• Content Count

  • Joined

  • Last visited

Community Reputation

46 Prepper

About StrangerFromTheInternet

  • Rank

Recent Profile Visitors

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

  1. Sounds like yet an other issue caused by only using single-precision floating point numbers, even when very small numbers are repeatedly added to a larger number. There also used to be an issue a while back where some food items would never degrade on Pilgrim while the time is not accelerated, and funnily enough, it was a performance optimization that fixed worked around this issue ๐Ÿ˜€
  2. Funnily enough, we actually used to do that in some places with Harmony when the usual Prefix / Postfix methods wouldn't cut it: we take the method's IL (think bytecode, but C#) and modify it, and Harmony would install the new method after doing some checks that we wouldn't crash the VM ๐Ÿ˜„ Messing around with Java bytecode is extremely interesting, too. Writing Java Agents to modify a program's instructions using ASM ( is such an awesome hack! (using the original meaning of hack) Yup, a lot of people are already doing that, and I've written some instructions on how to download TLD v1.56 to a different location using the Steam command line, as well. That way, people can have both the current and an old version of TLD installed at the same time ๐Ÿ˜€
  3. Yeah, but then again, it's not like you'd even need modding tools for that ๐Ÿ˜› But on a serious note, anything beyond the most basic mods will require some code to be written to enable custom functionality, and if that's not possible with Hinterland's mod support, then it's pretty much DoA. Most stuff that the community has been requesting for years (and which ye olde mods provided), like binoculars, more food items with special effects on the player, new firestarting items, etc., all require some code to be written. From what I've been able to tell, most people aren't just looking for "more of the same", which is the only thing you could do without writing code. Yeah, something like that would obviously be sweet, but I wonder how well this would really work for a game like TLD. Many TLD mods don't just extend the game's code in some way, but also change the game's existing functionality. Doing that from a scripting language but targeting a native binary - without having to embed asm into the scripting language and without ruining the game's performance - sounds like a horrendous task. ----- There were around 80 mods written for TLD by about a dozen modders, but they're not that easy to find. Part of the reason why you've never heard of them is because talking specifics about modding or even linking to mods is a big no-no on this forum.
  4. Yeah, there's a mod loader that allows people to read from and write to game objects (I think the published version actually only supports static fields for now) and that allows you to manually rewrite the game's assembly at runtime, but that's it. That's a far cry from what was possible with Harmony. Also, having to write mods in C++ is a huge hurdle for people who want to get into modding and who don't have tons of experience yet. Having to install IDA / Ghidra / whatever to disassemble the game's binary to make sense of what the game's various methods do is a huge annoyance, as well. Also, these mods would then rely on fixed offsets within the game's binary, so they'll almost certainly break after every ever-so-small update to the game. Yeah, no. We're sitting on thousands of lines of legacy code written by modders that either aren't around anymore or don't have time or motivation to work on modding anymore. We simply don't have the manpower to rewrite all of these mods in a different programming language, with a different modding framework that has fewer features, and worse modding tools overall. For a game that's eventually supposed to get mod support, that's a pretty rough deal.
  5. Wow, what an awesome update! Hats off to you, Hinterland, and enjoy your time off!
  6. Not sure if you're aware of this, but there used to be a mod called Relentless Night that did exactly that (and more) ๐Ÿ˜€ Unfortunately, mods don't work anymore after Crossroads Elegy :/
  7. The second bug you've shown in the video has been in the game for ages. Basically, when you go through a loading screen, the game "forgets" that there is ammo in your rifle and just calculates its weight as 4 kg. When you later examine or use the rifle, the game notices that the rifle is loaded and updates the weight to the correct 4.2 kg, which includes the weight of the loaded ammo. I have no clue what causes the first bug where you're left with 4 kg of carry weight despite not carrying anything, though.
  8. I mean, technically compasses are already part of the game. Just drop a stick on the ground - it'll always face in the same direction ๐Ÿ˜›
  9. I had a similar idea 2 years ago (decoupling hunger & stored calories), and I used some MatLab code to simulate that system. With some tuning, it worked fairly well! I feel like overhauling the hunger system is definitely something Hinterland should consider, as it would make for more interesting gameplay, and seeing one's stored calories dwindle could add another layer to the whole "constant depletion of resources" aspect of the game that Raph really seems to like.
  10. I agree, but this could be balanced by reducing the "default" temperature in these locations. For example, it could be -10 ยฐC inside the camp office. To not freeze there, one would have to light a fire in the stove every once in a while to keep the house warm. Just like in real life ๐Ÿ˜„ To prevent this from making the game more difficult in the early-game, one could have all houses start warm-ish and only cool down after some time.
  11. I don't think it's a bug. Fires last longer when it's very cold outside, and this seems to be an intended mechanic, but the increased burn duration is not shown to the player (which makes sense - it's based on the current temperature, so it changes all the time). I think that's all I can say about this mechanic here without getting ban-hammered ๐Ÿ˜…
  12. I'm not a lawyer, so take everything I'm saying here with a grain of salt, but... While the mods themselves may (or may not) be derivative works, they are still protected by the same copyright laws that also protect The Long Dark. Whether or not the act of modding is legal is a more difficult subject, and it varies wildly by jurisdiction. For example, I think that it would be protected under fair use in the USA: Mods are transformative in nature; all of our mods are non-commercial; The Long Dark is a published work; mods do not userp the market for The Long Dark, but rather stimulate it; we copy the least possible amount by only referencing the game's classes and methods without copying (that's the entire point of the mod loader), and only reference what we actually change to create our mods; and so on. However, Hinterland is not based in the US, but rather in Canada. Then again, if a game studio in Canada offers a game on a storefront in country X, and a user in country X purchases it there, then I don't think Canadian copyright law applies, but rather the copyright law of country X, which complicates this even further. And that doesn't even get into the complicated mess that are implied licenses. But I mean, what it boils down to is - if neither party is interested in pursuing legal action against the other party, does it even matter? Like, for example, I think that Hinterland is technically in violation of the software licenses of some of their 3rd party libraries like Json.NET or TinyJSON, which are licensed under the MIT license, according to which as I wasn't able to find any third party licenses included in The Long Dark. But again, nobody is interested in pursuing legal action over not including a license file. After all, the MIT license is often specifically chosen because the software is meant for other people to use in any way they see fit. So in the end, does it even matter?
  13. I mean, all of the asset stuff still works perfectly fine even with the IL2CPP backend. That's just down to how Unity packages its assets. And I'm not sure that you could even say that the code is protected. It's just an x86 binary. If you really want to find out how something works, or if you wanted to extract some secrets or whatnot, attach a debugger to it and go to town. But what is changed fundamentally in IL2CPP is that the excellent interoperability and tooling support that C# (or rather .NET IL) provided, is gone. There's no easy way to reference the game's classes, to call the game's methods, to communicate with the game in any form, basically. Most of our mods also relied on the Harmony library to change the code that the game executes. Being able to run your own code before or after any method, to change the basic IL instructions that a method is made up of, is incredibly powerful, and it has enabled the creation of so many excellent mods. But what worries me is that Harmony, and runtime code generation in general, doesn't work with native binaries, i.e. with IL2CPP. So I'm worried that most of the mods we currently have would never work with the IL2CPP scripting backend, or that enabling such mods would require a huge modding API that would be just unreasonable for Hinterland to create. I understand that you and all of Hinterland want to pursue the absolute best performance for The Long Dark, this is absolutely obvious, and that this can never be outweighed by enabling better mods for a small part of the community. So I fully accept the move away from Mono and towards IL2CPP. But what I'd like to ask you to at least consider would be to maintain two separate branches of the game on Steam - the main, default branch running on IL2CPP (once it has stopped crashing ๐Ÿ˜‹) and a second one running on Mono or .NET that people would have to explicitly opt into - at least until Hinterland's official modding tools are ready. That way, we could keep our current mods for now and then smoothly transition to Hinterland's tools once the time is right. Anyway - Raph, thank you so much for having this really open discussion with us tonight. You could've shut down this conversation, locked the thread, and started handing out warnings ten times over, and I really appreciate, and it really has changed my perception of you, that you didn't. I'll go catch some Zs. Have a good one!
  14. I don't think modding is comparable to the original act of creating a game, either, but we've still poured our hearts and souls into these mods, into our little sub-community, and into everything in-between. Sure, they may just be silly little mods, and none of this would exist if it weren't for The Long Dark and Hinterland, but they're our little mods, and they really mean a lot to us. When I found out that all existing mods would not work on v1.48, that "the era of modding" might end forever and that all of our creations essentially vanished over night, I was genuinely in a depressed mood. Mods are what connects me to so many people that I otherwise would've never got to know. I love creating mods, I love getting feedback, and I love talking to people about modding. I honestly couldn't care less if we'll ever get an official modding API or anything like this - I just don't want to lose all of my creations, our little community, our heart and soul, over night, just like this.
  15. Nah, it really isn't. Selecting a value from an array and then multiplying stuff together really isn't all that complicated ๐Ÿ˜‹ Seriously, I've analyzed and re-analyzed this bug so many times now, from decompiled code over asset files to mods that just print the time between respawns for each spawner. Since the bug has been first reported over a year ago on the test branch forum, and then again later on the bug tracker, nothing has changed.