• Content Count

  • Joined

  • Last visited

Community Reputation

21 Survivor

About StrangerFromTheInternet

  • Rank

Recent Profile Visitors

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

  1. @Raphael van Lierop I think you may have misunderstood @codfish107's question. I think he was specifically asking for a way to change the button used in wolf struggles without changing the button used for other interactions
  2. Hi Raphael! I was really surprised when I heard that The Long Dark would be removed from the GOG store. Can you shed some light on what made you take this decision?
  3. @BareSkin I think the main problem is that TLD is really only tracking the hunger calories stat, ranging from 0 to 2500 kcal. There's simply no way to effectively differentiate between someone who's been starving for a day and someone who's been starving for a month with just that variable. I had some success creating a model with 2 variables - hunger calories and body fat calories - and simulating that in Matlab. I really hope Hinterland will implement something similar. @Sgt. Eclair I really, really love that second idea. I almost feel like that's what the cairns could have and should have been.
  4. I don't even care about official mod support that much, I kinda like the "unofficial" modding tools that the community has put together over the last two years. Moreover, I don't think that Hinterland would ever go so far as to include a tool that would let you modify the behavior of the game while it's running. In other words, I think there will always be things that can only be done with "unofficial" mods. But what I'd really like to see is an end to this prohibition around talking about modding on this forum. I feel like the only effect this has is to drive people away from this forum. And besides, what's the harm in letting people talk about mods, anyway? It's not like censoring these discussions will magically make mods go away...
  5. Last I heard, mod support would be considered after Wintermute has been completed, which could still take a long time. But honestly, I'd be very surprised if TLD ever got proper mod support. I think it's much more likely that this will end up the same as Minecraft, where mod support has been promised over and over again, but nothing was ever delivered. I'm pretty pragmatic about this whole issue. If you want to make or use mods, the tools are available right now. They may not be official, but they work, and they work well.
  6. The recent v1.27 update moved the log file to C:\Users\USERNAME\AppData\LocalLow\Hinterland\TheLongDark\output_log.txt ... but v1.29 moved the log file again to C:\Users\USERNAME\AppData\LocalLow\Hinterland\tld\output_log.txt Is this just a bug, an undesired change in Unity, or an intentional change, @Support?
  7. Still no bug fixes for custom modes? The messed up loot and wildlife spawn rates really need to be fixed, guys
  8. This post cannot be displayed because it is in a password protected forum. Enter Password
  9. Yeah, for between 3 and 5 days at a time. One can completely eradicate every single wolf and deer near Quonset gas station, but within a matter of a few days, most wildlife will have respawned. I wouldn't exactly call that "Overhunting".
  10. Heyo everyone! The recent 1.06 patch addressed save games 'going missing' on PS4. Let's now also improve save file consistency on PC! Current procedure: Here's a brief outline of how saving a game on PC currently works. In the following pseudo-code, I'm using two variables, save_path and save_path_temp, which are just the locations of the current save file and another temporary file. It's also important to know that the game only ever tries to load the save_path file, but never the save_path_temp file. if "Compressed save data fits into shared buffer": 1.1. Delete possibly existing temporary save file at save_path_temp 1.2. Write the new save state from the shared buffer to save_path_temp 1.3. Delete the old save file at save_path 1.4. Copy file at save_path_temp to save_path 1.5. Delete file at save_path_temp 1.6. Done else: 2.1. Compress the save data into a new buffer 2.2. Overwrite the current save by directly writing the buffer to save_path 2.3. Done As long as nothing unexpected happens, this code works perfectly. Failure states: This is where we get to the "What happens if something goes terribly wrong part" of this analysis. You'll see that if there's a crash while the game is saving its state to a file, it's very likely that that save file will be lost. If the game crashes between 1.1 and 1.2, the new game state will not be saved, but the current save file has not been touched yet and can still be loaded. So all is fine here. If the game crashes at 1.3 or 1.4, we're in some deep trouble, but the user may be able to manually recover their save file: The current save game has been deleted, but there is a perfectly valid save file at save_path_temp. Unfortunately, the loading routine won't attempt to load from that file. This means that the slot that the save game previously occupied will now appear to be empty. The user may be able to recover their save file by manually copying the new save file from save_path_temp to save_path. If the game crashes at 2.1, we're in the same position as in 1.1. We'll lose the progress since the last time the game saved, but that's fortunately all that happens. If the game crashes at 2.2, however, we've also lost our save file - and this time, there is no way to recover that file. The file at save_path will now contain an incomplete save state that cannot be loaded, and we never bothered to write to save_path_temp in the first place. Proposed alternative: Here's my take on how this procedure could be made simpler and more crash resistant without requiring any more computation or IO: 1. Write the save game to a buffer and hold on to it. It makes no difference whether this is the internal shared buffer or a newly created buffer. 2. If save_path_old exists, delete that file. 3. Copy the current save file from save_path to save_path_old 4. Delete the file at save_path 5. Write the buffer to a new file at save_path 6. Optionally delete the file at save_path_old and also modify the save file loading procedure as such: 1. Try loading from save_path 2. If this fails, try loading from save_path_old 3. If this also fails, both save files are corrupted: Give up and notify the user Analysis: This new procedure is more crash resistant by always trying to keep one valid copy of the save file around. If the game crashes at step 1, there's not much we can do. We could not create a new save state, but fortunately, we can still load the old game state from save_path. If the game crashes at step 2 or 3, we're in the same situation as in step 1. We have also lost an older save file at save_path_old, but this should not worry us as there is still a valid save file at save_path, which we can load as usual. If the game crashes at step 4 or 5, we will attempt to load from save_path first, which will fail because that file is either missing or not yet fully written. Fortunately, we've copied the old save file to save_path_old in step 3, which we will be able to load from. If the game crashes at step 6, we may or may not have lost save_path_old. This does not really matter because we've already written the new game state to save_path, so everything is still fine. I'd recommend against including step 6 anyways. It doubles the disk space required for save files, but it further reduces the risk of people losing their save files due to the file being corrupted. As you can see, there is no longer a point in time during which the user can completely lose their save file. Instead, they will always be able to load from where the game saved prior to the crash. Further work: These are items the current save game system already relies upon, but which could also be improved in the future. I've ordered them from most important to least important. Caching. Of course, we need to make sure to always flush all our buffers - but that's not all. The operating system can also cache write operations, which it will later execute at its leisure. Flushing our user level caches is required for making the saving routine resistant to game crashes. If you guys also manage to flush the OS caches, the game saving routine should also be orders of magnitude more resistant to system crashes or sudden power losses while the game is saving to disk. Both saving routines rely on the output of the game state serializer to be valid. If the save data that's stored in the buffer is invalid, we'll write a save file we can no longer load from. If there's ample time, it may be a nice idea to build a small verifier that attempts to catch these errors before the corrupted data is written to disk. This is probably a bit over-cautious: Writing and copying to disk can introduce bit flips or other errors. If a disk stops responding for too long, for example, the operating system may silently discard pending write operations. The game could detect this and attempt to recover by calculating a hash of the file we've just written / copied and comparing that to the hash of the current buffer or file we're trying to copy. Again, this is probably over the top, but nevertheless worth considering. Hopefully, this thread will make its way to the staff member responsible for this subsystem. Thanks! Towards a future without lost save files!
  11. For a few items with high health points and low decay values, item decay does not occur unless the game is heavily accelerated (e.g. sleeping / passing time). This is because - for whatever reasons - only single precision floating point values are used for the item's internal health points. Let's take a player on Pilgrim difficulty with constant 60 FPS who has a brand new pack of beef jerky lying around outside. This gives us the following constants float hp = 1000f float decayPerDay = 0.1f float deltaTimeSeconds = 1 / 60f float dayLengthSeconds = 7200f; // Assuming not sped up, 12 in-game seconds per real-life second float decayScale = 0.25; // Due to Pilgrim float decay = (deltaTimeSeconds / dayLengthSeconds) * decayPerDay * decayScale; // = 5.7870377E-8 which is a lot smaller than the 3.0517578E-5 that is needed to get "hp" to go to the next smaller value. This means that (hp - decay) == hp is true, as long as timeScale is lower than 527.3437. And even then, there would be quite severe rounding errors. How to fix this: The easiest fix would be to just use double-precision floating point numbers instead of single-precision ones. There aren't even any real drawbacks to this as double-precision calculations are just as fast as single-precision calculations on CPUs. There's just the memory aspect, but even with 200'000 items, the added 4 bytes / item would result in less than 1 MB of additional RAM usage. Devs, please fix.
  12. @Mods: This post contains both bug reports and feedback, so it might have to be moved. Yesterday, while trying out the new challenges, I spontaneously decided to write down any bugs I'd encounter. Here's what I found (in no particular order), along with some other feedback about the update: Bugs: Alt-Tabbing out of the game with V-Sync on still makes GPU usage go up to 100%. This does not happen if V-Sync is turned off, but then the framerate is unlimited and we get 100% GPU usage in-game instead ^^. Maybe adding a configurable frame limit could help? Picking up a magnifying glass flips most of the screen vertically (screenshot 1, screenshot 2) There are extremely bright reflection spots on snow even when the sky is foggy, which just looks weird screenshot (screenshot 1, screenshot 2) Power lines are still heavily aliased (screenshot) Localization for "not injured" when clicking the first aid button in the radial menu is missing (screenshot) Hostile animals still sometimes flee towards the player, without attacking when in range. Not necessarily a bug, just strange Lantern fuel can be poured into storm lanterns, but there's no way of getting it back out again. Speaking of which, why does lantern fuel still have a degradation percentage, even though it never actually degrades? The player yawns while running, even when running away from wolves / bears. I understand that the sound is triggered by the increasing fatigue, but it's just so weird to hear yawning while running 0.1kg of newsprint rolls still transmutes into 0.2kg of tinder plugs. Very apparent pop-in effect near the exit of the hydro dam, even on the highest graphical settings. Just above the center of the images, yellow-ish thing. (visible, invisible) Some other feedback about the update: It's awesome that the player now actually makes sounds or says something when he / she is cold, hungry, etc.! I love the way wolves behave now! So cool! It's also awesome that crow feathers can now be found near animal corpses. I still have to investigate if this only applies to pre-generated corpses or also to the animals the player killed ^^ Just a personal opinion, but I think the interior of caves now looks too red-ish at dusk (screenshot 1, screenshot 2) Having storm lanterns start to flicker at 0.1L (10%) left feels a bit too early for me. 0.05L (5%) would make more sense in my opinion. The new tab HUD is great! I love how we can now see the increasing / decreasing arrows in real time! The parasite risk from eating predator meat seems unrealistic and feels like "cheap" game design. First of all, aren't we cooking our meat to get rid of those pesky parasites? And from a game design standpoint, why should the consumption of meat that is already harder to get and has less nutrients than other kinds of meat be further restricted? It's good to see that left click macros to defend against wolves now don't work as well anymore. Reversed mouse buttons on torches are also very much appreciated! Lower average FPS is kind of a bummer, especially considering a GTX 970 really shouldn't struggle that much. Can we please get an option to turn off chromatic aberration near the borders of the screen? I just kinda dislike the effect and would much rather have a clean and sharp image without aberration. Sorry if this post was a bit negative, I really liked the update all in all! I'm just kind of salty the GPU-frying bug is *still* not fixed Thank you guys so much for how much work you put into this game!