ProjectsWhat's NewDownloadsCommunitySupportCompany
Forum Index » S.T.A.L.K.E.R.: Shadow of Chernobyl Forum » Mod discussion
[Help - Bug] Empty Crates...

Posted by/on
Question/AnswerMake Newest Up Sort by Descending
  11:39:56  1 November 2016
profilee-mailreply Message URLTo the Top
Storm Shadow
A machine, a Shadow Machine.
(Resident)

 

 
On forum: 11/14/2007
Messages: 1421
[Help - Bug] Empty Crates...

Hey all,

I'm having a weird bug, in that every breakable crate, box or case is always empty, no matter what. No random spawns inside of them, not even the items that are meant to always be in them, as per all.spawn, etc.

What is the script that controls the item spawn on box destruction? I have tried rolling back my bind_physic_object.script, xr_box.script and some other likely candidates, but no joy.

Any help....

Cheers,

Shad
  11:52:40  3 November 2016
profilee-mailreply Message URLTo the Top
Storm Shadow
A machine, a Shadow Machine.
(Resident)

 

 
On forum: 11/14/2007
Messages: 1421
Further testing shows there is more to this bug I'm having than just the empty boxes, there's more.

Many of the ingame interactive physical object appear broken, or can't be interacted with, or won't respond correctly to their scripts. For example:

- The levers in the underground labs can't be thrown, this fully breaks the story line.
- The gateway into the bar level changer at the Duty blokpost in Garbage won't open when scripted to. It can be nudged open, or shot open regardless of whether you have satisfied Warrent Officer or not.
- And other such things like this are appear broken too.

Call me crazy (again), but I just feel like all of these things are related to the same bug, or some such. I haven't played Reb for about a year, so I can't fully remember where I was at when I last put it down, but I was integrating and testing the ZRP 1.07 r5rc, I may have made an error somewhere, but I'm not sure where.

Any help.....
  00:05:28  4 November 2016
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
 

Message edited by:
NatVac
11/04/2016 7:15:25
Messages: 4261
Hi, Storm Shadow.

Those symptoms suggest a problem with missing or dropped scheme attachments.

The recent ZRP versions would deliberately crash at game launch if there is a problem with a scheme script file loaded by modules.script.

But this isn't happening. First verify that modules.script is valid by putting a debug line at the very bottom of the file:

dbglog("modules.script: schemes loaded")

I would expect the line to appear in the log. If not, check for syntax errors in your changes there.

The next suspect for dropped schemes is too much processing at session load. (A game session is loaded when starting a new game, changing levels, or loading a save, for those who are following this thread.)

