Jump to content

Tehnomaag

Members
  • Posts

    129
  • Joined

  • Last visited

Everything posted by Tehnomaag

  1. Thanx Boidster - this script you modified indeed works just fine. If the server is running it notes so in the command line, waits the designated time (in seconds) and cheks again. If it is not running it opens a new command line window and starts the startdedicated.bat script and server indeed spins up upon my testing. Just the thing I was looking for!
  2. Thanx guys. This script is just the thing I was looking for. I'll give it a try later today. As far as server console drawing blank after the "server is starting" line in the console upon first run after a restart - that is a regular occurence for me as well. My workaround is that I start the server, then kill it after about 30 seconds and then just run the starting script again and normally the server console window starts updating then. After I have done it once after the machine restart the next server runs normally update the console log just fine. Fortunately I restart that machine on which the server is running relatively infrequently, every few months or so. A question on the script - can the timer for cheking the condition of the server be includuded in the script itself? So that I do not have to include it in the scheduler but can just run the script in the command line or powershell. The motivation for that question is that sometimes when I change servers (we from time to time try different mods) it would be mildly annoying if the scheduled script would try to spin up a server while I'm working on configuring it. That way I could just close the CMD in effect stopping the script from running for a little while and when I'm done just open up the command line again and re-run the server cheking script. Ofc doing it that way would mean leaving a command line open in the background but that would not be a problem, I presume, on a dedicated server. EDIT: The script is not quite working. When I close the server and run the .bat script it first, gives an error message that it cant find 7DaysToDieServer (which is expected ofc) but then tells me that the server is starting, including the 15 sec timer from the main start script but the server itself will not spool up. That is after I added the relevant "..." marks to get around the error message that D:\7 is not a known command because of spaces in the path.
  3. I am running a small private dedicated 7d2d server for myself and few friends. However, the server crashes from time to time, not frequently but at least once a week or so. This is a bit annoying as it often happens when I have already gone to sleep and my friends have to wait then with their things until I wake up and are able to restart the server. So the question is - what do you use to chek if the server is running and re-start it if it has crashed? The server is running on a dedicated physical machine with Windows 8.1 operating system. Basically what I am looking for is something that cheks if there exists a task in task manager called "7DaysToDieServer" and if it does not exist then run a "D:\7 Days to Die Dedicated Server\startdedicated.bat" script. This would ideally happen every few minutes or so.
  4. what are the constraints on using your own heightmap? grayscale png? max 256 levels between full white and full black? compression or no compression? what I'm trying to achieve is rather rough terrain 8x8 km map with significant amount of water between mountain peaks, basically, what I would like to do would be just taking the already generated heightmap and increasing water level by +25m or +50m and then re-running the map-gen for building placement. how would I go about achieving that? when I tried editing the heightmap the Nitrogen refused to import it.
  5. 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.
  6. 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?
  7. 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
  8. 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
  9. 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?
  10. 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.
  11. 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.
  12. 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
  13. 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.
  14. 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+.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. Is there a resource/documentation somewhere, if you know which would explain what flag does what in the POI xlm files? For example, there are "2" and "0" values in the "SleeperVolumeFlags", for red mesa. Does each sleeper volume have one flag only (i.e., does red mesa have 24 different sleeper volumes set up out of which six are auto-aggro)? What are the other valid flags? "0" is "normal sleeper", "1" is passive, "2" is auto agro. But .. there is supposed to be also "awake" state for a sleeper I understand? Is it "1" or "3" or something else, as an example? After thinking about it for a while and starting a new thread in the modding subsection of the game - based on discussion going on it that thread (i'll add link to it to the end of this post for the sake of completeness) it appears to be logical that the POI xlm files would be either "cooked in" into a map during a map gen (and downloaded by the players upon joining a server) or would be read server-side when a player enters the POI and then transmitted to a player from a server. Otherwise the system would be far too open for an abuse of anything clientside could override the server-side settings. This is an disctinction I am wondering about, as if the POI xlm is loaded by a server when player enters it it should be possible, theoretically, to override it by a server side xlm modlet. If the POI is "cooked into" map files during map gen then it might be a fair bit trickier to do anything about it at any later change with an xlm modlet. That might also explain, to a degree your observation that "Only manually editing the XML file worked." - if it was done prior map gen then it would imply that POI's are cooked into map files. If it worked on an existing map after manually editing the relevant xlm file for the POI it would imply that it is possible to change SleeperVolumeFlags for POI's on an already existing map by running a script changing the relevant flags server-side post map generation. As promised, link to the relevant thread in modding section as well:
  21. That would make sense. If such a change would be required only at map generation and POI's would be "cooked in" during generation that would simplify things to a degree, as then it could be indeed, only server-side. I'm not sure about compopack to be honest. As we usually play with a pretty closed group of players when we do a fresh map using a different compopack I'll just ask the players to install the relevant compopack on their side as well usually. This time one of the guys claimed he forgot to install the latest compopack and that the map loaded fine for him, so maybe nowadays they are cooked in? I think that back in a18.4 it used to fail if the player did not have compopack installed? Maybe I'm misremembering though. The install instructions of the current compopack just ask the user to copy the right stuff into prefabs folder without specifying if its needed only on server side or both server and client side. However, based on what you say - it seems to me very logical that the sleeper volumes would be handled strictly server side because, as you pointed out, it would be too open for abuse to have anything from clientside to override what the server has in this regard as that way a player could just "switch off" zombies in the POI's client side. So it would be logical that the POI's are either cooked in during map generation into the map itself (which is downloaded by the clients during first joying the server) or the server is using prefab files from the server prefabs folder (in which case it would be possible to update sleeper volumes of an already running server, I suppose).
  22. The question is in the title. The motivation for the present thread is a discussion about failures of stealth gameplay in the general section of the present forums and an issue some people have with auto-agro sleeper volumes (link in the end of this post). In that thread on page 9 Kalen posted a simple VB script that should, in theory, go over the POI XLM files in a given directory and change all auto-agro sleeper volumes (flag 2) into "normal" sleepers (flag 0) Const ForReading = 1 Const ForWriting = 2 sFolder = "C:\[Folder where prefabs are]\" Set oFSO = CreateObject("Scripting.FileSystemObject") For Each oFile In oFSO.GetFolder(sFolder).Files If UCase(oFSO.GetExtensionName(oFile.Name)) = "XML" Then ReadFiles oFSO, oFile End if Next Set oFSO = Nothing msgbox("Processing Complete") Sub ReadFiles(FSO, File) Set oFile2 = FSO.OpenTextFile(File.path, ForReading) Do Until oFile2.AtEndOfStream strLine = oFile2.ReadLine if instr(strLine, "SleeperVolumeFlags") <> 0 then strLine = replace(strLine, "2", "0") end if strText = strText & strLine & vbCrLf Loop sFile = File.path oFile2.close set oFile2 = Nothing Set File = FSO.OpenTextFile(sFile , ForWriting) File.Write strText File.Close Set File = Nothing end Sub That is pretty cool, in my opinion. However, what this basically means is doing a custom POI pack which means that both the server and clients would need to have it. It is not clear at all to me if it is even possible to do that change after the map has been already generated or if such an change would need to be done even before a map generation. What I would like to try, actually, would be a situation where ALL sleeper volumes in all POI's are set to "awake" state (flag 1). Now before I start messing about with scripts doing changes to the POI files I would need to understand a bit more about what does what in the POI xlm files, exactly. Is there such a resource available somewhere? Must the sleeper volume changes be made before map generation? Or are the sleeper volumes loaded from a file only after a player enters the POI and, thus, could the changes made to a already running server? Are the sleeper volumes loaded from the server side or must they be both server and client side? For example, I look at the "red mesa" POI xlm file <?xml version="1.0" encoding="UTF-8"?> <prefab> <property name="CopyAirBlocks" value="True" /> <property name="ExcludeDistantPOIMesh" value="False" /> <property name="ExcludePOICulling" value="False" /> <property name="DistantPOIYOffset" value="0" /> <property name="AllowTopSoilDecorations" value="False" /> <property name="QuestTags" value="clear,fetch,hidden_cache" /> <property name="ShowQuestClearCount" value="2" /> <property name="DifficultyTier" value="4" /> <property name="TraderArea" value="False" /> <property name="Zoning" value="industrial" /> <property name="AllowedTownships" value="wilderness" /> <property name="RotationToFaceNorth" value="2" /> <property name="EditorGroups" value="government" /> <property name="YOffset" value="-23" /> <property name="SleeperVolumeSize" value="29, 3, 17#13, 3, 27#9, 3, 1#24, 3, 16#16, 3, 2#1, 2, 1#10, 3, 12#11, 3, 11#10, 3, 6#16, 1, 10#24, 3, 13#5, 4, 7#16, 4, 19#9, 2, 9#4, 5, 4#11, 7, 24#4, 3, 2#14, 6, 13#3, 3, 9#8, 3, 5#7, 3, 7#11, 2, 13#21, 3, 3#11, 3, 2" /> <property name="SleeperVolumeStart" value="31, 23, 31#18, 23, 44#40, 18, 60#32, 14, 30#40, 14, 46#37, 15, 47#39, 29, 48#16, 14, 42#19, 18, 68#30, 2, 57#33, 2, 27#56, 2, 41#32, 8, 29#48, 8, 15#28, 8, 37#31, 6, 49#27, 6, 46#15, 19, 30#26, 26, 33#18, 26, 34#17, 14, 63#60, 8, 12#49, 10, 15#18, 26, 31" /> <property name="SleeperVolumeGroupId" value="1,1,1,2,2,1,1,0,0,0,0,0,3,0,3,4,4,0,5,5,0,0,0,5" /> <property name="SleeperVolumeGroup" value="S_-_Group_Zom_Soldier,0,1,S_-Group_Generic_Zombie,2,2,S_-Group_Generic_Zombie,1,1,S_-_Group_Zom_Soldier,3,3,S_-Group_Generic_Zombie,2,2,S_-_Group_Zom_Soldier,0,1,S_-Group_Generic_Zombie,1,1,S_Zom_Utility_Worker,1,1,S_Zom_Utility_Worker,2,2,S_-Group_Generic_Zombie,2,2,S_-Group_Generic_Zombie,2,2,S_-Group_Generic_Zombie,1,2,S_-Group_Generic_Zombie,3,3,S_Zom_Utility_Worker,1,1,S_-_Group_Lab_Worker,1,1,S_-_Group_Lab_Worker,4,4,S_Zom_Utility_Worker,2,2,S_-Group_Generic_Zombie,1,1,S_-_Group_Zom_Soldier,4,4,S_-Group_Generic_Zombie,0,0,S_-_Group_Lab_Worker,1,1,S_Zom_Utility_Worker,1,1,S_-Group_Generic_Zombie,1,1,S_-_Group_Zom_Soldier,4,4" /> <property name="SleeperIsLootVolume" value="False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False" /> <property name="SleeperIsBossVolume" value="False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False" /> <property name="SleeperVolumeFlags" value="2,0,0,0,2,0,0,0,0,0,0,0,2,0,0,2,0,0,0,2,2,0,0,0" /> <property name="SleeperIsQuestExclude" value="False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False" /> <property class="Stats"> <property name="TotalVertices" value="1905279" /> <property name="TotalTriangles" value="1876287" /> <property class="BlockEntities"> <property name="Vertices" value="1406927" /> <property name="Triangles" value="1513608" /> </property> <property class="ChunkMeshes0"> <property name="Vertices" value="396055" /> <property name="Triangles" value="252024" /> </property> <property class="ChunkMeshes1"> <property name="Vertices" value="0" /> <property name="Triangles" value="0" /> </property> <property class="ChunkMeshes2"> <property name="Vertices" value="3000" /> <property name="Triangles" value="1548" /> </property> <property class="ChunkMeshes3"> <property name="Vertices" value="438" /> <property name="Triangles" value="244" /> </property> <property class="ChunkMeshes4"> <property name="Vertices" value="62781" /> <property name="Triangles" value="50311" /> </property> <property class="ChunkMeshes5"> <property name="Vertices" value="0" /> <property name="Triangles" value="0" /> </property> <property class="ChunkMeshes6"> <property name="Vertices" value="0" /> <property name="Triangles" value="0" /> </property> <property class="ChunkMeshes7"> <property name="Vertices" value="36046" /> <property name="Triangles" value="58536" /> </property> <property class="ChunkMeshes8"> <property name="Vertices" value="0" /> <property name="Triangles" value="0" /> </property> <property class="ChunkMeshes9"> <property name="Vertices" value="32" /> <property name="Triangles" value="16" /> </property> </property> <property class="IndexedBlockOffsets"> <property class="FetchContainer"> <property name="0" value="60, 3, 43" /> </property> <property class="Rally"> <property name="0" value="53, 23, 1" /> </property> </property> </prefab> It appears, that red mesa, as an example, has altogether 24 sleeper volumes? Can I just change all the 24 flags in "SleeperVolumeFlags" to "1" to turn all volumes into "awake" volumes? Or is it a bit trickier than that? Or would it be truly that simple that I could walk through all the XLM files in a the prefabs directory and change any "SleeperVolumeFlag" that is not "1" into a "1" server-side and that would do it? If it could be made post-map-generation then an server side xlm modlet overrriding given prefabs would be possible? This is the link to relevant thread in "general":
  23. Hm. I get that the devs have some kind of specific vision. If that is particularly essential they could disable these suggested options for the Navgezene map. Unfortunately me and people I play with are not particularly interested in playing THAT game. For us this is a cool sandbox to play in and we tend to go in a different direction by pushing things a fair bit off from the official (vanilla) settings making it a fair bit more challenging for ourselves. To the point we even adopt few "house rules" which are not supported by the configuration options of the game. As an example, the current map we are on is 8x8 km full winter biome with all cities mostly bombed to wasteland. Landscape is 100% mountains, vicious cracks, as rough as it can be made, no roads - making going anywhere pretty brutal. We have 8x increased wandering horde size, x4 increased wilderness zombies. Day speed is 2 (run), night speed is 3 (sprint) [we did try nightmare as well, but the zeds start glitching a bit too much on nightmare]. Default difficulty settings (because making zeds bullet sponges does not seem to affect difficultly that much compared to adjusting zed speed). Day lengths is 3 hours (so 45 min night). There is single trader (took us about 90h to find it, as we deliberately did not preview the map and as there is no forest trader there is no initial quest leading to it). Delete all on death, so if you die you start again naked. Loot quantity set to 30%. House rules are: no underground mining (we can pick up boulders lying around but basically, no mining), not doing/bying/using machines with engine (cement mixer, power tools, vechiles, etc), no nerd-poling (you can get to roof but have to use ladders or build stairs - i.e., zeds can follow you). This is very different from vanilla experience, but after about 160h on this map we are still happy as clams, while in vanilla with no house rules we are bored after 20h at most or so. In a nutshell - we play for the initial struggle. We love the limited resources aspect and if after 160h on a map we still have to count the bullets and decide if it is the right time to use them. cool. Death should matter for us and oh boy it does. It hurts quite a lot to lose your carefully collected set of Q6 armor and mods when you have to start again from scratch, basically, after losing them. In such a context getting randomly murdered by an invisible flag is a bit more frustrating, I suppose, than in vanilla. But that is not the point. The point is, 7d2d is as popular as it is is predominantly because it allows players the choice of tailoring an experience THEY want to play. An OPTION to configure the sleeper volume behavior would extend that aspect of the game and, basically, fully neuter the underlying frustrating aspect of the game motivating the starting of the present thread. This should be technically relatively easy optional override to add for the devs, considering a simple script capable of doing that (by editing the POI files in a given directory) was already posted in the present thread on page 9 if I remember correct.
  24. If the problem is the yellow floating "!" mark. That is a relatively easy to handle by just inserting there some kind of "quest start container" or box or pole which seems more fitting. Say, for example, bright colored "Beware of zombies" sign in front of POI to press "E" against to start the quest. Double clearing as such, as others have noted several times already in this thread already, is not a "problem" in my opinion, because you are "doing" the POI the same way, basically, like you could do any POI in the world. Be it then killing everything or nerd-poling straight for the roof. In fact, it is probably more efficient to just pick another quest considering how good the quest rewards currently are. In vanilla settings the POI's are supposed to be done over and over and over again. Because in vanilla settings there is a loot respawn in POI's turned on after a certain time interval. And - if someone is after a particularly harsh playthrough - one has always option to enforce no traders on the map and turn off the loot respawn and opt to not mine resources - for that true scavenger of the apocalypse feel.
  25. An updated journal entry for stealth should do the trick and would be probably the right place to disclose the existence of auto-agro volumes. Ideally there would be an option, during the game setup to choose to override the sleeper volume behavior. Say, default (sleeper volumes behave as set by the POI designers) all auto-agro (all volumes rush you upon entry) all awake (the most underused flag, zombies are fully awake and with all senses on, but to no rush you outright before detecting you) all asleep (the "normal" sleepers upon whom you can practically step before they take note of you) all auto-agro volumes are instead turned into "awake" volumes would be ideal. That way all the people who are happy as clams with the things as they currently hare can just not change that option, while all the people who do have some kind of problem with things as they are have an option to choose something that fits them better. I personally would love to try a play where all sleepers are awake. So if you step into its line of sight, tough luck. Being stealthy would actually matter as you could bring the whole house down your way if you get too noisy. But there is an *option* to get through the POI without zombies attacking you.
×
×
  • Create New...