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 ... 356 357 358 359 360 361 362 363 364 ... 368 | Next 10 events »
Question Do YOU want an unofficial patch?
Answers
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
  14:34:37  3 December 2018
profilee-mailreply Message URLTo the Top
castl
(Novice)
 
On forum: 03/27/2009
Messages: 41
Found interesting with the packages. xr_gulag.script file

for i, job in ipairs( self.Job ) do
packet:w_u32( job.begin or 0 )
packet:w_32( job.fill_idle or 0 )
packet:w_u32( job.idle_after_death_end or 0 )
end


job.begin? 32 bit number and using game.time() ??? Why? Maybe use must game.get_game_time():diffSec(job.begin)?

Besides, why use u32 for job.fill_idle, enough u8!!!

I think not using self.was_in_smart_terrain!

file trade_manager.script

Why comment block in the save method? And reading all the rest... There are mistake packet:w_bool(false) added line

You need to write as much as you read!!!


we have not save\load methods necessary at all, since the same parameters are used during booting as during initialization
---END QUOTATION---
  03:47:39  4 December 2018
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
 

Message edited by:
NatVac
12/04/2018 9:14:53
Messages: 4259
The links to the current Zone Reclamation Project (ZRP) download site are in my first post on the previous page (as of this post).
__________

---QUOTATION---
>> Even if there were such a function, why would you need to use it?

I did this to clear some evaluates, that are still being called, for example:

xr_danger.script

function evaluator_danger:evaluate()

For the dead stalkers evaluate has called!
---END QUOTATION---


If that is happening, for some reason it is not crashing vanilla. I'll look into this, castl. Meanwhile, your test for alive() may be a workable alternative.

---QUOTATION---
--self.st.state_mgr.planner:clear() --' Working! Its so clearing
--self.object:motivation_action_manager():clear() --' does not working
---END QUOTATION---


When I asked you where you got a clear() function, I said it this way:

---QUOTATION---
Where do you get a clear() function for the motivation action manager? There's one for the planner, but not one for the manager that I know of.
---END QUOTATION---


What I meant by that remark is that lua_help.script shows a clear() member function for the planner class, but not one for the motivation_action_manager class.

Edit: What you might be able to use in the death callback or in xr_motivator.script's update() is:

self.object:motivation_action_manager():remove_evaluator(stalker_ids.property_danger)

>> I caught a mistake on the Yantar with my debug log!

Yes, there's an error in the vertex id; it's -1. The only reason I can think of that would explain why it doesn't crash vanilla is that it is a kamp instead of a true waypoint. I'll check this out to see whether an all.spawn change is needed, or if we can just go with a change to gulag_yantar.ltx. Thanks for reporting it.

Edit: Okay, I checked it out. The vanilla game does not use yantar_zombies_kamp_4 as is. It appends "_task" to it and checks for that section, and if that doesn't exist the game will use the original path. Here, however, yantar_zombies_kamp_4_task does exist, so it uses that. See xr_gulag.script, function gulag:get_job_path_name().

As for xr_gulag.script:

---QUOTATION---
job.begin? 32 bit number and using game.time() ??? Why? Maybe use must game.get_game_time():diffSec(job.begin)?
---END QUOTATION---


It's because game.time() returns a 32-bit number indicating the number of game-time (vanilla 10X real-time) milliseconds since about 8:45 a.m. on April 30, 2012. The math is much simpler when just comparing numbers than going through the conversions to get human-oriented values that we humans will never see.

Now that I think about it, game weather management should use game.time() instead of time_global(), because time_global() is always reset at the start of each game session, when you load a save or change levels. This is what rendered the vanilla level_weathers.script useless for managing weather changes -- what you see in a vanilla game is solely controlled by the engine.

>> Besides, why use u32 for job.fill_idle, enough u8!!!

Yes, but that's what's in the vanilla saves, and ZRP strives to be compatible with pure vanilla saves. We could make a change to test and convert saves to ZRP with an 8-bit value, but that overhead is not worth the very small savings in storage.

>> I think not using self.was_in_smart_terrain!