This could happen in vanilla. Generally doors would become inert (Sid's door, doors in Dark Valley or Yantar). It isn't that common, and I suspect quicksaves made while the game was "Synchronizing..." as not all schemes would be fully attached until the level was displayed. (I had to abandon one approach to making unique autosaves: saving the game while it is synchronizing resulted in a lot of dropped schemes.)

More often mods were the cause, especially those that loaded and dynamically parsed scripts on the fly. Recent mods are always doing processing in the background, but the problem solely occurs if this processing interferes with object initialization.*

That's what I'd check first. You can approach most broken doors and fix them with the "Repair Nearest Door" ZSU script (enable ZSU and install the desired scripts first). For the underground switches, there's the "Repair X16/X19 Switches" ZSU script.

The Garbage gate maintained by the Duty blockpost guys is treated as a door, but you'd have to modify z_repair_nearest_door.script to recognize it. Replace "physic_object" with "physic_destroyable_object" in line 18 and "door" with "gar_physic_destroyable_object" in line 19, change the first line's "Repair Nearest Door" to "Repair Garbage Gate", save the changed script as z_repair_garbage_gate.script, then load a Garbage save and get within 10 meters of the gate and execute the script from the ZSU menu (Esc Z).

If the ZSU scripts fix the doors/switches, then see if you have the same problem with an autosave for the level (likely, given your extensive list of broken schemes). If so, examine your scripts for blocks of code that perform extensive processing (iterative loops over all objects, for example). Start with bind_stalker.script. Compare it with the ZRP version, then focus on the changed parts.

If not, then examine your merge with the ZRP in general. What's different in your mod versus the normal ZRP? What scripts are affected by the merge? Maybe there's something in xr_logic.script.

Do you have a backup from an earlier time when this problem did not exist? If so, the changes may point to a cause, or at least narrow the search range.

__________
*...Unless the mod is mucking with STATE_Read()/STATE_Write() operations -- STALKER is not thread-safe -- but such script packet manipulation collisions with normal game operations result in corrupted games and saves, not just dropped schemes. This ongoing manipulation is what gives quicksaves a bad reputation. (If you don't always instantly return to the main menu after pressing the ESC key, don't use quicksaves.)
  13:18:55  11 November 2016
profilee-mailreply Message URLTo the Top
Storm Shadow
A machine, a Shadow Machine.
(Resident)

 

 
On forum: 11/14/2007
 

Message edited by:
Storm Shadow
11/11/2016 13:22:04
Messages: 1421
Hey NV, my favorite Texan friend, really good to hear from you and I hope your RL is treating you ok these days. Thanks for taking the time for such a detailed post.

After a lot of rolling back to previous versions and testing, and then rolling back only certain files/folders, as you suggested, I eventually found what the culprit was. I feel a little embarrassed I didn't try all this before making this thread, as it really was an obvious step in my fault finding. It had nothing to do with the ZRP at all, as I had changed the binding for physics_destroyable_object in system.ltx, once I put that back everything started working normally again.

But this lead me to wonder why I had been messing around with that in the first place, when I put stalker down over a year ago. So, some further testing reveled I had been trying to figure out some weird bugs I was having in stancia, being:

1. The exploding part of the wall, just prior to the gate in the first part of stancia. The animation plays and the wall explodes, but the physics dosen't remove the broken part of the wall and dosen't create the hole in the wall that's meant to be there so that you can't sneak through without having to go through the main gate. I don't know why this is.

2. The BTR-60 APCs that appear, if I destroy one, I get this CTD:
Expression    : fatal error
Function      : CScriptEngine::lua_error
File          : E:\stalker\sources\trunk\xr_3da\xrGame\script_engine.cpp
Line          : 73
Description   : <no expression>
Arguments     : LUA error: ...chernobyl\gamedata\scripts\bind_physic_object.script:170: attempt to index local 'victim' (a nil value)

And this occurs regardless of whether I use the vanilla bind_physic_object.script or my modified Reb version.
169| function generic_physics_binder:death_callback(victim, who)
170|  	printf("_bp: generic_physics_binder:death_callback: obj='%s'", victim:name())
171|  	if self.st.active_section then
172|  		xr_logic.issue_event(self.object, self.st[self.st.active_scheme], "death_callback", victim, who)
173|  	end


3. Not related to the other things at all, but I was wondering what controls the physics of the ragdolls after death. I mean that when any creature or stalker dies, their rag doll is still a physical object in the game world for only a short time, that can be interacted with. Such as pushed when I walk into it, or stood on top of. However, after a short time, they turn into a ghost, still visable, but I just walk right through them as if they weren't there at all (they can still be searched and picked up and dragged though).

Sorry I didn't reply to you earlier, I've been away for a little while with work and will be away a little while longer. I haven't had a chance yet to look into if there may be anything wrong with my xr_logic.script or bind_stalker.script. Do you still think these could be a fault with the other issues I'm experiencing?

Cheers again mate,

Storm

EDITS: formatting
  11:28:38  14 November 2016
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
 

Message edited by:
NatVac
11/14/2016 11:32:18
Messages: 4261
I don't know why the broken part of the wall is not being removed. I don't remember it happening in any ZRP game. It may be possible to use the event to trigger a delayed process to check for the block and remove it if necessary. That's a treatment of a symptom and not a treatment of the cause, so it is a last-resort workaround.

As for the crash: The victim is apparently not there by the time it is used in the death callback script. You can comment out the printf() statement in line 170 to fix that. Hopefully either the scripts that are run to handle any subscribed events can deal with the nil victim or they don't care (they often just give an info_portion or activate something like opening a door if you break a lock) or there aren't any. We can fix the first if needed and the other possibilities don't care.

Speaking of commenting out the printf() statement: If you need a vanilla script, I suggest using the ShoC_Treatment files. They already have the printf() statements commented out, plus other vanilla fixes.

Why do anyone want to do that? Because the printf() calls are generally worse than useless even at best: they don't do anything except result in some game lag in normal conditions, and can even result in a C-stack overflow due to too many nested calls. Every argument is evaluated before it is passed to the printf() statement, and there the results are ignored in vanilla -- typical printf() processing calls a function that is only enabled in debug mode. You can add custom debugging statements where they are really needed.

>> I was wondering what controls the physics of the ragdolls after death.

That ragdoll behavior is active at death and removed/disabled when the body stops moving. It is reactivated when the body is moved, by being picked up or struck by bullets/grenade fragments, or by the addition or removal of inventory. This motion can result in rubber-banding bodies or bodies embedded in walls, endlessly jerking in an attempt to come to rest, which is not possible while body parts intersect with any other physical object.

But that is just observation, not an answer to your question.

---QUOTATION---
I haven't had a chance yet to look into if there may be anything wrong with my xr_logic.script or bind_stalker.script. Do you still think these could be a fault with the other issues I'm experiencing?
---END QUOTATION---


Those scripts were mentioned as the likely source of extra processing due to mod additions, processing that might be affecting the attachment of schemes. But you have located that problem: the physics_destroyable_object binding.

There are other problems, like the crash in the south-side NPP level. That's likely due to the Rulix weapon manager doing something similar to the death manager: deleting items that are still in use by other items. In the death manager, that was the default ammo deletion when an NPC died while reloading. While this was fixed in the updated death manager support I gave you, the weapon manager is deleting a weapon while it is being processed by the box processing (I'm still investigating this).

