Has anyone ever tried the weather options of ZRP and confirmed they work?

Because in the readme it says:

---QUOTATION---

"All Good Weather - Soft Rain after Midnight" - This will restore the
sun to the game without the need to start a multiplayer session first.
It rains softly a couple of times in the wee hours of the morning, and
the weather will still cloud over from time to time.

---END QUOTATION---

I have never noticed the restored sun. In fact, I was testing JUST the files involved in this option, and I see no sun anywhere (though the weather changes do apply).

I know the restore the sun mod makes it work by changing a couple of lines of the weather script, and possibly the weather files themselves.

Can't see anything in ZRP like that, other than the removal of some rain options in the default weather ltx.

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.

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.

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 fluffy22et 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."

Thanks NatVac for the detailed instruction. I "solved" it my way by substituting the variable with numbers from 30 to 150 (meters). In the last case the bandit lookout at Cordon's Autopark shot at me while I was standing at the bridge and then came after me, it was 'close combat' for him, haa . I have an idea now about the game values of that radius. I'm playing quite from some time with this changes and I perceive the AI behaviour more "normal" than before.

I started looking at the script for another reason, the AI behaviour during the movement to the preset spot. Sometimes they are completely unresponsive to external dangers during such transfer.

The most emblematic example are the Monolith moving to their assault positions at the Barrier. You can shoot as many times you like, they would not respond to fire until they've reached the spot. All those exoskeleton Monos moving to the left side of the road, (when the player is looking from the Freedom positions toward RF), look like they are taking a walk in the park.

O looked inside xr_combat_camper.script and xr_combat_monolith.script but to me, nothing seems to be directy related to the behaviour. The logic that controls the opening of fire during patrol are is there OK, but it looks like it does nothing. Anyone has any idea where and what to look for?

Add the three needed ltx files in the folder with one section in each lets call it

[my_section1]

in first, my_section2 in the second etc. This function will ovewrite the used ltx with the content of the choosen ones.

Then it's just a simple section search to use the setting

local ltx = ini_file("misc\\smp_game_start.ltx")
if ltx then
if ltx:section_exist("my_section1") then *do something*
elseif ltx:section_exist("my_section2") then *do something*
elseif ltx:section_exist("my_section3") then *do something*
end
end

"experience is a son of tough mistakes"

Oleg V. Yavorsky: Getting hit by a wardrobe flying into your head can be fun!

SmP 2.5 team member

We will all CTD in the end

"Im trying to get the bulbs for the gynecologist/cyclops but I cant figure out how to get over the fence"

---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.

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.

---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.

1) Increase characters carrying weight. 10000lb is great
In one magazine review they critisized low carrying weight. I say also that is annoingly low. I mean like this: "Take few guns. Run to trader then do it again." Carrying weight addition reducing those running around with items to trader trips.