• Content Count

  • Joined

  • Last visited

Community Reputation

37 Prepper

About StrangerFromTheInternet

  • Rank

Recent Profile Visitors

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

  1. 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?
  2. 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!
  3. 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.
  4. 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.
  5. Yeah, it could be fixed at different levels. Either by renaming the setting, or by replacing a "*" with a "/", or by changing the tuning values, and so on, each with slightly different implications I think just renaming the setting wouldn't be a good idea, as that wouldn't fix the issue for players who've selected a "high" respawn frequency in the past but always got a "low" respawn frequency instead - but that's just my opinion. Either fix is absolutely fine 😃
  6. The language really isn't the problem here, the problem is maths: frequency = 1 / time 😃 When players select "animal respawn frequency = low", they instead get "time between respawns = low", which means a high respawn frequency, which is the opposite of what they wanted. I just checked, and this bug is indeed still in the game. Respawn times are 4 times longer when selecting the "Very High" respawn frequency, so the respawn frequency on "Very High" is just 25% of what it is on "Low"
  7. The head clothing slots are still swapped 😋 Most of the bugs on my list have definitely been fixed, but I haven't been able to check all of them yet 😃 I'm especially curious if the "wildlife respawn frequency" setting finally does what it's supposed to do. That bug goes all the way back to the test branch update where custom modes were first introduced
  8. "'How to make your company immediately lose a large number of clients and get fired' in 1 easy step!"
  9. That's not how this works. Legally, you do own a copy of a game. Games are goods, not services. You can gladly replace bought a copy of my painting with bought a license to download and indefinitely use a copy of my painting. It doesn't change the fact that your initial analogy was wildly inaccurate.
  10. I just need to fix this false analogy: As an artist, if you came into my house, bought a copy of my painting, and then drew a smiley face on it because you think it looks better that way, then I take your copy away and give you a new copy with a sharpie-repellent coating, and you then complained about it... get out of my house - why exactly? Kinda doesn't really work that way when it's adjusted to reality, does it?
  11. Hi, mod dev here. In general, I'd agree with you. If v1.48 had been any other update, sure. The difference is that they didn't just make changes to the game's code, but they switched the Unity scripting backend. It used to be Mono, so the game's DLLs all contained .NET IL that was easy to work with and write mods for. For v1.48, Hinterland switched to IL2CPP. That's a Unity-developed AOT compiler that takes that .NET IL and outputs platform-specific x86 assemblies. I assume you know just as well as me what such a change means for modding. This isn't a software issue, this is a software distribution issue. ??? No, we modify the game that they sold, but we don't distribute the modified software. We distribute our modifications. People still modify the game themselves, as they see fit. You wouldn't say that someone who hands out colorful curtains for people to hang in their houses distributes "modified houses". Also, no, we're not here to talk about "a conflict created by the modifications". We're here to talk about them possibly removing any possibility of efficiently creating mods for the game without any replacement. Seriously, especially as a software developer and modder, you should know what such a fundamental change how software is built and distributed means to other code that depends on that software.
  12. This has been Hinterland's position for literally years now. Can you at least throw us a bone and narrow down the time frame that we should expect? Also, do you plan to still support dynamically changing the game's code, which is what mods currently do using Harmony, or will the planned mod support be more restricted than our current tools? If creating builds with Mono isn't too much of a hassle: Would it be possible to have two builds of the game, the default one using IL2CPP and a deprecated one still using Mono that people would have to opt into using Steam, at least until the official mod support is released? That way, we wouldn't just lose all our mods basically over night.
  13. Basically, the thing I don't understand is - if Hinterland is truly committed to adding mod support at some unknown time in the future, why are they trying to essentially get rid of the current modding community? And why switch to a scripting backend that will make modding exponentially more difficult? Do they just not see the impact this will have on their future modding API? Or was all this talk about adding mod support just PR, and there never were any genuine plans to add mod support?
  14. The difference is that before, we were still able to pretty easily create mods, even without official mod support. Mod support would've been nice-to-have, and with Hinterland changing their stance on modding, we would've finally been able to talk about it on this forum without having to fear the ban hammer. But now, with them switching their scripting backend from Mono to IL2CPP, modding is pretty much impossible, so we'd need an official modding API to get anything substantial done. Heck, even with some fabled modding API, I don't see how people could feasibly create large mods as long as all the game ships with is native binaries.