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 ... 270 271 272 273 274 275 276 277 278 ... 369 | 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
  17:37:00  8 June 2012
profilee-mailreply Message URLTo the Top
ZaGaR
Skaarj Hybrid - NaPali survivor
(Resident)

 

 
On forum: 07/24/2007
Messages: 647
Thanks for the clarification NatVac. I was never bothered myself from this. This vanilla "feature" came back to my memory after playing russian mods that, as we know well, do not use ZRP, or even bfa for that matter. Immediately, the cheater that is in me , woke up craving for tons of mint condition weapons .

I simply brought it up, because of the also very old "bug-or-feature" argument, in the view of the intentions to provide a closer-to-vanilla config for those who want.


==Better and darker nights for ZRP==

This thread:
https://gsc-game.com/main.php?t=community&s=forums&s_game_type=xr&thm_page=1&thm_id=14695&sec_id=16
brought back to light this simple and fully compatible solution from mariner7 to vanilla's disastrous illumination. It is simply a reworked weather_default.ltx that helps, at a certain extent, with the absurd bright nights and light-shadow problems. Combined with ZRP's option for default weather on all maps would do a great job. No scripts, textures or whatever are involved, so compatibility should be 100%.

The drawback is the generation of continuous sun direction coordinates in the log, for the segments of time the sun_dir is outside vanilla boundaries. Once upon a time there were performance drops attributed to this. Personally, in all my gaming rigs, I never had any trouble with it.
  23:36:03  8 June 2012
profilee-mailreply Message URLTo the Top
MrSeyker
Senior Resident
 

 
On forum: 03/21/2010
 

Message edited by:
MrSeyker
06/08/2012 23:39:01
Messages: 427

---QUOTATION---
==Better and darker nights for ZRP==

This thread:
https://gsc-game.com/main.php?t=community&s=forums&s_game_type=xr&thm_page=1&thm_id=14695&sec_id=16
brought back to light this simple and fully compatible solution from mariner7 to vanilla's disastrous illumination. It is simply a reworked weather_default.ltx that helps, at a certain extent, with the absurd bright nights and light-shadow problems. Combined with ZRP's option for default weather on all maps would do a great job. No scripts, textures or whatever are involved, so compatibility should be 100%.

The drawback is the generation of continuous sun direction coordinates in the log, for the segments of time the sun_dir is outside vanilla boundaries. Once upon a time there were performance drops attributed to this. Personally, in all my gaming rigs, I never had any trouble with it.
---END QUOTATION---



Already looking into his nights to see if I can make a better transition that doesn't mess around with the sun direction isssue.
  19:00:55  9 June 2012
profilee-mailreply Message URLTo the Top
ZaGaR
Skaarj Hybrid - NaPali survivor
(Resident)

 

 
On forum: 07/24/2007
Messages: 647
Trojan says it can't be fixed, it is coded in the engine. For same weird reason, GSC has hardcoded the sun above real, geometric horizon, from 03 in the morning . That causes shadows on the ground from 03 - 05 in the morning, even if you make the sky black and the ambient light equal to zero , pure GSC idiocy. Anyway, I do not see a real problem here, because it concerns only two segments, if I'm not mistaken 03:00 to 05:00 and 21:00 to 23:00.

Still, there is a lot to be done MrSeyker in the direction of making the evening hours more realistically dark. The same goes for the strange evenig cloud colours. IMO the segment from 22:00 to 24:00 needs some work. There is also big differece between dx8-static and dx9-dynamic lighting. Fixing things for one is not neccessary good for the other.
  20:06:40  9 June 2012
profilee-mailreply Message URLTo the Top
MrSeyker
Senior Resident
 

 
On forum: 03/21/2010
Messages: 427

---QUOTATION---
Trojan says it can't be fixed, it is coded in the engine. For same weird reason, GSC has hardcoded the sun above real, geometric horizon, from 03 in the morning . That causes shadows on the ground from 03 - 05 in the morning, even if you make the sky black and the ambient light equal to zero , pure GSC idiocy. Anyway, I do not see a real problem here, because it concerns only two segments, if I'm not mistaken 03:00 to 05:00 and 21:00 to 23:00.

Still, there is a lot to be done MrSeyker in the direction of making the evening hours more realistically dark. The same goes for the strange evenig cloud colours. IMO the segment from 22:00 to 24:00 needs some work. There is also big differece between dx8-static and dx9-dynamic lighting. Fixing things for one is not neccessary good for the other.
---END QUOTATION---



