ProjectsWhat's NewDownloadsCommunitySupportCompany
Forum Index » S.T.A.L.K.E.R.: Shadow of Chernobyl Forum » Mod discussion
ZRP - A joint effort in fixing S.T.A.L.K.E.R.

« Previous 10 events | 1 ... 338 339 340 341 342 343 344 345 346 ... 374 | Next 10 events »
Question Do YOU want an unofficial patch?
Yes, I'm desperate!
Yeh, why not...
I don't care either way.
Could easily do without it...
Decane, stop spamming the forums with your dumb ideas! NO!
Posted by/on
Question/AnswerMake Newest Up Sort by Descending
  00:59:34  21 May 2017
profilee-mailreply Message URLTo the Top
Senior Resident

On forum: 06/15/2007
Messages: 4286
Current Zone Reclamation Project (ZRP) download site:

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 to check this site.

Have a crash? A freeze or lockup? A BSOD? A shutdown? Go here, first:

"Crash To Desktop (CTD): Causes and Treatment":

Crashes still in the game:

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:
Troubleshooting FAQ:

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

There's another issue in 1.09 XR1: The last switch in X16 is not accepting the command to switch. The workaround is to make a save and reload that save, something I must have done accidentally in an earlier 1.09 playthrough after the switch was online. The bug is due to a logical optimization of a bad design which was supporting a quirky feature in xr_logic.script. The fix is in XR2, which is in test internally right now.

Some TMI for those interested:

Physical objects (doors, switches, cases/crates, breakables, lamps, cars, etc.) in the game are updated one to four times a second. In vanilla and in ZRP 1.07 R5, this involved objects that had no associated logic, a waste of processing time. And those that had logic or were drop_box crates or metal cases had their set of three callbacks re-added on every single update() call.

Example: Dark Valley has at least 93 physical objects that are processed. Of those, 29 don't have a spawn_ini() associated with them (no logic, no [ignore_static], etc.). Of the remainder, 26 are drop_box items. You break them, their logic is no longer needed. Three objects have a spawn_ini() but have no processing; the ini exists to put something in the associated chests.

Likewise, the Bar has at least 100 physical objects, with 35 objects sans logic, nine drop_boxes and one object with just [collide] data.

