 |
 |
 |
|
|
|
 |
|
|
|
 |
|
| ZRP - A joint effort in fixing S.T.A.L.K.E.R. |
|
« Previous 10 events | 1 ... 254 255 256 257 258 259 260 261 262 ... 362 | Next 10 events » |
 Question |
Do YOU want an unofficial patch? |
| Answers |
|
|
|
|
 00:06:57 26 October 2011 |
|
ZaGaR
Skaarj Hybrid - NaPali survivor
(Resident)
On forum: 07/24/2007
Message edited by:
ZaGaR
10/26/2011 15:24:42
Messages: 647
|
On the AI logic improvements theme.
I did some small changes to xr_camper.script that have improved a lot the behaviour of the stationary guards. Seriy and co. manage to repel and kill the bandits now. Bes' situation improves a lot too.
The script has a local variable self.a.radius that also controls this behaviour. I tried to set a debug watch for its value, but failed miserably  .
I'll try to post these changes ASAP so that you guys judge yourselves if it worth at all.
======THE CHANGES to xr_camper.Script======
1- The thing I believe deals with the blindness of the camper-NPCs beyond 20m. In the original, line 548 is:
st.radius = utils.cfg_get_number(ini, section, "radius", npc, false, 20)
changed to:
st.radius = utils.cfg_get_number(ini, section, "radius", npc, false, 80)
I used a figure equal to the default view distance.
2- There are several time limits in xr_camper.script.
Line 74 is:
if time_global() - a > 20000 then
Make it 50000 or more.
The most significant behaviour change comes from script lines ~567:
st.post_enemy_wait = 5000 -- âðåìÿ, êîòîðîå ìû æäåì âðàãà, ñìîòðÿ â åãî ïîñëåäíþþ ïîçèöèþ.
Personally I used 50 000 and then 100 000, much better
st.post_enemy_wait = 100000 -- time we wait for the enemy, looking at his last position
Yo can also experiment with the line above it: "time to forget the enemy"
st.idle = utils.cfg_get_number(ini, section, "enemy_idle", npc, false, 60000)
If you try these things folks and see if you like what they cause. The only adverse effect I saw is the abandoning of the positions from some NPC we would prefer really stationary.
подавился зараза - choked that infection 
|
| 06:56:29 6 November 2011 |
|
NatVac
Senior Resident
On forum: 06/15/2007
Messages: 4239
|
Current Zone Reclamation Project (ZRP) download site:
http://www.metacognix.com/stlkrsoc/
Please read the documentation in the mod's archive before posting here. And your question might already be answered elsewhere; you can try Google with the search parameter site:gsc-game.com to check this site.
Have a crash? A freeze or lockup? A BSOD? A shutdown? Go here, first:
---QUOTATION---
"Crash To Desktop (CTD): Causes and Treatment":
https://www.gsc-game.com/main.php?t=community&s=forums&s_game_type=xr&thm_id=11715&sec_id=12
Crashes still in the game:
http://www.metacognix.com/stlkrsoc/CrashesStillInTheGame.html
---END QUOTATION---
Read the "Find your log file" section. Most "crashes" are fixable, but we need the info from the end of the log file.
Bugs in STALKER-SoC: http://www.metacognix.com/stlkrsoc/BugsInSTALKER.html
Feel free to mention any bugs or crashes you know that are missing from the list.
If you don't start a new game, there may be some minor problems with your saved games. The saves are modified versions of the all.spawn file present when you started your current game. Saved games based on mods might also include custom items from those mods, and support for them will need to be properly merged to avoid crashes.
¯¯¯¯¯¯¯¯¯¯
ZaGaR, some good thinking there. I'll look at some of your changes in a bit. I'd been looking at xr_combat_camper.script in the same way in the demo days, and I remember having to explicitly assign the scheme to the logic. But any NPC using xr_camper@xxx will use this scheme.
---QUOTATION---
The script has a local variable self.a.radius that also controls this behaviour. I tried to set a debug watch for its value, but failed miserably .
---END QUOTATION---
The "a" is the storage variable, the same as the st variable in the set_scheme() function. It's set in the __init() constructor function for the evaluator_close_combat class, "instantiated" by the add_to_binder() function, itself indirectly called by xr_logic's assign_storage_and_bind() function via set_scheme() for each NPC.
In English: There is a unique set of class "instances" associated with each NPC via the assigned logic for him. You would need quite a bit of info to access that data for a particular NPC, but it can be done. Get the NPC object via z.this_guy() (you can use z.this_name() in Variable Watch to know you can get the NPC object via z.this_guy()) and assign it to a global variable in Execute Script Command:
exec myNpc = z.this_guy()
Verify that it is not nil by entering the following and pressing Enter:
myNpc
(If examining the result of a function, you'd use "print" or "echo" as a prefix. See the docs.) That should return "userdata" for the object. Get the storage this way:
exec myNpcSt = db.storage[myNpc:id()]
That should be a table:
myNpcSt
Now you can look at his xr_camper logic:
exec myNpcC = myNpcSt["camper"]
If myNpcC is not nil, you can look at his "radius". (If nil, check the NPC for other logic, like "meet" or "danger". Example: Try myNpcSt["danger"].ignore_distance or myNpcSt["meet"].meet_set -- you'll have to find a variable that is part of a scheme assigned to the NPC.)
myNpcC.radius
Or you can examine it in a Variable Watch. But I don't expect it to change once set. However, you can now dynamically change it by assigning a new value to it. I don't know when that value will be re-accessed; you might have to save and reload to get it to change, and that will likely invalidate most if not all of your current global variables.
Since it doesn't change, you can just put in a debug statement in the set_scheme() routine right after you have read the value from the configuration file. 
¯¯¯¯¯¯¯¯¯¯
MrSeyker, re restored sun: That is probably due to a misinterpretation on my part. I'm playing almost exclusively with static lighting (save for a bit of testing under dynamic lighting, but it is too painfully slow on my outdated gaming PC), and until I changed the weather I had not seen the sun's circle before, just the lit-up clouds. That text was already marked for change for the next release.
Re the Duty vs Freedom minimod: The version you posted to make it more accessible to me was apparently updated with a change to limit the quality of the suit you get from Voronin if you are not a member of Duty. Unfortunately the conditional test is missing an end statement in bar_dialogs.script's enter_to_dolg() function. (You'll see a strange crash referencing xrLua and xrGame DLLs in a stack trace if you talk to anyone with a <precondition>bar_dialogs.function</precondition> in an active dialog branch, or select a dialog option that uses <action>bar_dialogs.function</action>, because the bar_dialogs script object is nil.)
I took the liberty of reverting it to vanilla because that test is performed before you can join Duty, thus making the Duty equivalent of the SEVA inaccessible in the game as a reward from Voronin even if you join Duty.
Beyond that, the DvF (FvD?) minimod is working as standard fare. Do we need a conditional on Lukash's merc camp task? I ask because Freedom membership makes mercs and bandits neutral. I've not yet tested the dialog_manager change to see if the wounded dialogs appear for them yet.
Thanks for the info on the "defend border from Monolith" info_portion stuff. |
| 07:05:15 6 November 2011 |
|
NatVac
Senior Resident
On forum: 06/15/2007
Messages: 4239
|
Bug Fixes and Workarounds, part five:
Actually, this is more of a useful enhancement.
Here's a nifty way to get level-based autosaves. It copies or renames autosave.sav to <level>_autosave.sav, where <level> is the name of the level (e.g., l01_escape or l02_garbage). It should work with any version of bind_stalker.script -- ZRP is not required.
Edit gamedata\scripts\bind_stalker.script. Put this block at the top of the file, before the first line:
-- set this true to automatically copy or rename autosaves
local level_autosaves = true
-- these apply if the above is true
-- set this true to rename autosave, false to copy it
local rename_autosave = true
-- set this true to preserve your first access to a level
local keep_first_level_access = false
After this line in the file:
if self.bCheckStart then
insert the following block of code (leading spaces/tabs don't matter)
local fs = getFS()
local autosaveFile = string.lower(user_name()).."_autosave"
if level_autosaves and fs:exist("$game_saves$", autosaveFile .. ".sav") then
local sg = CSavedGameWrapper(autosaveFile)
if level.name() == sg:level_name() then
local target = level.name() .."_autosave"
local target_save = target .. ".sav"
local target_image = target .. ".dds"
-- update_path info per fluffy22
local savedir = fs:update_path("$game_saves$", "")
local need_level_snapshot = false
local target_exists = fs:exist("$game_saves$", target_save)
if target_exists then
local sg2 = CSavedGameWrapper(target)
if sg:game_time() > sg2:game_time() then
-- autosave is newer
need_level_snapshot = true
end
else
need_level_snapshot = true
end
if need_level_snapshot then
if rename_autosave then
fs:file_rename(savedir..autosaveFile..".sav", savedir..target_save, true)
else
if target_exists then fs:file_delete(savedir..target_save) end
fs:file_copy(savedir..autosaveFile..".sav", savedir..target_save)
end
get_console():execute("load_last_save "..target)
if keep_first_level_access then
local first_target = level.name() .." - start.sav"
if not fs:exist("$game_saves$", first_target) then
fs:file_copy(savedir..target_save, savedir..first_target)
end
end
end
end
end
Change the top variables to suit your needs. The upcoming ZRP 1.07 R3 release will also support your custom savegame prefix. I suggest leaving rename_autosave true; it has no noticeable effect on level transitions (when autosaves are usually made).
The keep_first_level_access variable is practical only for new games, making a "<level> - start.sav" the first time you visit each level if it is set to true. (Use all.sav for the Cordon.)
Thanks to ThunderFreak for asking and fluffy22 et alia for posting useful info in the "Changing Loadscreen" Mod Discussion thread (thm_id=21095). That's part of one item on a pending checklist of mine: "Determine formal parameters to C++ engine functions." |
| 06:03:40 12 November 2011 |
|
MrSeyker
Senior Resident
On forum: 03/21/2010
Message edited by:
MrSeyker
11/12/2011 6:06:54
Messages: 417
|
---QUOTATION---
Re the Duty vs Freedom minimod: The version you posted to make it more accessible to me was apparently updated with a change to limit the quality of the suit you get from Voronin if you are not a member of Duty. Unfortunately the conditional test is missing an end statement in bar_dialogs.script's enter_to_dolg() function. (You'll see a strange crash referencing xrLua and xrGame DLLs in a stack trace if you talk to anyone with a <precondition>bar_dialogs.function</precondition> in an active dialog branch, or select a dialog option that uses <action>bar_dialogs.function</action>, because the bar_dialogs script object is nil.)
I took the liberty of reverting it to vanilla because that test is performed before you can join Duty, thus making the Duty equivalent of the SEVA inaccessible in the game as a reward from Voronin even if you join Duty.
---END QUOTATION---
DAMN!!
I had already caught that bug, but it seems I only fixed it in the files for my big mod merge and forgot to update the mini-mod before uploading.
Time to update the dowload links.
Also, I did not make any change to the mercs or bandits, and I'm not familiar with how the game handles medkit dialogs, so that will probably be an issue.
And there's one other feature I'd like to have which is a neutral Bar for Freedom allied players.
EDIT:
Well, here's a fix for that bug and now the duty reward should behave correctly if the mod is not enabled.
Old MF link is delted, but it wont let me upload the fix ATM, so only a Megaupload link for the time being.
http://www.megaupload.com/?d=CXDESXIO
Also, it bothers me that this board won't let me edit old posts.
I want to get rid of all the outdated links (Rapidshare's are gone, and the MF uploads have been changed thrice now).
EDIT2:
Delted the old post and changed the upload yet again :\
Also, the dowload links in page 253 (and probably the any other previous link to my mods posted) are now all dead.
Just follow my sig if you want to download them again.
My S.T.A.L.K.E.R files:
https://www.mediafire.com/folder/galaj1kcbawe9/SHOC
https://www.mediafire.com/folder/1duxlnn6jlm5z/STALKERFiles
|
| 04:16:17 26 November 2011 |
|
NatVac
Senior Resident
On forum: 06/15/2007
Messages: 4239
|
ZaGaR, re the AI behaviour during the movement to the preset spot: What's also annoying is that they know they are getting hurt because they complain about the damage! I know there's some general path following in getting to a destination where the NPC moves from waypoint to waypoint. Either the waypoint navigation support has it, or there's a general ignore_combat setting or something similar.
I now have a z.dbstruct() function to perform a "dump" (listing) of the variables and schemes attached to NPCs. It is essentially the same as the print_table() function in _g.script (which is useless in retail versions of the game because the devs disabled the debug stuff like printf()).
Anyone can adapt the vanilla print_table() function by replacing the printf() calls with dbglog() calls in ZRP (or equivalent in your own mod), but they need to know that the original function would crash because it prints the table key index values as strings but for some reason the actions table for schemes like walker or death uses a game object (which is interpreted as userdata in the Lua script engine) as an index, and the string.format() instruction would throw an exception noting that there is no such operator to convert that into a printable string.
If you use the ZSU's Execute Script Command function to execute this command, it won't crash but it will only list the NPC's data up to the first actions table unless you check for that situation. To fix that, check if type(k) == "userdata" before you do the normal checks for type(v) -- note the check for type of the key k instead of the type of the value v. If a match, then just print a debug statement that the key is userdata. This is already handled for the next release.
¯¯¯¯¯¯¯¯¯¯
Lijenstina, re your new game configuration approach: Great minds think alike. I mentioned earlier that I would be implementing something similar for ZRP 1.1. One advantage is that a relatively-robust mod could be compressed back into a gamedata.dbn archive and use a scheme like the one you proposed for configuration.
¯¯¯¯¯¯¯¯¯¯
MrSeyker, thanks for posting the update to your Duty vs Freedom mini-mod. I still think that because the info_portion is not yet given when the check is made, one will not get the Duty equivalent of the scientific suit even if one joins Duty. It is given upon completing the quest, but you are still in the process of doing so when the check is made.
I think the medkit dialogs for mercs and bandits (as well as Monolith followers) is handled already, but as mentioned I'd not yet tested the dialog_manager change to see if the wounded dialogs appear for them yet.
I don't know what to do about a neutral Bar since it is Duty territory -- unless you mean the 100 Rads Bar itself, in which case you can just keep the lone Dutyer out. But there's still the issue of getting there without shooting any Dutyer. While you can normally shoot an enemy without changing faction relationship status, the Bar script logic checks to see if you hurt NPCs that are normally actor-neutral in vanilla, like loners, Dutyers and ecologists and puts out a broadcast noting that you are now everyone's target if you hurt Duty.
It bothers me as well that the forum won't let one edit old posts, but the reason given was ... reasonable: It keeps folks from changing posts to rewrite history. I'd like it if you couldn't edit existing text, but you could append a note, like one of correction based on new info to keep folks from doing something that isn't helpful. I suppose if one really needs the change, one could contact Don Reba.
And thanks for not shooting the messenger on the Mediafire thing. As Cassandra's heir, I fully and miserably empathize with the poor prognosticator's plight. |
| 18:55:56 26 November 2011 |
|
MrSeyker
Senior Resident
On forum: 03/21/2010
Messages: 417
|
---QUOTATION---
MrSeyker, thanks for posting the update to your Duty vs Freedom mini-mod. I still think that because the info_portion is not yet given when the check is made, one will not get the Duty equivalent of the scientific suit even if one joins Duty. It is given upon completing the quest, but you are still in the process of doing so when the check is made.
---END QUOTATION---
I finally get what you mean.
I wanted to make the game give you a common duty suit for doing missions for them as a loner and the duty seva for doing missions as a dutyer.
However, the game uses the enter_to_dolg function three times, and all of them are 1-time-only.
The rg-6 reward is pre-duty only, the kill-twig-reward is also 1-time-only and can be taken before joining the faction therefore locking out the duty seva, and when joining duty you get the reward BEFORE you're given the infoportion, so you never recieve the duty seva.
It's easily fixed, just give the infoportion before giving the reward.
That way, depending on how you play, you can end these missions with:
2 duty suits, 1 duty seva suit
1 duty suit, 2 duty seva suits
About the bar:
I need to modify the all-spawn to make the bar area neutral to a freedom actor (just him)? Could this be achieved by script?
As for the dialogs, I'll have to check some of the faction mods to see if they do anything to the wounded dialogs, and do some testing.
I'll update my download again afterwards.
If you think leaving the suit check out is for the best, be my guess.
My S.T.A.L.K.E.R files:
https://www.mediafire.com/folder/galaj1kcbawe9/SHOC
https://www.mediafire.com/folder/1duxlnn6jlm5z/STALKERFiles
|
|
« Previous 10 events | 1 ... 254 255 256 257 258 259 260 261 262 ... 362 | Next 10 events » |
| |
|
| |
| » » |
| |
All short dates are in Month-Day-Year format. |
|
|
|
|
|
|
|
|
|