Which is why I'm reverting the sun position to vanilla, to prevent the console flood.

I have a mod that makes the sun go from east to west (with no flooding that I recall), but the thing we have to rememeber is that STALKER is at heart still a DX8 game.

Because in static lighting world shadows (buildings, trees) do not get updated, they kept the sun rising and setting at the same location. This way you don't get the situation where the sun is right in front of you, and the shadows around you point straight to it.

So I leave daytime lighting and position as it is, and just edit the night segments going from 20pm to 4am.

I tested mariner7's weather yesterday, and while intresting, his shadows are too blueish and on static lighting still considerably bright (the fog values are messed up as well).

So what I did was make nights shift towards darker blue, and change fog, cloud and static/dynamic ambience color towards similar values.

Problem was that, while I loved how it looked on DX8, in DX9 the sky and clouds were way too bright when contrasting to the really dark ambience and fog.

In order to compensate, I had to make nights pitch dark in both. I would like something a bit brighter, but I don't understand a lot about the color values and the differences between renders to achieve a similar effect on both.

As it stands, the heavy lighting changes go from 20 to 23hs, and from 0 to 4hs.

I have a second version that cheats the engine into moving sunrise fowards so that the sun starts to come out at 5am, while delaying sunset so that it's already dark at 21hs. Cheap, but I think it works without having to add time settings.
  10:55:24  11 June 2012
profilee-mailreply Message URLTo the Top
MrSeyker
Senior Resident
 

 
On forum: 03/21/2010
Messages: 427
Found myself messing around with the Quest Overhaul, despite me saying I didn't like the changes it introduced.

I was thinking about that mission for the Unique Vintar.

Barkeep talks about how he sold the Vintar to a group of stalkers with a load of cash that was heading out to the Red Forest and got wiped out.

Well, the game by default will always spawn a group of dead ecologists by the hole in the wall that separates the forest from the road.

I believe that this group of scientists are the ones that bought the weapon, and I was thinking that perhaps one of them should be carrying it in his backpack.

I tested the _custom_ext script to see if I could change the spawn-point for the Vintar, and right now I have it spawn in the body that's further into the Monolith perimeter.


Just thought it'd be a neat change for future releases.


It's a shame the game randomizes the bodies, as the character_desc for the Red Forest describes the group as a "leader" with an orange scientist suit that carries only a pistol, and two guards in green scientist suits carrying rifles.

The leader carrying the special weapon would be ideal, but you can have a playthrough where the "leader" doesn't spawn and all the bodies are guards.
  17:08:19  15 June 2012
profilee-mailreply Message URLTo the Top
ZaGaR
Skaarj Hybrid - NaPali survivor
(Resident)

 

 
On forum: 07/24/2007
 

Message edited by:
ZaGaR
06/15/2012 18:54:01
Messages: 647
For the first time I had to play with a f..ing wide screen , one of the worst technological "achievements" of our time, and I found a small problem in the inventory screen. The resolution is 1366 x 768, a ratio approximately 1.78 causes elongation of the green item state bar to the left, beyond its boundaries. Not to mention how weird is the shape of the scopes. All this with 1.0006 which supposedly has proper support for the WS.

I could fix it, but it remains a questionable solution if it changes with every bloody ratio of the bloody "wide" screen resolutions the industry keeps throwing at us .



CORRECTION
It is the trade screen that has that green status bar problem.
  20:20:01  15 June 2012
profilee-mailreply Message URLTo the Top
Xeros612
Senior Resident
 

 
On forum: 01/05/2010
Messages: 681
Don't blame the (actually pretty good provided a proper FOV is used) shift to widescreen-focus, blame GSC for not providing very good widescreen support for their game(s).
  12:28:00  17 June 2012
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4263
Folks, let me start by apologizing for the delay in responding to your valuable input. My life is filled with storms, hail, power issues, house repair, dog issues (our "Treeing Walker Coonhound" had a bad encounter with a black Lab requiring several staples to close her neck wound; short-term antibiotic regimen didn't work and it's not fun getting her to swallow several pills a day), lack of sleep and a newly-broken tooth -- yes, another one! I didn't know the hamburger was "bone-in" -- which I've not yet found time to address.

I'll be replying to unanswered posts primarily according to initial posting order, but I will also try to include subsequent comments by the same poster in my reply. This means that you should see all your backlogged questions answered (okay, at least addressed) in the same post. If you had recently engaged in a dialog with others in this thread, you might want to read my replies to them.

