Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Request: A mod to disable the freezing changes. #25542
Kevin has full authority over stuff (from my suggestion to add an atomic item):
He has said in multiple other suggestions that creating a mod of it was ok. I don't see why he turned down this one (about a no freezing mod) in particular.
That doesn't do what you think it does.
I don't want to speak for @kevingranade, but I believe his objection to the previous attempt was because it was too intrusive and fragile the way it was done. After #25509 is complete, implementing a mod in a way that isn't super fragile or intrusive should be totally possible. Note, I am not volunteering to do that mod per se, just clarifying the situation.
Given his last issue closed with indication of what you are claiming his reasons are, you are indeed speaking for him. No offense.
Kevin has the bad habit of shutting down issues with little more than a very vague statement (see above), leaving many confused as to what rule or policy they ran afoul of. Which in turn leads to rehashing of "closed" issues like this (since no one is entirely certain what went wrong with the previous attempt, and may inadvertently repeat the same mistake). Or just cultivating hostility to moderators by creating the appearance of arbitrary decision-making.
It would help either speed along the process of creating a mod, or shutting down a doomed endeavor early, if there would be some clarification of what was wrong with the previous attempt.
You raised concerns #25385 (comment) in my PR:
The first para raises concerns that what I did would be costly/slow. I took a stab at addressing that in f0c8e20 but since my PR already got shut down I saw no point trying to contribute those changes here.
The rest of your post is comment on the pre-existing temperature handling code, which has nothing to do with me or my PR; #25509 is you addressing those misgivings.
The crux of my code is adding a check in the one and only place where item freezing occurs in the code, to prevent freezing if the user has disabled it through the mod. It is a one-line change in exactly the place it needs to be.
Would you care to elaborate on why you think this is "too intrusive and fragile", since this is your opinion, not something Kevin said.
I don't buy the reasoning behind the decision to block any further mods that disable core features.
The recent change in default season length is accompanied by the announcement
Well, equally, when a user applies mods to their game they should also beware issues, e.g. wonky balance, unexpected interactions or even outright breakages. This is true of any game, not just CDDA.
Why the difference in attitude?
Precluding mods from making even tiny code changes -- i.e. insert a check for some user-configurable option -- severely limits the range of what is possible.
In this case (no freezing), what could be done with very few lines of code would require a much larger json mod, and even that would not be possible if not for freezing point json setting to be added soon.
If we consider, say, Simplified Nutrition or Filthy Clothing, it's not clear those mods can even exist if they're not allowed to touch C++ code. For one, filthy clothing mechanics doesn't translate to something that can be straightforward jsonized and modded with purely json changes.
The inflexible philosophy of "core features can no longer be made optional" means that when Hypothetical Future Controversial Core Feature lands, it may not be possible to disable it within these limitations. The only recourse for people who don't want to play such a feature would be a hostile fork; I'd hate for that to happen.
Honestly I've been against mods to disable core game features all along, but at various times I've had co-maintainers that were very insistent on adding them, so I allowed myself to be overruled.
The freezing mechanics are also much more core to the game experience than filthy clothes, and much less difficult to get right than nutrition. I have a strong expectation that freezing is going to be sorted out within a reasonable timeframe, and once it is, there is no reason to make it optional, it's just part of the game, and more fundamentally, part of the game world. The situation is the same for the other mods, once they are ready to be enabled by default, the disablement options/mods will go away.
If you don't want to deal with freezing mechanics, there is a very simple option setting that should do it, which is enabling eternal seasons and setting your season to summer (spring or fall might work, I haven't checked). Especially with the ability to do this, I don't see a need for an option specific to the freezing mechanics.
This is essentially correct. The real problem is that disabling core features is fundamentally fragile, it means there is not one game to test and debug anymore, there are dozens or hundreds of slightly different variants of the game. At some point a few years ago, we improved the options class to the point where it became trivial to add new options, over time that has resulted in more and more options being added, with little management of whether those options are a good idea. Various people have also taken that as a cue to carve out their own personal version of DDA within the main game, but at the same time, not take responsibility for maintaining said game version with testing and updates to code as needed. As a result, any non-default options tend to accumulate bugs over time, and it falls to core developers to maintain them, whether they think the option should exist or not.
As a result of this, I'm becoming more and more loath to allow new options to be added, and this one does not meet the bar for necessity.
As has been outlined here, you are free to make a mod that adjusts down the freezing point of various items, essentially disabling the mechanism, but in that case the mod is entirely external to dda, and places the burden of maintenance on the mod author, where it should be.
I have spoken at great length many times about why I'm resistant to expanding options within the codebase, it seems to make no discernible difference. As a result I've become more terse on the matter because in the past it hasn't helped. When I explain my reasoning people argue with it, if I don't explain my reasoning, people "get confused", but essentially don't cause further problems. As such the two approaches are essentially equivalent, and I follow one or the other based on how much free time I have at the moment. If you feel like cataloguing my responses on a particular topic, feel free, but as for me, I'm always too busy.
Because the horse is already out of the barn with respect to season length. If we had 365 day years and no option to change it, and someone proposed adding an option to adjust it, I'd deny it too. Since it's already an option, it needs to be treated differently.
In general, we make as much configurable as possible in json definitions, and over time the trend is only toward increasing that. That is the mechanism whereby dda supports configurability. As for relative work, that just acknowledges that making it an option pushes work onto the core dda developers. If you want a mod, you're responsible for maintaining it.