Jump to content

Tehnomaag

Members
  • Posts

    129
  • Joined

  • Last visited

About Tehnomaag

  • 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.

Tehnomaag's Achievements

Hunter

Hunter (4/15)

43

Reputation

  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. 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.
  8. 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.
  9. 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:
  10. 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.
  11. 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.
  12. The problem with auto-agro sleeper volumes (for example, in Red Mesa) is that this argument about it being "mostly sltealthable" based on internal volume distribution of auto agro volumes is that this is not really representative of the difficulty/danger of the POI. The "normal" sleeper areas are not low difficulatly because they are normal sleeper, but because regardless of your build the zombie distribution is low enough where you can do these parts relatively easily without stealth as well. The zombies in there come in ones or twos, which is kinda fine, stealth or no stealth. When you reach an area where stealth would actually matter (a room with 8+ opponents, some being feral/irradiated at higher gamestages) THIS area is set to auto-agro. Completely invalidating the points invested into the stealth perks WHEN IT WOULD ACTUALLY MATTER THE MOST. So that is where the argument that the POI is "mostly stealthable" fails, because it is not in the parts where it actually matters, i.e., the POI is, for practical purposes "not stealthable". Unless one cheeses ofc by triggering, blocking the doorway or going through the wall and doing the POI backwards. But that is not stealth - that is just cheesing the POI by using workarounds outside of stealth.
  13. Based on the disdirbution of sleeper volume flags posted in this thread earlier, it appears that this assesment is not entirely true. Only 1.6 % of POI's have "awake" sleepers, while approx third have auto agro sleeper volumes according to this distribution. So as far as I can see "vast majority" of players who think they were victims of an auto-agro sleeper volume actually are entirely correct. As "awake" sleeper volume flag is utterly under-represented in the distribution, compared to the normal sleeper volumes and also compared to auto-agro-sleeper volumes.
  14. I am sad to report that after some testing this does not affect missions at all. It appears that the modlet only changes the trader normal/special shop refresh time, but with this modlet the trader is still offering 5 missions per day, refreshing them every day. There must be a separate line in the xlm somewhere that is related specifically to the missions, I have to assume.
  15. I am happy to report that the edited modlet seems to be working now (a19.1 b8). It is day 32 currently in my game and the next trader restocking day is day 38. I have added the JaxTellers relevant modlet where I have added the additional lines for the new traders in a19 to change the new traders restocking days as well. The Modlet messes with Joel further, but for all the rest of the traders all it does is increasing their restoking interval from 3d to 7d. It should do, to some limited degree, what the OP is asking for .. by increasing the restocking interval the total number of trader missions per day is roughly halved, effectively (was 5 missions per 3 days, now is 5 missions available per 7 days). EDIT: However, this modlet, apparently, does not "fix" the trader missions issue. The trader, after some testing, still offers 5 missions each day. JaxTeller718_TraderBalances.zip
×
×
  • Create New...