Yes, it's not used other than for debugging, and those debug statements are commented out. But we keep the parameter for save compatibility. One optimization here would be to throw away what is read from the save, and then only write out false. That would save a byte for just about every entity spawned by the game.

---QUOTATION---
file trade_manager.script

Why comment block in the save method? And reading all the rest... There are mistake packet:w_bool(false) added line

You need to write as much as you read!!!
---END QUOTATION---


How much is written/read is still controlled by a boolean flag. As you noted:

---QUOTATION---
we have not save\load methods necessary at all, since the same parameters are used during booting as during initialization
---END QUOTATION---


Yes, the parameters are the same. The game is reading the same information that was written -- and then overwriting it without using it. (Autosaves only use trade_init(), while loading non-autosave saves invokes load() before trade_init(), and trade_init() reinitializes the trade manager for each NPC.) This is a waste in vanilla.

But to maintain vanilla save compatibility, the full load is initially performed because the boolean flag will be true when a vanilla save is loaded.

After that, ZRP will write out a boolean false on subsequent saves. When those saves are loaded, the load() function will fetch the flag, see that it is false and then simply return.

If you look at the comment block in the ZRP 1.09 trade_manager.script's save() function, you will see that the vanilla code was already testing for the NPC's trade_manager, and then writing false and returning if the test was false. Now the test will always be false, so there is no need to write redundant information.
  09:32:51  4 December 2018
profilee-mailreply Message URLTo the Top
castl
(Novice)
 
On forum: 03/27/2009
 

Message edited by:
castl
12/04/2018 9:36:22
Messages: 41

---QUOTATION---

game.time() returns a 32-bit number indicating the number of game-time

---END QUOTATION---



game.time ()), which overflows just once per game month (more precisely, 4294967295 ms, which is approximately 1193 hours, ie, 49 days).

Therefore need to use game.get_game_time()


---QUOTATION---

Now that I think about it, game weather management should use game.time()

---END QUOTATION---



I do not recommend! Described above

Can be considered from the beginning of the game. Just read the date (start_time and start_date) in alife.ltx

--' parsing!
local d1, d2, d3 = string.match( system_ini():r_string( "alife", "start_date" ), "([%d]+).([%d]+).([%d]+)" )

local t1, t2, t3 = string.match( system_ini():r_string( "alife", "start_time" ), "([%d]+):([%d]+):([%d]+)" )

-- Set game time. Installation format: (Y, M, D, h, m, s, ms)
game_start = game.CTime() -- 
'zero' game time (CTime class object)')

game_start:set( d3 + 0, d2 + 0, d1 + 0, t1 + 0, t2 + 0, t3 + 0, 0 )
dbglog("game started at %s:%s:%s %s-%s-%s", t1, t2, t3, d1, d2, d3 )



start_callback() in the _g.script

and using in scripts


local diff_sec = game.get_game_time():diffSec(game.CTime() or game_start)



As you noted:

I has an error loading the game. Maybe because I used patch 1007. Now, of course, I deleted all the code.

I'm now lazy testing
  14:22:07  6 December 2018
profilee-mailreply Message URLTo the Top
castl
(Novice)
 
On forum: 03/27/2009
Messages: 41

---QUOTATION---
See xr_gulag.script
---END QUOTATION---



Yes it is!

if not level.patrol_path_exists then
...


Im sorry! I inserted my debug log to before this function, and here is the result

I have warning's for the look path with the invalid game_vertex_id. Not level_vertex_id. Need to edit?


---QUOTATION---
but not one for the motivation_action_manager class
---END QUOTATION---



I checked, does not work


self.object:motivation_action_manager():remove_evaluator(stalker_ids.property_danger)

For the dead? Can you use this method?

I thought it was for a alive and to method engine!

example:
manager:add_evaluator(xr_evaluators_id_script_combat,property_evaluator_const(false))-- Disable engine evaluates!



It turns out game.get_game_time() is not present when smart is initializing

I was wrong when I wrote

local diff_sec = game.get_game_time():diffSec(game.CTime() or game_start)

sorry: need..


