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 ... 254 255 256 257 258 259 260 261 262 ... 354 | 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
  00:06:57  26 October 2011
profilee-mailreply Message URLTo the Top
ZaGaR
Skaarj Hybrid - NaPali survivor
(Resident)

 

 
On forum: 07/24/2007
 

Message edited by:
ZaGaR
10/26/2011 15:24:42
Messages: 647
On the AI logic improvements theme.

I did some small changes to xr_camper.script that have improved a lot the behaviour of the stationary guards. Seriy and co. manage to repel and kill the bandits now. Bes' situation improves a lot too.

The script has a local variable self.a.radius that also controls this behaviour. I tried to set a debug watch for its value, but failed miserably .

I'll try to post these changes ASAP so that you guys judge yourselves if it worth at all.


======THE CHANGES to xr_camper.Script======

1- The thing I believe deals with the blindness of the camper-NPCs beyond 20m. In the original, line 548 is:
st.radius = utils.cfg_get_number(ini, section, "radius", npc, false, 20)

changed to:
 st.radius = utils.cfg_get_number(ini, section, "radius", npc, false, 80)

I used a figure equal to the default view distance.



2- There are several time limits in xr_camper.script.

Line 74 is:
if time_global() - a > 20000 then

Make it 50000 or more.
The most significant behaviour change comes from script lines ~567:
	st.post_enemy_wait = 5000 -- âðåìÿ, êîòîðîå ìû æäåì âðàãà, ñìîòðÿ â åãî ïîñëåäíþþ ïîçèöèþ.

Personally I used 50 000 and then 100 000, much better
st.post_enemy_wait = 100000 -- time we wait for the enemy, looking at his last position


Yo can also experiment with the line above it: "time to forget the enemy"
st.idle = utils.cfg_get_number(ini, section, "enemy_idle", npc, false, 60000)



If you try these things folks and see if you like what they cause. The only adverse effect I saw is the abandoning of the positions from some NPC we would prefer really stationary.
  22:13:16  5 November 2011
profilee-mailreply Message URLTo the Top
MrSeyker
Senior Resident
 

 
On forum: 03/21/2010
Messages: 403
I had a doubt.

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

Because in the readme it says:


---QUOTATION---

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

---END QUOTATION---



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

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

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

So, does this work? It affects only one lighting type? Or what?
  06:56:29  6 November 2011
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4209
Current Zone Reclamation Project (ZRP) download site:
http://www.metacognix.com/stlkrsoc/

Please read the documentation in the mod's archive before posting here. And your question might already be answered elsewhere; you can try Google with the search parameter site:gsc-game.com to check this site.

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

---QUOTATION---
"Crash To Desktop (CTD): Causes and Treatment":
https://www.gsc-game.com/main.php?t=community&s=forums&s_game_type=xr&thm_id=11715&sec_id=12

Crashes still in the game:
http://www.metacognix.com/stlkrsoc/CrashesStillInTheGame.html
---END QUOTATION---


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: http://www.metacognix.com/stlkrsoc/BugsInSTALKER.html

Feel free to mention any bugs or crashes you know that are missing from the list.

If you don't start a new game, there may be some minor problems with your saved games. The saves are modified versions of the all.spawn file present when you started your current game. Saved games based on mods might also include custom items from those mods, and support for them will need to be properly merged to avoid crashes.

¯¯¯¯¯¯¯¯¯¯
ZaGaR, some good thinking there. I'll look at some of your changes in a bit. I'd been looking at xr_combat_camper.script in the same way in the demo days, and I remember having to explicitly assign the scheme to the logic. But any NPC using xr_camper@xxx will use this scheme.

---QUOTATION---
The script has a local variable self.a.radius that also controls this behaviour. I tried to set a debug watch for its value, but failed miserably .
---END QUOTATION---


The "a" is the storage variable, the same as the st variable in the set_scheme() function. It's set in the __init() constructor function for the evaluator_close_combat class, "instantiated" by the add_to_binder() function, itself indirectly called by xr_logic's assign_storage_and_bind() function via set_scheme() for each NPC.

In English: There is a unique set of class "instances" associated with each NPC via the assigned logic for him. You would need quite a bit of info to access that data for a particular NPC, but it can be done. Get the NPC object via z.this_guy() (you can use z.this_name() in Variable Watch to know you can get the NPC object via z.this_guy()) and assign it to a global variable in Execute Script Command:

exec myNpc = z.this_guy()

Verify that it is not nil by entering the following and pressing Enter:

myNpc