What follows is a lot. Please be patient with me and help me fix typos/omissions and clarify sense by bringing such issues to my attention. Thank you.

And thanks for the feedback on the ZRP, both good and bad.
  12:37:11  17 June 2012
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4263
MrSeyker, re formatting of real weapon names:

---QUOTATION---
I think that's how I had them working in that file I descibed to you in that other thread, but I did not point that out (like I said, in retrospect, those descriptions were a tad bit incomplete and/or confusing).
---END QUOTATION---


Even if your real weapon/ammo name comments had been perfectly clear to someone else, I am non compos mentis when it comes down to interpreting others' verbal descriptions. I just thought you didn't send me the weapon description text because you wanted to keep that for your own mod. I regret that I gave you credit, which means you got the blame for something you didn't do (e.g., ERForman's reasonable assumption).

---QUOTATION---
I like properly formatted names, but if you want, NatVac, we can either revert those two back to vanilla format, or use that format for all ammo types.

Personally, I rather leave the new format and sacrifice a bit of visibility from the fire-mode display, but it's your call.
---END QUOTATION---


Well, we could shrink the font or go multiline. For simplicity I'm thinking we just remove the "mm" on the names that don't fit. It can't be many. Useability trumps orthogonality, but if we have to have orthogonality we can always just remove "mm" from every instance and just add "cal." or similar to the others. (I'm not a weapons specialist, but I play one in CoD. --j/k!)

>> Was wondering if it'd be correct to change all silencer references to supressor.

Probably. I'm flexible if the change is a small impact. For example, four of five files changed are already changed for other reasons, or the changes are used multiple times. This stuff will also impact internationalization.

Related aside: I like Kayback's analysis on suppressors in this thread:

---QUOTATION---
"Weapon customization"
https://www.gsc-game.com/main.php?t=community&s=forums&s_game_type=xr&thm_id=11484&sec_id=14
---END QUOTATION---


__________

---QUOTATION---
Also, there must be an alterative to "noiseless and flameless sniper fire" that crops a number of times in the descriptions.
---END QUOTATION---


Lots of alternatives, but few that everyone will agree on. I would use something like "A special sniper rifle with an integrated suppressor for reduced sound and muzzle flash" for the Vintorez description and "designed for special forces operating in conditions demanding inaudible and invisible fire" for the AS Val (close to one of Steelyglint's more serious suggestions ).

Re binocular "new" position: That's a "bug" introduced in 1.0003 to show off the binoculars model by raising the HUD at-rest position without fixing the animation distance. My initial workaround was to restore the old behavior which had the advantage of being mostly out of the field of view. But since we are already including both, I'm for the change for the new position. Now, do we make w_binoc.ltx.new_position the default w_binoc.ltx?

And I'm not surprised that the third-person knife bug wasn't fixed until now and that the FN2000 suppressor is positioned wrongly because the FN2000 doesn't take a suppressor in vanilla. Since we're including both weapon files for other reasons, this is a decision I can make even in my state of constant sleep deprivation.

But I'd be willing to include a mesh for a third-person fix only if it is small. There are a couple of fixes I've not included because they are large and available elsewhere, like the Pripyat ghost garages/invisible walls fix. (Okay, that one can be small if you are willing to run the batch file that comes with SoCPUP to extract and patch the 4.3MB level file.)

I like the idea of individual weight customization of the explosives for carrying, and without even seeing your changes I'd agree that the weather config descriptions need reworking -- what's "normal" weather? or "good"? And the Actor.cfg changes sound good, too.

---QUOTATION---
Also changed a number of default values in Actor.cfg so that it uses the exact values of Vanilla files.

Pet peeve of mine, for instance ZRP's default jump_speed value is "6", in vanilla it's "6."
---END QUOTATION---


I recall changing some files to keep SMM from deleting them simply because they were the same as vanilla (e.g., the box/crate stuff). Other changes might stem from an OC thought that every millisecond counts, and the decimal is superfluous. Also that change is in an optional file; vanilla is not changed.

>> I rather the files deviate from vanilla as little as possible.

I also would like files to be close to vanilla for those doing compares, but this legacy stuff is not clean, as you know. Even you have a willingness to change them; see the legacy reference below. And just for the fun of it: Compare Decane's official QO files with vanilla.

>> NatVac himself has added mods into the ZRP that go beyond fixes.

Yes, I included mods that everyone asked for (SANB, Ammo Aggregation, Quest Rewards, etc.) and am slowly disabling the ones considered important (R3 no longer has AA enabled by default). They generally address annoyances or have other usefulness. The MonoMartyrs and Artifact Swap were left in from the demo, but I didn't remove them because feedback was positive and they were instructive. (The MM code doesn't exceed a maximum population; no runaway spawns or stack overflows.) They address annoyances like how to make freeplay less boring and how to reduce micromanagement in the game -- even making a game out of doing so.