local diff_sec = game.get_game_time():diffSec( game_start or game.CTime())

return diff_sec



I do not know where to write, but I had crushing in the game:

Critical: SMapLocation binded to non-existent object id"

According to my tests, any critical error is not related to the arena at all.

For example:

I removed the logic from all.spawn in ltx. And I forgot, by inattention, to remove the link to the file already in logic

I did not work correctly with the package

I also had this error when I forgot to specify the function parse_names and output the raw string.

Therefore, I conclude - this error is a marker


illegal instruction

I got this error. Incorrect work with tables

stack trace:
001B:01DE6EBC xrGame.dll
001B:01DE7029 xrGame.dll
001B:01E33550 xrGame.dll


self.object:set_home(self.st.home, minr, maxr, self.st.aggressive)

Path was unavailable!

I was fine with the paths and coordinates. It turned out that the restrictor was to blame

restrictor_type = 0 ; warning!

I replaced by on the

restrictor_type = 3
  11:58:07  16 December 2018
profilee-mailreply Message URLTo the Top
castl
(Novice)
 
On forum: 03/27/2009
Messages: 41
My edit was wrong! Sorry stalker's.

File: heli_combat.script

self.center_pos = packet:r_vec3()

and

self.enemy_last_seen_pos = packet:r_vec3()