(If examining the result of a function, you'd use "print" or "echo" as a prefix. See the docs.) That should return "userdata" for the object. Get the storage this way:

exec myNpcSt = db.storage[myNpc:id()]

That should be a table:

myNpcSt

Now you can look at his xr_camper logic:

exec myNpcC = myNpcSt["camper"]

If myNpcC is not nil, you can look at his "radius". (If nil, check the NPC for other logic, like "meet" or "danger". Example: Try myNpcSt["danger"].ignore_distance or myNpcSt["meet"].meet_set -- you'll have to find a variable that is part of a scheme assigned to the NPC.)

myNpcC.radius

Or you can examine it in a Variable Watch. But I don't expect it to change once set. However, you can now dynamically change it by assigning a new value to it. I don't know when that value will be re-accessed; you might have to save and reload to get it to change, and that will likely invalidate most if not all of your current global variables.

Since it doesn't change, you can just put in a debug statement in the set_scheme() routine right after you have read the value from the configuration file.

¯¯¯¯¯¯¯¯¯¯
MrSeyker, re restored sun: That is probably due to a misinterpretation on my part. I'm playing almost exclusively with static lighting (save for a bit of testing under dynamic lighting, but it is too painfully slow on my outdated gaming PC), and until I changed the weather I had not seen the sun's circle before, just the lit-up clouds. That text was already marked for change for the next release.

Re the Duty vs Freedom minimod: The version you posted to make it more accessible to me was apparently updated with a change to limit the quality of the suit you get from Voronin if you are not a member of Duty. Unfortunately the conditional test is missing an end statement in bar_dialogs.script's enter_to_dolg() function. (You'll see a strange crash referencing xrLua and xrGame DLLs in a stack trace if you talk to anyone with a <precondition>bar_dialogs.function</precondition> in an active dialog branch, or select a dialog option that uses <action>bar_dialogs.function</action>, because the bar_dialogs script object is nil.)

I took the liberty of reverting it to vanilla because that test is performed before you can join Duty, thus making the Duty equivalent of the SEVA inaccessible in the game as a reward from Voronin even if you join Duty.

Beyond that, the DvF (FvD?) minimod is working as standard fare. Do we need a conditional on Lukash's merc camp task? I ask because Freedom membership makes mercs and bandits neutral. I've not yet tested the dialog_manager change to see if the wounded dialogs appear for them yet.

Thanks for the info on the "defend border from Monolith" info_portion stuff.
  07:05:15  6 November 2011
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4209
Bug Fixes and Workarounds, part five:

Actually, this is more of a useful enhancement.

Here's a nifty way to get level-based autosaves. It copies or renames autosave.sav to <level>_autosave.sav, where <level> is the name of the level (e.g., l01_escape or l02_garbage). It should work with any version of bind_stalker.script -- ZRP is not required.

Edit gamedata\scripts\bind_stalker.script. Put this block at the top of the file, before the first line:

-- set this true to automatically copy or rename autosaves
local level_autosaves = true
-- these apply if the above is true
-- set this true to rename autosave, false to copy it
local rename_autosave = true
-- set this true to preserve your first access to a level
local keep_first_level_access = false


After this line in the file:

 	if self.bCheckStart then


insert the following block of code (leading spaces/tabs don't matter)

    local fs = getFS()
    local autosaveFile = string.lower(user_name()).."_autosave"
    if level_autosaves and fs:exist("$game_saves$", autosaveFile .. ".sav") then
      local sg = CSavedGameWrapper(autosaveFile)
      if level.name() == sg:level_name() then
        local target = level.name() .."_autosave"
        local target_save = target .. ".sav"
        local target_image = target .. ".dds"
        -- update_path info per fluffy22
        local savedir = fs:update_path("$game_saves$", "")
        local need_level_snapshot = false
        local target_exists = fs:exist("$game_saves$", target_save)
        if target_exists then
          local sg2 = CSavedGameWrapper(target)
          if sg:game_time() > sg2:game_time() then
            -- autosave is newer
            need_level_snapshot = true
          end
        else
          need_level_snapshot = true
        end
        if need_level_snapshot then
          if rename_autosave then
            fs:file_rename(savedir..autosaveFile..".sav", savedir..target_save, true)
          else
            if target_exists then fs:file_delete(savedir..target_save) end
            fs:file_copy(savedir..autosaveFile..".sav", savedir..target_save)
          end
          get_console():execute("load_last_save "..target)
          if keep_first_level_access then
            local first_target = level.name() .." - start.sav"
            if not fs:exist("$game_saves$", first_target) then
              fs:file_copy(savedir..target_save, savedir..first_target)
            end
          end
        end
      end
    end


Change the top variables to suit your needs. The upcoming ZRP 1.07 R3 release will also support your custom savegame prefix. I suggest leaving rename_autosave true; it has no noticeable effect on level transitions (when autosaves are usually made).

The keep_first_level_access variable is practical only for new games, making a "<level> - start.sav" the first time you visit each level if it is set to true. (Use all.sav for the Cordon.)

Thanks to ThunderFreak for asking and fluffy22 et alia for posting useful info in the "Changing Loadscreen" Mod Discussion thread (thm_id=21095). That's part of one item on a pending checklist of mine: "Determine formal parameters to C++ engine functions."
  19:04:56  8 November 2011
profilee-mailreply Message URLTo the Top
ZaGaR
Skaarj Hybrid - NaPali survivor
(Resident)

 

 
On forum: 07/24/2007
 

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

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

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

O looked inside xr_combat_camper.script and xr_combat_monolith.script but to me, nothing seems to be directy related to the behaviour. The logic that controls the opening of fire during patrol are is there OK, but it looks like it does nothing. Anyone has any idea where and what to look for?
  08:02:36  9 November 2011
profilee-mailreply Message URLTo the Top
Lijenstina
Doom metal in the shade of the flying radiators
(Resident)

 

 
On forum: 07/23/2005
 

Message edited by:
Lijenstina
11/09/2011 8:04:01
Messages: 1902
One interesting way of achieving new game settings from the main menu ( before the new game starts) is this.
http://media.moddb.com/images/mods/1/13/12551/stalker-20111108-165333.png

function change_the_ltx(w_ltx)
    if w_ltx then
		local f = getFS()
		local flist = f:file_list_open("$game_config$","misc\\smp_game_settings\\",FS.FS_ListFiles)
		local file_name = "smp_game_start1.ltx"   
		if w_ltx == 1 then file_name = "smp_game_start1.ltx"
		elseif w_ltx == 2 then file_name = "smp_game_start2.ltx"
		elseif w_ltx == 3 then file_name = "smp_game_start3.ltx"
		end
		local ltxs = f:update_path("$game_config$","misc\\smp_game_start.ltx")
		local name = f:update_path("$game_config$","misc\\smp_game_settings\\"..file_name)
		f:file_delete(ltxs)
		f:file_copy(name, ltxs)
	end
end



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

 [my_section1] 

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

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

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

  06:03:40  12 November 2011
profilee-mailreply Message URLTo the Top
MrSeyker
Senior Resident
 

 
On forum: 03/21/2010
 

Message edited by:
MrSeyker
11/12/2011 6:06:54
Messages: 403

---QUOTATION---
Re the Duty vs Freedom minimod: The version you posted to make it more accessible to me was apparently updated with a change to limit the quality of the suit you get from Voronin if you are not a member of Duty. Unfortunately the conditional test is missing an end statement in bar_dialogs.script's enter_to_dolg() function. (You'll see a strange crash referencing xrLua and xrGame DLLs in a stack trace if you talk to anyone with a <precondition>bar_dialogs.function</precondition> in an active dialog branch, or select a dialog option that uses <action>bar_dialogs.function</action>, because the bar_dialogs script object is nil.)

I took the liberty of reverting it to vanilla because that test is performed before you can join Duty, thus making the Duty equivalent of the SEVA inaccessible in the game as a reward from Voronin even if you join Duty.
---END QUOTATION---



DAMN!!

I had already caught that bug, but it seems I only fixed it in the files for my big mod merge and forgot to update the mini-mod before uploading.

Time to update the dowload links.


Also, I did not make any change to the mercs or bandits, and I'm not familiar with how the game handles medkit dialogs, so that will probably be an issue.

And there's one other feature I'd like to have which is a neutral Bar for Freedom allied players.


EDIT:

Well, here's a fix for that bug and now the duty reward should behave correctly if the mod is not enabled.

Old MF link is delted, but it wont let me upload the fix ATM, so only a Megaupload link for the time being.

http://www.megaupload.com/?d=CXDESXIO

Also, it bothers me that this board won't let me edit old posts.

I want to get rid of all the outdated links (Rapidshare's are gone, and the MF uploads have been changed thrice now).

EDIT2:

Delted the old post and changed the upload yet again :\

Also, the dowload links in page 253 (and probably the any other previous link to my mods posted) are now all dead.

Just follow my sig if you want to download them again.
  04:16:17  26 November 2011
profilee-mailreply Message URLTo the Top
NatVac
Senior Resident
 

 
On forum: 06/15/2007
Messages: 4209
ZaGaR, re the AI behaviour during the movement to the preset spot: What's also annoying is that they know they are getting hurt because they complain about the damage! I know there's some general path following in getting to a destination where the NPC moves from waypoint to waypoint. Either the waypoint navigation support has it, or there's a general ignore_combat setting or something similar.

I now have a z.dbstruct() function to perform a "dump" (listing) of the variables and schemes attached to NPCs. It is essentially the same as the print_table() function in _g.script (which is useless in retail versions of the game because the devs disabled the debug stuff like printf()).

Anyone can adapt the vanilla print_table() function by replacing the printf() calls with dbglog() calls in ZRP (or equivalent in your own mod), but they need to know that the original function would crash because it prints the table key index values as strings but for some reason the actions table for schemes like walker or death uses a game object (which is interpreted as userdata in the Lua script engine) as an index, and the string.format() instruction would throw an exception noting that there is no such operator to convert that into a printable string.

If you use the ZSU's Execute Script Command function to execute this command, it won't crash but it will only list the NPC's data up to the first actions table unless you check for that situation. To fix that, check if type(k) == "userdata" before you do the normal checks for type(v) -- note the check for type of the key k instead of the type of the value v. If a match, then just print a debug statement that the key is userdata. This is already handled for the next release.

¯¯¯¯¯¯¯¯¯¯
Lijenstina, re your new game configuration approach: Great minds think alike. I mentioned earlier that I would be implementing something similar for ZRP 1.1. One advantage is that a relatively-robust mod could be compressed back into a gamedata.dbn archive and use a scheme like the one you proposed for configuration.

¯¯¯¯¯¯¯¯¯¯
MrSeyker, thanks for posting the update to your Duty vs Freedom mini-mod. I still think that because the info_portion is not yet given when the check is made, one will not get the Duty equivalent of the scientific suit even if one joins Duty. It is given upon completing the quest, but you are still in the process of doing so when the check is made.

I think the medkit dialogs for mercs and bandits (as well as Monolith followers) is handled already, but as mentioned I'd not yet tested the dialog_manager change to see if the wounded dialogs appear for them yet.

I don't know what to do about a neutral Bar since it is Duty territory -- unless you mean the 100 Rads Bar itself, in which case you can just keep the lone Dutyer out. But there's still the issue of getting there without shooting any Dutyer. While you can normally shoot an enemy without changing faction relationship status, the Bar script logic checks to see if you hurt NPCs that are normally actor-neutral in vanilla, like loners, Dutyers and ecologists and puts out a broadcast noting that you are now everyone's target if you hurt Duty.

It bothers me as well that the forum won't let one edit old posts, but the reason given was ... reasonable: It keeps folks from changing posts to rewrite history. I'd like it if you couldn't edit existing text, but you could append a note, like one of correction based on new info to keep folks from doing something that isn't helpful. I suppose if one really needs the change, one could contact Don Reba.

And thanks for not shooting the messenger on the Mediafire thing. As Cassandra's heir, I fully and miserably empathize with the poor prognosticator's plight.
  18:55:56  26 November 2011
profilee-mailreply Message URLTo the Top
MrSeyker
Senior Resident
 

 
On forum: 03/21/2010
Messages: 403

---QUOTATION---
MrSeyker, thanks for posting the update to your Duty vs Freedom mini-mod. I still think that because the info_portion is not yet given when the check is made, one will not get the Duty equivalent of the scientific suit even if one joins Duty. It is given upon completing the quest, but you are still in the process of doing so when the check is made.
---END QUOTATION---



I finally get what you mean.

I wanted to make the game give you a common duty suit for doing missions for them as a loner and the duty seva for doing missions as a dutyer.

However, the game uses the enter_to_dolg function three times, and all of them are 1-time-only.

The rg-6 reward is pre-duty only, the kill-twig-reward is also 1-time-only and can be taken before joining the faction therefore locking out the duty seva, and when joining duty you get the reward BEFORE you're given the infoportion, so you never recieve the duty seva.

It's easily fixed, just give the infoportion before giving the reward.

That way, depending on how you play, you can end these missions with:

2 duty suits, 1 duty seva suit
1 duty suit, 2 duty seva suits

About the bar:

I need to modify the all-spawn to make the bar area neutral to a freedom actor (just him)? Could this be achieved by script?

As for the dialogs, I'll have to check some of the faction mods to see if they do anything to the wounded dialogs, and do some testing.


I'll update my download again afterwards.

If you think leaving the suit check out is for the best, be my guess.
  19:58:18  29 November 2011
profilee-mailreply Message URLTo the Top
ST35AL
(Novice)
 
On forum: 07/05/2011
 

Message edited by:
ST35AL
11/29/2011 20:02:54
Messages: 29
I have some great suggestions for this mod:

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

2) Increase characters starting money. 500000RU is good

3) Make traders spawn new items more often( Ammo and other stuff)
 
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-2018 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.