Few are default, and all can be enabled/disabled at any time, with the exception that the QO stuff is considered one-way because the weapons spawned are not removed via checkbox, although you can destroy them.

Now why did I include those mods? Although I think Explosives Carry is a cheat, the idea is to give folks options. By including the mods after adjusting them to play well with one another, I provide a third-party equivalent workaround to in-game mod management that is not a part of STALKER. (Yes, you already know this, but many don't.) There's no need to deal with merging icon_equipment.dds files to get QO and EC to work together, and you get a brighter pseudodog tail bugfix to boot.

This makes it easy for the consumer/player, but wears down the producer/modder by adding to the difficulty.

I'm a "function directs form" kind of guy. When it comes to form, I'm pro orthogonality, but there's all sorts of "form". One form is legacy support, where many would complain because I moved them into the future all at once and made the mod hard to merge. Another form is ease-of-use, and given that using mods in STALKER is not like using them in other games (e.g., open up a mod dialog within the game and check the checkboxes of the mods you want, then check the features of each mod you want enabled, then play), I opted for making the most popular mini-mods work together with only one extra step involved -- running the Modifier before launching STALKER.

>> Autosaves

Are you talking about utak3r's Autosave mod or your own?

---QUOTATION---
while the ZRP has a lot of input and contributors, he is still just the one person working on the patch. It's can be a lot of work for just one person with what I'm sure is a busy personal life.
---END QUOTATION---


>> If NatVac can check my changes and offer some input

I don't have a busy personal life. That's because I don't have a personal life at all! But I do look at stuff when I encounter one of those rare moments of free time... <sniff!> Sorry, bit of nostalgia there. Just send it my way, and be sure to use the proper friendly name to get past the unforgiving SS (Spam Squasher).

>> The modifier is a powerful, but limited tool at the moment.

Granted. Fixes are planned, for a time when I have a sufficiency of spare time. I used to say something like hopefully before the heat death of the universe, but now it's looking more like in the next cycle after Asimov's Multivac answers the ultimate question.

---QUOTATION---
ZRP files can get quite messy, with a number of lines that unnecesarily depart from 1.0005 vanilla files by removing spaces (which can fubar comparation with WinMerge under certain compare options), and the changes/addons he has made are somewhat inconsistent for my tastes.
---END QUOTATION---


I wouldn't say "unnecessarily" even it it were true. There might be some cases where spaces at the end of lines were removed, or spaces converted into tabs. Selecting "ignore whitespace changes" in WinMerge should have helped, though.

---QUOTATION---
His special artifcats have ";NO TRADE" parameters, but ONLY in the Freedom trader file. Is this by design or an oversight?
---END QUOTATION---


By design, to prevent an exploit found by notanumber; see my 6 Feb 2009 post on this thread's page 131. The Freedom trader Skinflint is the only one making those artifacts available. I don't care if you want to sell them to anyone else for a paltry fee that's one-twentieth of what you paid for them, not to mention the value of the artifacts exchanged.

---QUOTATION---
The QO weapons have ";NO TRADE" parameters in all of them, but without consistency. They are listed in between the vanilla weapons in all files but the Generic Trader, which has them identified and separate from the rest at the end of the file.

The last one is the ideal way to introduce the modification, why is that not the norm?
---END QUOTATION---


Ah, legacy! Well, I only changed the generic trader (i.e., NPC trading) because I had to change that file for the xStream/Rulix support. The others kept the original ZRP QO change format, to minimize the file comparison changes. It's classic Double Fanucci -- "The only way to win is not to play." (Zork: Grand Inquisitor)

---QUOTATION---
And what about the other weapons added (the special Vipers, Scopes, SIGs, the Pellet Gun)?
---END QUOTATION---


They need to be added, but I didn't consider them critical -- there's only one of each and they're special. If you sell the special scope before you get a weapon that uses it, tough. ("You've made your bread, now you have to live with it" or something like that.) The Pellet Gun isn't even a recommended option, except few read the associated help file. I guess I need to mention it in the tool-tip.

>> Gauss/Gauss ammo pricing not intended but overlooked

Well, actually (he confesses sheepishly) it is a deliberate overlook. I made it so you wouldn't sell northern weaponry to Skinflint at full price (less the cost of damage), but I liked selling that rare Gauss rifle at full price to that greedy Sidorovich. And the money was good for getting more of those pricey artifacts from Skinflint. While you're here: I guess we should fix the QO psi protection suit pricing.

We can change all this, of course. We can make it tougher, stronger, faster, at a cost of only six million dollars -- no idea what that is in rubles.

---QUOTATION---
NatVac has commented out some references to old, removed quest items from some trader files, but not in others.

This shouldn't matter, because unless you mod your game, you will never see these items in the game world.

But all commenting out does is that if you were, for instance, to spawn said items in game, you can now sell them at full price, if they have one, to anyone, unless they are marked as special items to keep.

So, why even bother to change only some files and leave the rest untouched?
---END QUOTATION---


Other than what I've said about this, I might have made some changes to support a reduced memory footprint -- no need to load in support for something not used in the game. Modders who want to use those items can add the support back in, using the vanilla files as a starting point.

I was planning on migrating the rest of the files at some point, when the interest in the game had waned sufficiently. The only thing that's actually happened is that the average age of the interested seems to have dropped considerably. Or maybe that's just an apparent side-effect of playing...

Thank you for replying to X-RaY2 on the 1.0006 bug. (Folks shouldn't be eating food directly off corpses anyway.) It's like modern game patches and mods that attempt to address issues aren't merely taking "two steps forward, one back" with each release, but are even moonwalking. "We're making progress. Negative progress, but progress nonetheless."

¯¯¯¯¯¯¯¯¯¯
Re darker nights:

>> Which is why I'm reverting the sun position to vanilla, to prevent the console flood.

How about setting the elevation maximum value to zero? It works in static lighting for me; don't know about DX9. See my post here:

---QUOTATION---
"Log being spammed with 'Current[0]->sun_dir'":
https://www.gsc-game.com/index.php?t=community&s=forums&s_game_type=xr&thm_id=21427&sec_id=16
---END QUOTATION---


Putting the sun at the edge of the fog stripe might cause a problem with the SDK (or so I hear), but that is easily changed temporarily while using the SDK.

No one remarked on it, so I don't know about the impact on dynamic lighting.

¯¯¯¯¯¯¯¯¯¯
Re mission for the Unique Vintar:

---QUOTATION---
Barkeep talks about how he sold the Vintar to a group of stalkers with a load of cash that was heading out to the Red Forest and got wiped out.
---END QUOTATION---


Yes, "nippie types". Rich dandies, newbies, dilettantes. The current ZRP QO location is not the original QO location, but it is consistent with the details Barkeep reveals about the group and there's a secret about their stuff in that spot as well. The scientists aren't there on a lark. Plus you can't remotely grab that weapon with a ZRP debug function unless you write one.

>> Just thought it'd be a neat change for future releases.
I don't think it would fit the scene that well, but it could easily be a one-line option.


---QUOTATION---
It's a shame the game randomizes the bodies, as the character_desc for the Red Forest describes the group as a "leader" with an orange scientist suit that carries only a pistol, and two guards in green scientist suits carrying rifles.
---END QUOTATION---


That's actually consistent with the lore, as the scientists are not well protected from mutants/humans, but their protective guards are. Kruglov was unusual, but his buddies were just scientists.

¯¯¯¯¯¯¯¯¯¯
Re tl;dr:

You are not really missing anything, but you can use your browser's search to check comments on topics of interest to you.
  12:40:14  17 June 2012
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4263
The links to the current Zone Reclamation Project (ZRP) download site are in the first post on the previous page.
__________

---QUOTATION---
The vanilla game.graph is 8 MB sized, but 2 MB is surplus, it has around 10 (non-existent) test maps level.graph too...
---END QUOTATION---


Bangalore, that would be a sizable reduction. So we need the SDK to rebuild the game.graph without the test levels? I'm wondering if it is like the other database files in that the compressed directory is read, but the actual resource isn't loaded until needed.

¯¯¯¯¯¯¯¯¯¯
Thanks for replying to noLife.

¯¯¯¯¯¯¯¯¯¯
>> >> I'm now experiencing quite a few exits [...]
>> >> two "can't build game path" mutant problems

>> The "cannot build game path" problem is solved.

That's good news for the spam stuff, but it might not apply to what causes those particular CTDs. Remember this?

---QUOTATION---
"anyone know how to avoid this?"
https://www.gsc-game.com/main.php?t=community&s=forums&s_game_type=xr&thm_id=20446&sec_id=16
---END QUOTATION---


(That second section's values in the wiki need to be updated.)

What that second parameter value means to me: 000 means access to normal (allowed) places, 001 means access to dangerous places, 002 means never allowed there. I was able to fix those error messages in aliVe by adding the extra lines assigning 001 to the second value as mentioned in the above thread, but I don't recall these being the direct cause of any aliVe crashes, just a lot of log spam.

The difference between this:

---QUOTATION---
! Cannot build GAME path! (object mil_dolg_stalker0006)
! CURRENT LEVEL : l07_military
! CURRENT game point position : [-410.092133][-20.844643][7.337811]
! TARGET LEVEL : l08_yantar
! TARGET game point position : [62.400002][0.000000][-18.400000]
! Target point mask [10][1][0][0]
! Object masks (2) :
! [8][1][255][255]
! [255][0][255][255]
---END QUOTATION---


and this:

---QUOTATION---
! Cannot build GAME path! (object m_tushkano_normal21511)
! CURRENT LEVEL : l10_radar
! CURRENT game point position : [376.978180][-51.199860][29.992897]

FATAL ERROR

[error]Expression : I != levels().end()
[error]Function : GameGraph::CHeader::level
[error]File : e:\stalker\patch_1_0004\xr_3da\xrgame\game_graph_inline.h
[error]Line : 171
[error]Description : there is no specified level in the game graph : 96
---END QUOTATION---


is that the first one lists the target info you reference but the second doesn't. The first is indeed fixable as you noted, but I've yet to confirm that the second would be fixed by adding entries to a mutant's terrain specification -- there's already one there. The error refers to a level issue, here it's level 96. Where did that come from? I've also seen level 0 for a tushkano game path problem. Others were for dogs: level 243, level 199, level 0. I had one for a pseudodog: level 64.

The spec for mutant terrains is given by the terrain = <section> line where "[<section>]" is defined elsewhere in the file, but the m_stalker.ltx assignment is terrain = 255,255,255,255,0,1 -- that's different.

Here are the Google translations (with my adjustments) for [location_0]:

000 = "..."
001 = "escape" (Cordon)
002 = "dump" (Garbage)
003 = "agro" (Agroprom)
004 = "agro-subway" (Agroprom Underground)
005 = "dark valley"
006 = "Laboratory X-18"
007 = "darkskeyp" (Darkscape)
008 = "Bar"
009 = "Sprout" (Rostok)
010 = "Amber" (Yantar)
011 = "Laboratory X-16"
012 = "Military" (Army Warehouses)
013 = "Dead City"
014 = "Radar" (Red Forest)
015 = "The radar bunker" (X19, or X10 if you want the typo)
016 = "Pripyat"
017 = "nuclear plant" (NPP)

Meanwhile, that location ([376.978180][-51.199860][29.992897] is the level point for a current game vertex in Red Forest, in the middle of the road to Pripyat. It's a valid spot for that tushkano. But the target level isn't printed to the log because that is what causes the error. Those reported level numbers are random.*

That implies it is not a permissions/access issue but a bad level reference issue. It is as if the engine is indexing into an invalid set of values for the target. This might not be fixed by correcting the game graph unless there are bad level references there.

Or it might be that the engine tries to find a match for a specific level first by traversing the lines in the defined section, and falls off the end (engine bug) only because a match is not found. If so, this can be fixed in either the game.graph (make the target point an an unrestricted point) or via the allowed terrain section permissions (allow 001 access to restricted areas on problematic levels).

Even if not, your fix is still a fix for at least some of these "Cannot build GAME path!" instances and useful for any modders who add new STs. I wish other smart folks were as willing to share their discoveries.

Right now this is a rare problem in a ZRP-based game, but it still does occur. At least it is not a show-stopper bug. Players can reload the last save and continue.

__________
*It may be that sometimes a random level value is in the "valid" range. Then we get a different error, like maybe "There is no proper graph point neighbour!"
 
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.