Jump to content

Tehnomaag

Members
  • Content Count

    125
  • Joined

  • Last visited

Community Reputation

38 Excellent

About Tehnomaag

  • Rank
    Hunter
  • Birthday 03/20/1979

Personal Information

  • Location
    Estonia

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hm that would make some sense I suppose. Otherwise it would be very hard to make a zombie rush from a little distance away if one starts opening some looooong open time container (like ammobox, for example) I have observed in some custom POI's in compopack. But if it would be possible to define a relatively tight additional volume around the container, linked to some further away volume it would be easy to arrange.
  2. Does anyone know if only and only the SleeperVolumeFlags determines the behavior of the zombies of the given sleeper volume or does there exist some other triggers as well that make the sleepers attack the player upon entry or reaching a certain point or touching a certain container? For example, what does the SleeperVolumeGroupId determine considering there also exists a SleeperVolumeGroup setting that seems to point to a setting defined somewhere else of what type zombies can spawn in a given volume?
  3. Seems fair. I mean it is kinda modding even if it originally started as a complaint about POI design decisions. Have been testing this everything awake (flag 1) for few days now. The zeds do seem to be more alert now, however, I really cant figure out if they still auto-attack sometimes or they are just really really alert sometimes. I suspect there is some other trigger somewhere as well that makes them attack upon entry. But I cant really claim that with high confidence as its an already running map I updated with these scripts, our "combat" characters are heavy armor and zero stealth skills and when they get into a tier 5 quest POI it's ... uhh ... I suppose more brutal when it used to be with auto-attack volumes and normal blind/deaf normal sleepers. The second you fire a unsilenced gun most of the POI will beeline to the location of the shot. My own char is not really combat as I'm a support (farming/cooking/salvage/crafting benches) with some points thrown into agi to be able to clear smaller poi's on my own. I'll attach the updated and now working scripts to this message as well, because the ones in my previous post, one of them had the mistake Kalen pointed out. The "2_to_0" makes all auto-agro volumes into the normal braindead sleepers, and the "0_to_1" turns all the normal braindead sleeper volumes into the "awake" ones, that are supposed not to auto attack upon entry but be really alert and attack you when you get near them (like the normal random walking zed in the wild) AAA_script_0_to_1.vbs AAA_script_2_to_0.vbs
  4. It appears that the answer to the question I asked in the first post is "yes". With the help of Kalen on page 17 of the linked thread inspiring this question I have managed to get the scripts working and a dedicated server was able to boot up using the modified prefab files. There is 2 scripts - one changes all the auto attack volumes into normal passive sleeper volumes (2_to_0 script) and a second one changes all the normal passive sleeper volumes into "awake" sleeper volumes (the 0_to_1 script) where the sleepers are a bit more alert and tend to take note of your presence if you step into their field of vision. If someone wants to use them then change the path to the prefabs folder to the one used in the machine running the script. The attached scripts assume default steam installation on disk C. If the map is already running any POI that has been already visited might not update. Preliminary testing (on an already running multiplayer server) did not highlight any game-breaking problems, although it must be noted that in one of the tested POI's one room still did the scripted attack event on player - its unclear if it was because the POI had been already visited in the past or there was a separate trigger rigged up for that event. AAA_script_2_to_0.vbs AAA_script_0_to_1.vbs
  5. Does anyone know if there is some other flag/mechanic than the SleeperVolumeFlags that makes the zombies in a given volume attack the player upon spawning? Got around poking in only few POI's last night after updating all the SleeperVolumeFlags in the game to be "1" (i.e., awake) - the zeds appear to be somewhat more alert as few waked up somewhat easier than before, especially, when sneaking into their apparent field of view, so that is interesting. But in one tier 3 fetch guest (compopack poi, so not vanilla thing) there were 6 zombies that spawned and attacked the player. I'm not so much having an issue with the fact that they did (it made sense in that location and was cinematically nicely done, with 6 of them breaking out of their graves in a burial site) but wondering that how ... if all the sleepervolumeflags were changed. Granted this is already playing map, so it is expected that not all the changes will register in all the POI's - but the assumption was that when a trader gives a mission to a POI and POI resets that then the POI would be loaded again from the prefabs folder and then the changes might register for a given POI. Is this assumption incorrect if someone knows?
  6. Yeah. I was myself thinking of the same, that it would be really cool if there would be a way to set a volume flag to a random value. Ideally it would be done in-engine, but failing that a script running on a timer server-side might do something like that as well. The script worked now. Server booted just fine so its time for me to go poking and seeing how it goes. Thanx for the script and for the help in getting it to work for me.
  7. Heh. Thanx. Yeah I see now what I did. I kind assumed that the line I changed checks if the SleeperVolumeFlags has a value that is not equal to the number behind it. So it made a perfect sense that if its not 0 go look up all the 2's and change them to 0 and in the next script if its not 1 go change all the 0's into 1's. Ofc I should have spotted that mistake by more carefully checking the resulting xlm files and taking note that ALL the zeros in the file have turned into 1's and that is not the intent.
  8. Thanx for checking. It is possible that it is something that is installed on my side which causes the edited XLM files to update from version 1.0 to 1.1 causing this issue. Although if it is it must be something which is shared between my PC (W10 Pro) and the machine running our dedicated server (W8.1 Pro). I'll add an example file's for the red mesa. The original is clearly at xlm version 1.0 while the one after running the script twice is the version 1.1. I'll add the two versions of the script as well I used, but I doubt that it is something I did there, because all I did was leaving, basically the 2 to 0 script as it was and in second script replaced the 2 with 0 in the condition and the 0 replacing 2 with 1 - but it should not target the xlm version, because the script very clearly targets only contents of the SleeperVolumeFlags. Regardless, now that I know that on your side everything works as it should then I know that its not the script itself that is an issue but something in the environment I'm running the script in. Another thing I should probably check is if my client installation is content to use these prefabs in single player and its only the dedicated server installation that has a problem with the xlm files version maybe. installation_red_mesa.xml installation_red_mesa_original.xml AAA_script_0_to_1.vbs AAA_script_2_to_0.vbs
  9. The script works, in the sense that it goes and replaces all the "2" in SleeperVolumeFlags with "0" so it does exactly what is needed. However, the modified XLM files are failing to load. Apparently 7d2d uses XLM version "1.0", however, the visual basic, apparently, decides to save the files as XLM version "1.1" which, in turn, makes 7d2d to throw a tantrum when trying to load such an XLM file. 2020-10-14T18:48:02 32.634 ERR Failed parsing XML (skyscraper_03): 2020-10-14T18:48:02 32.635 EXC Version number '1.1' is invalid. Line 1, position 16. XmlException: Version number '1.1' is invalid. Line 1, position 16. I'm myself more of a Fortran and Python person, so any way you know from the top of your head to fix this small hiccup before I start googling and trying to figure this out on my own? BTW thanx for the script again. I used it to first turn all auto aggro volumes into normal sleeper volumes and then ran it again to turn all normal sleeper volumes into "awake" (flag "1") ones for the currently running multiplayer server we are using to test how such a thing behaves on an already running server.
  10. Well ... we have the loot quantity significantly reduced as well. If my memory serves me correct we are currently playing at 33% loot quantity. And delete_all_on_death provides a consistent item sink to avoid the game being "done" the second you get a good Q6 armor and weapon with the right mods. So yeah ... them settings. Cant really complain about them, since we choose to set them ourselves. We are currently a bit over 200h in on our current map and it is still going strong. Full winter biome, no roads, as rough as it gets so there are bottomless cracks everywhere, all the cities set to wasteland. Its amazing how "hostile" one can make a map with Nitrogen and few manual edits to the biomes image. Compopack as well. So its not really vanilla experience at this point. Some "designers" in the compopack have gone even crazier with auto agro volumes than the official vanilla poi's normally do. There are mansions with entire floors going bat@%$# crazy the second you set a foot on the stairs leading there and beeline straight to you from all over the building. Throwing 30+ green men at you all at once from all directions in gamestage 100+.
  11. Kinda depends on the settings one is playing at. My time estimates are based on playing with few slider cranked somewhat up. For example zombie speed can make a quite large difference in a difficultly of a given POI if one encounters an auto aggro room. At some settings just standing your ground in a light armor against a green swarm rolling in your direction can be a bit riskier strategy than when they are moving a bit slower. And ofc we do not mine in our current game, wich is kind of self inflicted handicap, but ammo is kinda scarce still and reserved for situations where things get particularly hairy.
  12. I would not call it "fear". Its more of an nuisance, annoyance, frustration, etc. After the first few auto-agro rooms it is not that hard to connect the dots. Then it is what ... about dozen different buildings, at most, if even that where the game sends you for missions so you know your eyes closed how, exactly, will this POI play out. Doing them over and over and over again ad nauseum. Like in red mesa (tier 4), for example, get next to the small tower, make hole in the wall, shoot all the sleepers in the head, get endgame loot head downstairs, there is 2 more auto agro rooms and then it no longer matters from where you come.
  13. A fully combat specced character (steel armor, sledgehammer) does a lev 5 clear mission in about 30 minutes. With some variation depending on a POI. Let's call it "up to 45 minutes" to be on a safe side. Ofc a sneaker or not so combat focused character could spend hours on doing one, with all the auto agro rooms and then having to run away, stealth and wait for the zombies to settle down again and then circling back to get stealth kills on them.
  14. Following that argument to its logical end. MAJORITY of sleepers (2/3, roughly) are pretty passive and you have to basically step on their fingers to get them to wake up. It is that about 1/3 of the sleeper volumes react to a player presence in given volume and not something that player does "wrong". If one includes the wilderness zombies as well (a minority, of total zombie population as you pointed out) I'd say that roughly 20 to 25% of all the zombies a player encounters are these auto agro ones.
  15. That is confusing. A hypothesis why the dedicated server test might "fail" - if the server transmitted POI files are cached client side somehow the local files, which the client believes to be the correct server-side configurations might get used resulting in passive zombie behavior while server-side they are set agressiivse, supposedly. That is quite a stretch hypothesis, though and I'd consider that to be somewhat improbable, as as far as I understand it, the zombies are, supposedly, controlled server-side. Another possibility might be that when a poi is visited the server somehow stores somewhere the state it was when it was visited and upon a next visit no longer loads the POI from the prefabs folder but actually picks up the stored copy of the POI with all the changes a player might have done when visiting it the previous time (all the broken walls, removed trash, looted containers, zombies already killed, etc). In that scenario, if you change the POI SleeperVolumeFlags in prefabs after the POI has been already visited by any player it might not register until someone gets a mission there and resets the POI, at which point I'd assume it would be freshly loaded from the prefabs and the new SleeperVolumeFlags register. By your description of what you are doing I do not believe it would be something that would be done "wrong" on your side. After-all, chaning the SleeperVolumeFlags in the POI xlm is a relatively straightforward action. It just seems to be more of a case, that the server-client interaction is a bit more complicated than one might at first assume. Thanx for the tests. There certainly is a fair bit of food for thought. However, I'd say that preliminary tests are promising to a degree. They show that it IS POSSIBLE to change SleeperVolumeFlags server side and these changes migrate over to the client side somehow (i.e., it would be sufficient, theoretically, to update the relevant xlm's server side). The open question is if it is possible to get these changes to register on an already running server and map or is the only sure what to do so upon a fresh map/server before any players log in.
×
×
  • Create New...