The complaint I have is that this problem may be rare if you are not using patch 1.0006. That patch has introduced several regressions as it addressed minor issues, regressions due to changes in sections that probably did not need changing. (A regression usually refers to the re-introduction of a bug that was fixed in a prior patch. I use it to describe a step backwards in any update that should be going only forward -- "two steps forward, one step back" is a common phrase used to describe this situation.)

Among the regressions is the crash from using an object directly from a body's inventory (e.g., eating/drinking food or using bandages/medkits). We've had several iterations of 1.0006 to address the changes in multiplayer server support, the death of GameSpy and the forcing of vertical sync. None fixed the existing engine crashes in the game, and instead added the crash mentioned, as well as making other crashes like the ammo deletion crash more prevalent. And I'm fairly certain that the 1.0006 security vulnerability is still there.

So I'm not enamored by a patch that fixes things that didn't affect me in the first place, and instead takes away my ability to eat or heal on the go using what I find in the field. What's worse is the effluent flooding the log files.

Sorry. What was I saying before encountering that rabbit-trail? Ah, other issues. Besides the crash, there's also some lag in vanilla and sometimes significant lag in any heavily-modified game. I've been working on that as well, but it involved a serious re-write of quite a bit of the code base. The pauses when AI comes online due to the loading of resources is still there but it is significantly reduced, and disappears in instances where those resources have been previously loaded (cached).

That change is guaranteed to break mods. I'm currently adapting the AIPack and Rulix extensions to work with it, even though I've not yet isolated that weapon manager crash any finer than "somewhere in rx_wmgr.script".

An alternative to the rewrite is simply to extend the switch_distance value in alife.ltx to something like 800 or 1200. While this is a sure-fire way to remove virtually all of the lag if your PC can handle the increased load, it causes issues with NPC over-awareness of distant threats and affects the results of battles, as they can now be over before you even show up on the scene. Yet this is a very possible solution, and it would fix the bug with the Dark Valley bandits not attacking the Duty blockpost until you get within switch_distance of their normal campsite in the bandit base. Incidentally, this is another regression. Once upon a prior patch, this scenario actually worked as expected...

Meanwhile I've a lot of work keeping me occupied including the game fixing, so no worries on response times. I hope you can enjoy as much as possible of your time spent doing whatever it is you are doing.
  12:52:46  20 November 2016
profilee-mailreply Message URLTo the Top
Storm Shadow
A machine, a Shadow Machine.
(Resident)

 

 
On forum: 11/14/2007
Messages: 1421
yeah thanks heaps man, again you've pointed me in the right direction.

Turns out that last time I was using the SHOC Treatment repacked, but this time I've done a fresh install and haven't installed that. So, by copying the fixed up SHoC Treatment bind_physic_objects.script into my mod, and tweaking my binders in system.ltx, I've got it back to working 100%. I won't bore you with the details.

I still intend to do more testing of the e_parent entity crash in Stancia, it's on my list.

Cheers again bro.
  07:34:09  21 November 2016
profilee-mailreply Message URLTo the Top
Storm Shadow
A machine, a Shadow Machine.
(Resident)

 

 
On forum: 11/14/2007
Messages: 1421
Sorry, I was quite tired when I made that last post.

I meant that the boxes/cases/BTRs are destroying correctly now. I still haven't solved any of the other problems yet, like the brick not being removed from the wall. I will take a closer look into your proposed solution of scripting it to remove.

I use the Rag Doll mod, so I don't have too much of that rubber banding effect. I only really noticed this the other day, as I was staking up a pile of dead bodys to try and use them to climb up onto a high object. Otherwise I prob would've never even noticed. Is there any way to tweak these values of when they turn into ghost objects?
  01:48:43  27 December 2016
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4261
>> Is there any way to tweak these values of when they turn into ghost objects?

I have not seen any script code that affects this. It's probably in the engine. This is the answer I should have supplied in my earlier post.

I'm glad you fixed your box/case/BTR bugs, especially the crash due to printf() trying to use a non-existent object.
 
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.