What xr_logic.script had been doing is setting the use callback to nil on scheme switch. This may have been done to stop a race condition (e.g., to prevent a door from being used while it is in the midst of opening or closing from the immediately-prior use) or just to remove no-longer-needed support (a broken box won't be used or hit again).

Well, that was fine until the devs discovered a problem with that: Subsequent logic won't work. A door will open once, but it can't be closed. Or it can be unlocked, but you can never open it -- until you save and then reload that save. So they did another "ad hack" fix (an old pun on "ad hoc", which is also appropriate) by re-installing the callbacks every update() call.

ZRP 1.09 avoids that unnecessary remove/re-add overhead. It also prevents the checking of physical objects that don't have any associated logic.

See this thread's page 338 for a couple of other XR1 issues, and page 337 for what's new in XR1.

Similar to the physical object tweak to prevent the continuous logic processing on those objects that don't need it, I've eliminated the space restrictors without logic from the list processed during the update(), a greater than 60% reduction in the number of space restrictors constantly checked.

All these tweaks have a positive effect for me: my game is no longer CPU-bound (where the single core used by STALKER was always pegged at 100%). And I like the very fast reloads of a save, showing that the main issue now is loading resources from disk. I've got an SSD I'll be using when the changes settle down.

But there was a downside: These speed-ups make the game's race conditions much more apparent. I've just spent some time fixing the auto-completion of tasks involving state changes. In vanilla the overhead of the game prevented the game from checking if there were any members of a camp until after the members began to be re-added in the new alarm state (or attack state) after being "fired" from the normal state. The camp population goes briefly to zero and then back up as the now-jobless NPCs take on the jobs in the new state. This was mentioned in ZRP_Changes_1.07_R5 to 1.09_XR1.txt.

(There was an exception that had nothing to do with this issue: The "defend the AW campsite" task would auto-complete because the vanilla logic looked at the village bloodsucker population instead of the attacking merc population. No bloodsuckers? Congratulations on defending the loners from the wrong threat.)

What was a once-in-a-while problem had become a more likely occurrence in 1.09 with Voronin's "Purge the bandit base" in Dark Valley. Soon after the bandit base went on the alert (from state_normal to state_alarm), you would probably see a task completion message even though you hadn't done anything yet.

That's now fixed and I'm testing it. I also removed the no-longer-needed artificial-delay hacks in gulag_general.script and gulag_military.script.
  01:00:30  21 May 2017
profilee-mailreply Message URLTo the Top
Senior Resident

On forum: 06/15/2007
Messages: 4286
Capt.Host, thanks for the nice summary of the typical experience. It will serve as a nice eulogy.

v1ld, thanks for the very encouraging words, and for the VCS suggestions for MrSeyker. The 1.09 release is a radically changed code base which is not modder-friendly at all. The changes may not be needed for most mods already using 1.07; the bug fixes can be isolated from the list of changes and the changed files are identified for relatively easy comparison, if not easy merging.

Is there a date or some kind of timeframe for when 1.09 will be released? Would love to know.

EA, as the download link info says, 1.09 is a work in progress. The number of testers on this ten-year-old effort has naturally diminished over the years. I received almost no feedback from those press-ganged into evaluating the crash on NPC reloading with a couple of exceptions, one being Storm Shadow, and his issue was actually with the Rulix NPC Weapon Manager, something I've not yet had time to address. So a test release was made public.

Just as the previous versions have had experimental releases (1.05 never made it out of "test" status), so does 1.09. I guess the first version without an XR designation will be an official release. With 1.07 that was R3.

So far, MrSeyker's comment about fonts and Lowpro18's bug report are the only ones who have taken the time to post useful feedback about the test release. That's okay; I'm in no hurry. I've discovered a couple more issues in my playing the pending 1.09 XR2 release. See above.

The XR2 release can be expected within a couple of weeks. The release after that will depend on converting the rest of the AI add-on stuff to the new base and fixing the weapon manager crash that the AI stuff introduces, something for which I don't have an estimate.

Lowpro18, if you see any more crashes, please check them against the "Bugs in STALKER" list at the ZRP website. There are workarounds for the CTD bug introduced by 1.0006 if you use or consume an item from a corpse. The easiest: enable the feature to automatically transfer your favorite items to your inventory when you check a corpse. Set local transfer_faves = true in zx.script and add the items you might otherwise consume to the favorites list: "bread", "conserva", "energy_drink", "kolbasa", "vodka", separating each with a comma except after the last one in the list. The "bandage" entry is already there; just remove the "--" prefix which makes it a comment. The "conserva" is the Tourist Delight can.

I believe I may have found the reason for the following CS bug, which is probably also in SoC

Yes, Decane, that "music still plays while NPC is standing up" bug is in SoC also. I had to tweak the code for the second instance (the target didn't always have a subanim, which didn't matter with the previous non-working approach) and I also put in a warning for future development because the subanim table is not contiguous. Thanks for the fix!

I noticed that although you seem to have sorted the section switch condition tests in try_switch_to_another_section() in descending order of occurrence, and likewise the actual values being tested, you are still using pairs() to iterate over the values in table 'l', and pairs() is known to iterate over elements in an arbitrary order. Have you considered using a numerical for-loop or ipairs() instead, to guarantee that on_info is really checked first if it appears first in the iterated-over table?

No, because I'd checked: In Lua 5.1 it's always first-in-first-out with a normal numeric indexed table that has not been sorted or undergone deletions or mid-table insertions, something we control in most of the table creations on the scripting side of the game. I did this check a long time ago after being bitten by the '#' (length) operator on a table with mixed elements. (Yes, I'd read the Lua manual -- still didn't expect it.)

I'm considering it now because I would expect a for x=1,#l do loop here would be faster than an iterator.

The real savings in try_switch_to_another_section() is due to the replacement of the cond() calls with in-line pre-concatenated strings. The constant string concatenation in a separate function was very heavy.

One more optimization coming -- which you likely have already thought about: All of the conditions are checked if none are met, which can happen a lot. A way to shorten this test loop is to break up the check into groups:
	if string_find_(c_name, "^on_actor") then -- test the on_actor group
		if string_find_(c_name, "^on_actor_inside%d*$") then
		elseif string_find_(c_name, "^on_actor_dist_le%d*$") then
		elseif string_find_(c_name, "^on_actor_...") then
	elseif string_find_(c_name, "^on_timer%d*$") then
		...other conditions...

This avoids testing all eight "on_actor" conditions (in SoC) unless there will be a match for at least one.
  01:03:34  21 May 2017
profilee-mailreply Message URLTo the Top
Senior Resident

On forum: 06/15/2007
Messages: 4286

There might have to be a revision of the ltx controlling dead body and crate boxes (there's a very low chance that they can drop low tier goodies that vanilla lacks).

If this is for a pure bug-fix mod, just use the vanilla files, MrSeyker. I made the odds of certain def_box items non-zero because every item there has no chance of appearing in a def_box. There were quite a few def_boxes in the vanilla game (examples: fourteen in the Cordon, eight in Agroprom) that were useless because of this -- worse than useless because they require logic support that does nothing but waste time. (See my comment on physical objects in a recent post above.)

Even then, the odds of getting an antirad or a medkit is still only one in a thousand def_box crates, a bandage only three in a thousand. An examination of the all.spawn files suggests they initially intended to populate every def_box with an obligatory spawn, but either didn't finish or just gave up. A pure vanilla fix might be to just remove all the [drop_box] entries that have "community = def_box" without any "items = ..." list. Just reverting the small changes you noted won't change the processing load much, if at all.

There is one change that caught my eye that made me raise an eyebrow. A stash with a Val and 90 rounds in vanilla has two Vals and 120 rounds in the latest ZRP.

That was changed in the very first ZRP release in October 2007. For one thing, "feast or famine" has been the (unique?) nature of the game; you get stashes with lots of one item on occasion, like five medkits or five grenades or eight antirads, but you might go a long time between such finds for any one item. Sometimes the game just throws ammo at you: There's a couple of rooms in X18 where you can overload on 5.45x39 ammo, even though you won't lack for it if you fight your way out through the soldiers. (Tip: one can run a gauntlet and likely survive if not overburdened.)

For another: there are 665 rounds of 9x39 AP (SP-6) ammo in Army Warehouse secrets, but this is the only Red Forest secret with that ammo. It is also the only source of the AS Val in a secret.

For another: The secret's description indicates it is military supplies. Like the stash in Pripyat where you get 240 rounds of 9x39 ammo from a helicopter crash, this is a footlocker next to a downed heli holding the transported supplies.

Yes, not vanilla. It's consistent with vanilla mentality, and supports the "living, breathing world" that exists outside of the player. Yes, you should take it out for a pure vanilla game. But in a true vanilla playthrough, one would not be able to carry much at that point and would likely already have a Vintar/Vintorez, so the number of rifles added to one's inventory at that point might be one more.

This could be added to Vanilla.cfg. I'm thinking of renaming that configuration file, as the ZRP-based SoC is much truer to the vanilla intent than the original game.

The quest manager is more significant. Built from a Quest Overhaul file, and updated in subsequent releases, it shifts around quests, makes them conditional, unlocks others, changes rewards (some had items that have been disabled in order to make them money transferring auto quests).

This statement is a repeat of old stuff discussed in the earlier part of this ZRP thread as well as in the Quest Overhaul thread. The approach evolved over time and is supported by the ones who took the trouble to express their preferences. The presence of a side task entry in the file is to support the optional side tasks without having to keep different copies. If the Quest Overhaul is not used, it is not affecting the game. And if it bothers anyone that much, there's a task_manager.ltx.normal provided in the config\misc\optional\ subdirectory. This is mentioned in docs\ZRP_ModdingNotes.txt:

There are some files included in the distribution that are not used by the game. Look in the optional directories for files with extensions like .normal or .alt1. The .normal files return more of the original game to you if you wish to use them. Less quests and the usual auto-quests, for example, when you rename task_manager.ltx.normal to task_manager.ltx.

... "And copy it up a level, replacing the default ZRP file." The file was moved to an optional folder in ZRP 1.05 nine years ago. No one has remarked on that omission, though. Even those who started with a pure vanilla game and switched to ZRP have not complained about the transitioning of some vanilla autoquests to side quests.

I remember changing a Wild Territory task for Voronin to make it work. And back in the early days before one could skip a task, I moved Voronin's task to kill those blind dogs in the Garbage to the very end; I didn't want to have to murder some dogs just to get to the more meaningful jobs.

Later I discovered that those dogs were scripted to attack the vehicle graveyard. Eh.
  01:08:52  21 May 2017
profilee-mailreply Message URLTo the Top
Senior Resident

On forum: 06/15/2007
Messages: 4286

[...] Then those that are a little
more experienced or victims of the first situation may start using Quick
Saves and Quick Loads. This allows them to save progress in more places
than the Auto Saves but the downside to that is Quick Saves are limited
in number and they overwrite each other. Overwrite your good save with
a bad one and you're screwed. So basically I always advise ANY Player
of ANY experience NOT to use Quick Saves & Quick Loads since they easily
corrupt, are limited in number due to overwriting and never to rely on just
Auto Saves alone.

Yes, quicksaves can burn you enough to swear off of them, Tejas Stalker. But this might be your experience with mods showing. Mod quicksaves are dangerous when the mod uses a couple of techniques: *pstor* storage additions that overflow when you save a lot; and direct manipulation of internal engine data via packet modification, which doesn't play well with multitasking because you can quicksave in the middle of an update, while the data is being changed. The result is corrupted saves. (v1ld mentions a couple of rarer mod corruptions on this thread's page 335: likely a mismatched object save/load in AMK's Yantar and missing/malformed ambients in AA2, but these are independent of the save method.)

But quicksaves in pure vanilla, in vanilla with ZRP and in any mod that avoids the dangerous techniques should be just as safe as manual saves with one simple exception: quicksaving when the game is synchronizing. At that time, the game is fleshing out the objects, but the multitasking system processes the quicksave key and writes the save to disk with incompletely-loaded object data. This is a common source of broken doors in vanilla -- the logic schemes become detached. (If it happens, one can fix that with the ZRP's support utilities.)

But even that does not corrupt saves.

The real reason to not depend on quicksaves is that you can do that at a point where something in the game has gone, or is about to go, awry. That's where your comment has real merit: you can overwrite -- really, replace; a deletion followed by a write doesn't always go to the same place, especially not with SSDs -- you can replace a good save with one not conducive to continued play.

Some will make "manual" saves from the console, but this is just as risky as quicksaves in mods. A general rule of thumb is that if you can get to the main menu you can make any kind of save you want. And ZRP has extra (safe) quicksaves, too. But any quicksave made other than when the game is synchronizing is just as safe as manual saves in vanilla or vanilla with ZRP.

I'm emphasizing "just as safe as manual saves" because there are certain places in "patched" vanilla where any kind of save, manual or otherwise, won't work. You can't make a reliably-usable save in Pripyat; there are several broken features of that level like a psydog invalidly assigned to a smart terrain or a bad NPC path waypoint. Getting the attention of a helicopter on the NPP south side can result in a crash when saving. All of these kinds of problems are fixed in the ZRP.

There are still problems with the game that can corrupt both manual saves and quicksaves even with the ZRP. The most common one I know about is the orphaned mapspot which happens when a body is destroyed within 50 meters of your position in vanilla or with ZRP. One situation for that is taking on arena combatants and winning. The game deletes the losers as it puts you back before Arnie. If you are within mini-map distance of the bodies, the spots can get disconnected from the associated NPCs. This can also happen in Whirligig and Vortex anomalies if they are close enough. The symptom of an impending problem is an error message in the console right after it happens. This means you can check to see if you need to replay from an earlier save. Look for "Critical: SMapLocation binded to non-existent object" text in the console log. (This is fixed in ZRP 1.07 R5 or later for the arena.)

Any save of any kind made after that error will be corrupt, although there can be enough of a separation between the cause and its consequence to leave you bewildered as to what happened.

A public service reminder: Move the quicksave keybind away from the quickload keybind. Putting the quicksave key right next to the quickload key is an example of bad affordance, a term describing the logical usability of a product that stems from its design. The word is from "The Design of Everyday Things" by Donald A. Norman. Anyway, you can try to quicksave and wind up loading a prior save if you don't move those keybinds apart. Worse, you can try to load and wind up quicksaving during synchronizing -- and not even know it!

99% of a Player's problems can be solved by making
Manual Saves, frequently like before leaving a level and after you arrive,
before you engage in a battle or meet a mutant and after that action is
over. Before you meet someone important and after you have done so
with your new reward, loot or task.

This is very good advice for vanilla or ZRP-based games. Some mods don't like anyone saving a lot, though.

Get the radiation bug? A door won't
open? Going back to a Manual Save prior to this event solves all of these.
Simply put, being able to go back BEFORE a problem is the easiest solution.

In my opinion the easiest solution is the application of measures to avoid having the problem in the first place. Five minutes to download and install a bug-fix mod can prevent a lot of grief.

You have the advantage of a wealth of meta-knowledge gleaned from extensive time playing the game. The beginning player does not have that knowledge, as shown by the myriad posts of woes on various forum sites.

Often the earliest save that doesn't have the issue is a long way back from the typical player's current progress -- they don't have the smart habit of making saves as you describe. But with the ZRP the problem generally goes away or never happens. (All the rare exceptions can be fixed with the ZRP's extra features.) And the "manual save" becomes trivial in the ZRP: Esc F5 (or Esc F6) is a level-based manual quicksave, so you can have a unique one on every level. And each level has its own autosave instead of just one autosave for the whole game.
  14:10:19  21 May 2017
profilee-mailreply Message URLTo the Top
Senior Resident

On forum: 04/04/2007

Message edited by:
05/21/2017 15:16:40
Messages: 1703

In Lua 5.1 it's always first-in-first-out with a normal numeric indexed table that has not been sorted or undergone deletions or mid-table insertions

Nice, thanks for the info.

The real savings in try_switch_to_another_section() is due to the replacement of the cond() calls with in-line pre-concatenated strings. The constant string concatenation in a separate function was very heavy.

I concur. However, I've got a system I think you'll appreciate even more, which replaces the string.find() tests with simple string equality checks (much faster). It requires passing in variable 'cond' (with e.g. value "on_info") as a separate argument to each of the function-values of variable 'func' in cfg_get_switch_conditions() and using that 'cond' variable (instead of variable 'field', with e.g. value "on_info3") as the value of the 'name' field in the hash returned from each func() call in cfg_get_switch_conditions(). That way, the 'st.logic' array field bound to variable 'l' in try_switch_to_another_section() only contains condition names that are not suffixed by an integer, even though the condlists for any integer-suffixed conditions (e.g. 'on_info3', 'on_timer2') are still contained in 'l' as previously.

In implementing this system, I did define custom-named functions (e.g. "cfg_get_condlist_s()") for use by cfg_get_switch_conditions(), since e.g. cfg_get_condlist() gets called by other scripts as well, and I didn't want to start testing for whether variable 'cond' was passed in or not. Also, using custom functions allowed me to freely make other optimizations, many of which are copied from the ZRP. Here is a snapshot of the current WIP version of xr_logic.script for the next SRP version, with all the previously referenced optimizations in place: Caution: Not yet tested!
  10:37:24  24 May 2017
profilee-mailreply Message URLTo the Top
Senior Resident

On forum: 06/15/2007
Messages: 4286
Decane, I'm impressed. Favorably, even!

The direct string comparison works just fine in SoC. I checked that all the non-xr_logic.script calls to the condlist functions only processed alpha-named sections (e.g., one-offs) in SoC vanilla. I also realized something: If you don't care about the debug info (something you can re-enable if there's a problem with your additions), then you don't need multiple argument signatures -- you can just pass cond to be stored as the name, as the field argument to parse_condlist() is not used -- actually, the first three arguments to your parse_condlist() are never used.

I'm in Agroprom on a new playthrough with the change. Absolutely no trouble encountered beyond the kind you want to see in the game.

I seem to have the best results with a single string_find() to match "on_actor_" (to group the eight "on_actor_" string comparison tests) and string compares for all the rest versus just string compares. In my otherwise-useless test on DX8 medium-low, I would run through the Bar level from the AW level changer all the way south to just shy of the Garbage level changer on the Bar level, look at the ground with nothing in my hands, low-crouch and then note the framerate shown on the debug display. The event loop had a typical delta of 3 or 4 ms (250-333 FPS) and even would occasionally hit 2 ms. Outside of the game, I would be running a task manager graph showing the CPU usage. My dummy test would show the game's CPU core using less than 50% of max during that time on the Bar's south end.

Thanks for the contribution. XR2 is going to be the Decane edition.

In other news, the Bar sr_territory check is broken in 1.09 XR1 (the new_action variable is never assigned the value of the object created for that purpose), so you probably won't see any response to your violations of Duty regulations there. I found it when I was checking the issue_event() processing.

I also tweaked the look-at-attacker-when-hurt feature I added in 1.07 R5. It was not working well enough across saves, so that when you were the attacker last seen to the south by your enemy when you saved, when you reloaded that save and flanked your enemy on, say, the west side, he would be fixated on your last-seen position -- and would not turn right away to look at you when you shot him. Now he should (if you were his "best enemy" before and if he is still alive when you shoot him) and the rest of the enemy's faction will be notified of your new position if your enemy sees you when he looks your way.
  11:07:00  3 June 2017
profilee-mailreply Message URLTo the Top
Senior Resident

On forum: 06/15/2007
Messages: 4286
ZRP 1.09 XR2 (AKA the Decane Edition) is available on the website's downloads page:

It's still experimental, as noted by the XR in the version. Featured in this release are Decane's fixes and tweaks.

What's new in this version:

Changes in 1.09 XR2 over ZRP 1.09 XR1
ZRP 1.09 XR2 changes (NatVac and others as noted):

Bug Fixes and Tweaks:
* Tweaked get_nearest_anomaly() to use one short radius for
  detection (low processing demand) and a longer radius for
  actual anomaly avoidance (to prevent NPC stalls after
  successfully avoiding the nearby one). [anomaly_evader.script]
* Kept space restrictors without logic out of the updateable
  list to reduce the update() processing (>60% reduction).
* Prevented trade with NPCs if they are in panic mode; panic
  causes an incomplete initialization. Also fixed the update()
  check to see if the inventory needed to be refreshed due to a
  switch to a different logic section. It was intended to check
  once a real-time hour but was doing so continuously.
  [trade_manager.script, xr_logic.script (*)]
* Stopped processing saves and loads in trade_manager.script
  because the trade settings were ignored in trade_init(). The
  configuration is simply re-read and the condition lists are
  re-parsed and reset. Updates for generic traders are now
  ignored (nothing ever changes from what is initially set on
  session start). (NatVac, Decane) [trade_manager.script]
* Added ph_button to the exception list of schemes that don't
  need to have their callbacks removed on scheme switch.
  [xr_logic.script (*)]
* Corrected anim iteration checks to properly decrement from
  total anim count instead of incrementing. This stops the
  playing guitar music when the NPC stands up. (Decane)
* Modified state change processing and gulag population checks
  to prevent race condition issues like arbitrary task
  completion due to slow re-hiring of NPCs/mutants for jobs in
  the new state. Removed obsolete time-delay workarounds. This
  change can affect saves; there is now a possibility that
  a ZRP 1.09 save is not backward compatible with ZRP 1.07.
  [gulag_general.script, gulag_military.script, xr_gulag.script]
* Switched from all string_find checks to mostly string compares
  within try_switch_to_another_section() for speed. Adjusted
  related condlist processing. (per Decane)
  [xr_logic.script (*)]
* Fixed XR1 regression issue that let the player get away with
  murder on the Bar level. [sr_territory.script]
* Modified prod_npc_on_hit logic to force NPCs to look your way
  when you shoot them, after a reload has them facing where you
  were when the save was created. [xr_motivator.script (*)]
* Modified register_target() and unregister_target() in
  task_manager.script to take another argument to speed up
  processing. Also adjusted a couple of files that used those
  functions. (se_item.script did not need to be adjusted.)
  [task_manager.script, se_stalker.script, smart_terrain.script]
* Implemented quite a few access tweaks and other optimizations
  in various script files.
  [*.script - go by modified date between 4/17 and 6/2/2017]
* Set a timer to activate the player's weapon for the arena.
  This will work for all the matches except the surprise one.
* Player's arena inventory is no longer stored in inventory box
  after successful matches. This should reduce stash-based lag
  on the Bar level if you play in the arena. [xr_effects.script]
* Let the player know during his first dialog with Arnie where
  his inventory will be after the match if he survives.
  (English) [config\text\eng\stable_dialogs_bar.xml]
* Added xr_logic.script to the main_menu.script's validation
  check. If xr_logic.script was not valid, any attempt to start
  a game or load a save would hang the game. Now you will be
  notified that xr_logic.script has a problem and will be
  prevented from doing anything except quitting.
* Added another "cleaner fonts" option: a smaller font size.
  (MrSeyker tweaked ZaGaR's cleaner fonts.) See the Modifier
  section. [config\optional\fonts.ltx.ZaGaR_MrSeyker; renamed
  config\optional\fonts.ltx to fonts.ltx.ZaGaR]

Modifier configuration changes (NatVac):
* Added Fonts entry to support a cleaner font and a cleaner
  font with a smaller text size, as well as vanilla.
  [modcfg\_ZRP.cfg, modcfg\Vanilla.cfg]
* Made some small text changes on tooltips to aid in deciding.
  [modcfg\_ZRP.cfg, modcfg\Actor.cfg]
* Added tip on Camera Viewpoint (player's view height) to
  adjust Item Pickup reach as well. [modcfg\Actor.cfg,
* Minor corrections/rewording on various Modifier files.
  [modcfg\*.cfg, modcfg\*.cfg.txt]

Debug changes (NatVac):
* Supplied a script to make teleporting a specific distance a
  little easier. It uses z.jump(), re-introduced in the XR1
  release. It has some special features to permit jumping to
  stashes, inventory_boxes w/story_ids and those without. Copy
  it up a directory from scripts\optional\ if you might want to
  use it. SAVE BEFORE EACH USE! There currently is no smart
  positioning on destination, so you could find yourself inside
  a car or other Marked-One-mangler. (Esc D R to get back, or
  Esc D F to jump out.) See the XR1 debug changes for more info.

All.spawn changes/fixes since 1.09 XR1 -- these require a new
game, but are not critical so existing saves are okay:
* Removed four instances of "trader_flags = 0", one for an
  Agroprom stalker and one for an RPG-wielding merc in the Wild
  Territory, with the remaining two being the player and the
  Cordon trader. The engine didn't quite ignore the unused flag;
  in the first instance the stalker often didn't have ammo for
  his weapon. [alife_l01_escape.ltx, alife_l03_agroprom.ltx,
* A zrp107r5_zrp109xr2_spawns.diff file is included. Find it
  in the gamedata\docs\diffs_for_modders\ subdirectory.

Notes, instructions and changes in ZRP 1.09 XR1 since 1.07 R5RC are given on this thread's page 337:


Please follow new posts in this thread for any notes that might affect/improve your enjoyment of this release.
  01:15:44  4 June 2017
profilee-mailreply Message URLTo the Top
On forum: 01/31/2013
Messages: 61

Hey NatVac are there few testers for zrp? And if so what exactly you need to fix still? If there's something to try/do in game let me know i'm available for testing stuff
  02:02:23  4 June 2017
profilee-mailreply Message URLTo the Top
On forum: 04/28/2014
Messages: 16

I finally completed a playthrough on 1.09 XR1 and havent encountered any problems during and i noticed you just released XR2 so i might give it another go soon to report anything i run into. I have a question, Would it be possible to add the cut mutants during ZOI mode? I added them in the spawn menu and didnt see any issues with them running around the level and thought it would be fun to have some more challenges in a freeplay session.
  05:13:50  4 June 2017
profilee-mailreply Message URLTo the Top
Senior Resident

On forum: 03/21/2010
Messages: 433


I finally completed a playthrough on 1.09 XR1 and havent encountered any problems during and i noticed you just released XR2 so i might give it another go soon to report anything i run into. I have a question, Would it be possible to add the cut mutants during ZOI mode? I added them in the spawn menu and didnt see any issues with them running around the level and thought it would be fun to have some more challenges in a freeplay session.

They would need more tweaking. Vanilla cut mutants do stupid amount of damage and can soak out bullets like crazy.
Each word should be at least 3 characters long.
Search conditions:    - spaces as AND    - spaces as OR   
Forum Index » S.T.A.L.K.E.R.: Shadow of Chernobyl Forum » Mod discussion

All short dates are in Month-Day-Year format.


Copyright © 1995-2020 GSC Game World. All rights reserved.
This site is best viewed in Internet Explorer 4.xx and up and Javascript enabled. Webmaster.
Opera Software products are not supported.
If any problem concerning the site functioning under Opera Software appears apply
to Opera Software technical support service.