This is incorrect method for readinf r_vec3((



After loading the save, I had a helicopter hanging and did not react to anything, even the logic was inactive. Here is the log:


initialized = true
self.enemy_id = 0
self.enemy_last_seen_time = 26353
self.can_forget_enemy = true
self.enemy_forgetable = true
self.enemy_last_seen_pos = nil
initialized = false
initialized = false
initialized = false
initialized = false
initialized = false



here it comes to reading self.enemy_last_seen_pos and then the self.initilized variable returns false


After revert


initialized = true
self.enemy_id = 0
self.enemy_last_seen_time = 124112
self.can_forget_enemy = true
self.enemy_forgetable = true
self.enemy_last_seen_pos = [870.75622558594:50.606002807617:-48.983951568604]
self.enemy_last_seen_pos = [870.75622558594:50.606002807617:-48.983951568604]
self.combat_type = 2
self.change_dir_time = 4294499840
self.change_pos_time = 126530
self.flight_direction = false
self.center_pos = [870.75622558594:50.606002807617:-48.983951568604]
initialized = false
initialized = false
initialized = false
initialized = false
initialized = false



As you can see the vector is read

Therefore, return everything as it was, This error can lead to broken saves!



NarVac,
Why do we need this code? In the save method?


			if self.change_dir_time == nil then
				self.change_dir_time            = t
				self.change_pos_time            = t
				self.center_pos                 = self.enemy_last_seen_pos
				self.flight_direction           = random_choice( true, false )
			end



I did not notice anything like this! If an error has occurred, this is a corrupt save.


I think


			if self.change_dir_time == nil then
				dbglog("! 2Heli_combat:save:change_dir_time == nil HOW???")
				packet:w_u32(4294967296)
			else
				packet:w_u32 (( self.change_dir_time or 0) - t)
			end



and load method:


time_ = packet:r_u32()
			if time_ ~= 4294967296 then
				self.change_dir_time = time_ + time_global()
				--logf("self.change_dir_time = "..tostring(self.change_dir_time))
			end




So more right...
  02:43:46  18 December 2018
profilee-mailreply Message URLTo the Top
Kev2k
(Novice)
 
On forum: 12/12/2018
Messages: 17
Which ZRP version most fits to use in the SDK?

I am currently trying to use ZRP 1.09 in SDK 0.4, however I am encountering multiple duplicate items and when I generate game_graph the level rostok gives a level_changer error. Can anyone tell me if ZRP 1.07 fits with SDK 0.4?
  12:35:19  18 December 2018
profilee-mailreply Message URLTo the Top
100RadsBar
100RadsBar - Formerly known as LoboTheMan
(Resident)

 

 
On forum: 06/03/2009
Messages: 1634
ZRP 1.09 XR3a

Just did a speedrun of ZRP 1.09 XR3a.

Doing mainly the main quest, and a few sidequest.

Only 1 crash were the game froze. That was the very last level just before the last portal to the end-game movie.
I did not think to get the crash log, but the error could not be reproduced.
So I guess it was just a onetime event.

Other than that, it ran smoothly, I did not any other mods this time, I only used the modifier program to tailor the options to my liking.

The dialogue with the C-Consciousness does still has a quirk though.
It seems that the last word in each sentence is cut.

I did report this before, it seems that I am the only one with this issue.

It could be that I am running the GOG version which is patched to 1.0006 if I remember correctly, perhaps this has something to do with it?
I could dig up one of the installation DVD's and patch that to 1.0005 and see if that "error" persists
  07:32:19  1 January 2019
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4259
That's a very good point about game.time(), castl. It's even worse because the clock starts around 8:45 on April 29 (I was off a day counting backwards); when converted to game days the vanilla starting value is 5.865, so game.time() will wrap around 43.845 game days later.

Despite the wraparound, maybe it might work out for job.begin. The math always subtracts job.begin from game.time() before comparing, so the result might still be reasonable if the operation conforms to normal 32-bit register arithmetic which would ignore math overflow. For example, a current game.time() of 1000 minus a large job.begin of, say, 2000 before rollover, would yield 3000.

If it doesn't, at least the resulting error is not seen in most gameplays. Correcting it with a CTime object would need to convert it to/from something compatible with a 32-bit storage slot for game save compatibility.

There is a minor issue in xr_gulag.script in that the clear_dead() function will only idle a job opening 600 * 1000 game milliseconds. With the default time_factor of 10, this means the game will wait just 60 seconds after the former jobholder dies before asking for replacements for that job.

I'm thinking of a global variable (say, global_seconds) that keeps track of the number of seconds, a variable that is written on saves and read on loads, to which the current time_global() is added after being divided by 1000 before being written to a save. Calculations would be based on time_global() plus this global_seconds. This would give a clock lasting over 49,700 days.

---QUOTATION---
>> See xr_gulag.script

Yes it is!

if not level.patrol_path_exists then
...


Im sorry! I inserted my debug log to before this function, and here is the result

I have warning's for the look path with the invalid game_vertex_id. Not level_vertex_id. Need to edit?
---END QUOTATION---


Neither vanilla nor ZRP has the test for "not" there. Since the test checks for the patrol path name "yantar_zombies_kamp_4" combined with "_task" and that test is true for this modified path in the center_point test, the unmodified path is not used, as I said previously.

Even if there are warnings for the unmodified path in your tests, it doesn't matter in vanilla/ZRP. It seems the only purpose of that path's existence is to provide the base name for the modified path. But you can edit it for use in mods if you want.

---QUOTATION---
self.object:motivation_action_manager():remove_evaluator(stalker_ids.property_danger)

For the dead? Can you use this method?

I thought it was for a alive and to method engine!
---END QUOTATION---


I don't know whether the remove_evaluator() method can be used for the dead. I only suggested it because you were still having the evaluators called on dead NPCs in your game or your testing, something that is not a problem for vanilla or ZRP as far as I know.

---QUOTATION---
I do not know where to write, but I had crushing in the game:

Critical: SMapLocation binded to non-existent object id"

According to my tests, any critical error is not related to the arena at all.

For example:

I removed the logic from all.spawn in ltx. And I forgot, by inattention, to remove the link to the file already in logic

I did not work correctly with the package

I also had this error when I forgot to specify the function parse_names and output the raw string.

Therefore, I conclude - this error is a marker
---END QUOTATION---


Please search this thread for instances of SMapLocation, where I note that any removal of a close NPC body (while that body has a map spot on the minimap because it is within 50 meters of the player in default vanilla/ZRP) can result in SMapLocation and CMapLocation errors in the log file, and that this leads to game corruption with later saves. The game does not crash when the error occurs, but the orphaned map spot is going to confuse the game when loaded from a save.

This does not mean that it only occurs in the arena. The workaround I implemented does fix it for the arena, and for the arena only. The error doesn't always happen with the arena but it happens often enough to warrant a fix. My remark to you on this thread's page 350 was in the context of the vanilla arena save function error you found, from a bad loop index caused by using the hash (#) length operator on a table with non-numeric indices. If you are deleting bodies on your own in the arena, the ZRP arena fix won't apply.

This error is mentioned on page 296 by BobBQ (for the arena, before the ZRP fix; a reference to comments on page 124) and then by me, in reply to bamah because his game was crashing when he removed NPC bodies (non-arena) on a timer using alife():release(), and on page 297 by bamah noting that the problem was fixed by not removing those bodies. You might try what he was thinking about: removing the spot before removing the bodies.

Other causes mentioned include NPC bodies destroyed in Whirligig and Vortex anomalies if you are close enough; as I mention on page 342 in this thread, check your console log if that happens and reload an earlier save if so. The Pripyat stadium is a common location for this error.

I mentioned back in 2008 (page 102 in this thread) that deleting bodies caused this problem, but at the time I speculated that maybe Whirligig/Vortex anomalies didn't have the problem and that we should emulate what the anomalies did -- but this was before I discovered it can happen anyway, as mentioned on page 121 and clarified a bit on page 122.

---QUOTATION---
I was fine with the paths and coordinates. It turned out that the restrictor was to blame

restrictor_type = 0 ; warning!

I replaced by on the

restrictor_type = 3
---END QUOTATION---


I suspect that restrictors using type 0 are meant for Marked One triggers, not NPC triggers.

>> My edit was wrong! Sorry stalker's.

I've reverted it. However, I don't think that's a problem; both seemed to work in my tests. I think lua_help.script is incomplete here. Also, the added ZRP level changers and anomaly removal code works with the returned value, but has problems with the passed-reference approach.

---QUOTATION---
Why do we need this code? In the save method?

			if self.change_dir_time == nil then
				self.change_dir_time            = t
				self.change_pos_time            = t
				self.center_pos                 = self.enemy_last_seen_pos
				self.flight_direction           = random_choice( true, false )
			end


I did not notice anything like this! If an error has occurred, this is a corrupt save.
---END QUOTATION---


Actually, the crash occurs on a save attempt, so no corrupt save is made. The game is not corrupt at this point but it has a bad value resulting in an exception (crash) when attempting to subtract a number from nil. There is an initialization problem; the helicopter changes states but the associated data with the new search state is not initialized. This old hack code of mine prevents a crash by providing that initialization for the entire array of variables for the state when a save is made.

Interestingly, the code in round_update_flight() is commented out; the game is not even using this change_dir_time value at all, just saving and loading it.

There may be other issues as well, but they don't manifest in any game corruption that I can see. Since the game is not even using the value, the decade-old hack was sufficient even though it was not an ideal solution. I still looked more closely at this because you brought it to light here.

It turns out that it is just change_dir_time that is not initialized, in the search_initialize() function. (And search_setup_flight() ignores the arguments passed to it, but that's relatively harmless.) Meanwhile, it is initialized in round_initialize(), but the associated combat type combat_type_round is not even checked during saves/loads.

The fix is to just include the line

    change_dir_time = 0

early in the search_initialize() function. If the variable is ever used, it can work with the same approach used for change_speed_time and change_pos_time. This simple change also prevents the original crash with less overhead.

All this leads me to think that perhaps the combat_type test in the save()/load() functions might have been intended for combat_type_round...

And thank you for continuing to find and report problems, castl!
  07:36:19  1 January 2019
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4259

---QUOTATION---
Which ZRP version most fits to use in the SDK?
---END QUOTATION---



Kev2k, welcome to the forum. I don't recommend using any version with the SDK. There are tests in the vanilla code for the SDK's editor which are removed from the ZRP for speed; search the script code in gamedata\scripts for editor() tests and note the ZRP remarks about it (e.g., se_zones.script). It's just easier to work with the original database files for simple changes.

As for the duplicate items, my guess would be that there are some ZRP optimizations which override the original game files, but somehow the SDK is loading the original files as well as their replacements. One error that some modders encounter is from extracting the gamedata.db* files in the wrong order (needs to be in ascending alphanumeric order with numbers first), but I don't know if you are doing that here.

I'm not sure why a level changer for the Rostok level would have trouble. I believe the only changes were to position (for aligning the Rostok west side's LC with that of the east side; this change should have no effect on the SDK) and to an additional level changer marker (which is not part of the all.spawn but is added when each session is loaded). A lot of the level changers were adapted to provide a better rejection position and/or a better destination position/orientation.
__________

---QUOTATION---
Only 1 crash were the game froze. That was the very last level just before the last portal to the end-game movie.
I did not think to get the crash log, but the error could not be reproduced.
So I guess it was just a onetime event.
---END QUOTATION---


100RadsBar, I also have had one such crash while going through the teleporters. It happened when I took down a Monolith exo master, and the error indicated it could not find a particular ammo item in his inventory. While examining the NPC upon reload, it turned out he had both SS190 and AP ammo, and the SS190 had a different ID number than the ID for the SS190 that was missing according to the error message. I suspect that the original SS190 was deleted by the death_manager script because the NPC was using the AP ammo which it left for the game to handle, but the game somehow wanted the old SS190 ammo as well, perhaps from a combination reload/ammo type change. It might be fixed by not having the NPC's weapon have more than one ammo type.

But the error report is key to knowing the cause. You could try running with the -silent_error_mode option on the command line so the archived log info won't be overwritten in your logs\ folder when any crashes occur. (This is if the log file gets written at all. You might be able to dump the contents of the clipboard (ctrl-v) into an edit box after the crash if it doesn't.) The option also prevents some lockups. If a crash still locks up your PC, you might be able to kill the task with info in this thread:

---QUOTATION---
"Trick to kill the game if it locks-up"
https://www.gsc-game.com/main.php?t=community&s=forums&s_game_type=xr&thm_id=17066&sec_id=16
---END QUOTATION---



---QUOTATION---
The dialogue with the C-Consciousness does still has a quirk though.
It seems that the last word in each sentence is cut.

I did report this before, it seems that I am the only one with this issue.

It could be that I am running the GOG version which is patched to 1.0006 if I remember correctly, perhaps this has something to do with it?
I could dig up one of the installation DVD's and patch that to 1.0005 and see if that "error" persists
---END QUOTATION---


I wouldn't expect the GOG audio to be that different than the 1.0005 version. I am wondering if there is something unique in your audio setup causing this, as quite a few others are running with the GOG version and ZRP without mentioning what is an obvious issue. It might be audio driver related. Do you have a special audio card, or the usual audio found integrated into the motherboard of most PCs these days? Maybe there is something online that might identify a cause, like an operating system quirk.

I thank you for excruciatingly going over the same levels again. I hope to have an alternate all.spawn available in the future that has a much-more-challenging last level with different teleport paths and more puzzles to solve, among other vanilla-compatible all.spawn changes, should you ever want to run that gauntlet again.
  10:51:48  4 January 2019
profilee-mailreply Message URLTo the Top
100RadsBar
100RadsBar - Formerly known as LoboTheMan
(Resident)

 

 
On forum: 06/03/2009
 

Message edited by:
100RadsBar
01/04/2019 11:14:56
Messages: 1634
@NatVac:
The crash I had was a one-off, so no worries there.

Regarding the audio clipping out, I tried with the CD version with patch 1.0005, ran it on my own PC, and another PC, and it did not happen there, so I guess the installation from the GOG version has a bug or something .

I have not had any crashes during the speed-run.
I will start a new game and take a little more time, doing side-quests, and more exploring.
But to my experience it is stable.

I did add the following mods to ZRP:
OWR3 (requires some editing to make it work)
Darker Nights
Absolute Nature by CrommCruac
Absolute Structures by CrommCruac

So far they work fine

Did you ever consider moving the level-changers to "extend" maps?
They did it in Priboi Story, and I moved some more of them in the Overhaul.
It helps to get the loot of NPC's that die beyond the level-changer.
 
Each word should be at least 3 characters long.
Search:    
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-2019 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.