Whats the logic behind eatting and smelling after.

meganoth said:
I though about it again and found one solution to my theoretical problem that is so easy it is embarassing I didn't think of it already:

If the options menue can read and display the modded values as (new) default then a user can actually see and change the modded values while getting the modded values as default.
The options need to override the mods by the way. For example if someone wants to play a mod that (among other things) increases zombie run speed by day to jog and a players has always increased that to run in vanilla to make it difficult for him he should be able to do that in the mod as well.
Click to expand...
The options really shouldn't be overriding what a mod does. If someone is using a mod that changes a value to something that the player doesn't like, the player will need to edit the mod unless the mod makes an in-game option for it. If game options change the mod values, then you're preventing a mod from making changes unless the game allows a mod to change the values in the game options.

Now... that doesn't mean that a mod can't edit the game options UI and insert their own values into game options. That is a good option for a mod author to consider. It lets players use additional options when starting a game rather than limiting options to just what the mod does. But that isn't always what a mod author will want. If a mod author wants a specific kind of game setup (this may be especially true for overhaul mods) then they may want to prevent specific game options from being used, and that should be allowed. Of course, they could still go in an change the game options and remove anything they don't want, but they could also just override the game options and that should be fine also.

Consider this... let's say a mod author wants to just increase block damage. They can make a simple mod that does so, ignoring any UI changes, and it will work. If the game overrides mod changes, then a mod author will always have to edit the UI game options. That will greatly increase the incompatibility of different mods because they will all be trying to change the game options UI instead of just changing values. It just isn't good practice to ignore what a mod does if you change game options.
 
Riamus said:
The options really shouldn't be overriding what a mod does. If someone is using a mod that changes a value to something that the player doesn't like, the player will need to edit the mod unless the mod makes an in-game option for it. If game options change the mod values, then you're preventing a mod from making changes unless the game allows a mod to change the values in the game options.

Now... that doesn't mean that a mod can't edit the game options UI and insert their own values into game options. That is a good option for a mod author to consider. It lets players use additional options when starting a game rather than limiting options to just what the mod does. But that isn't always what a mod author will want. If a mod author wants a specific kind of game setup (this may be especially true for overhaul mods) then they may want to prevent specific game options from being used, and that should be allowed. Of course, they could still go in an change the game options and remove anything they don't want, but they could also just override the game options and that should be fine also.

Consider this... let's say a mod author wants to just increase block damage. They can make a simple mod that does so, ignoring any UI changes, and it will work. If the game overrides mod changes, then a mod author will always have to edit the UI game options. That will greatly increase the incompatibility of different mods because they will all be trying to change the game options UI instead of just changing values. It just isn't good practice to ignore what a mod does if you change game options.
Click to expand...

Why would the game option UI need to be changed. All that the mod would be changing is the value of an internal variable initially set by inizialization code.

You are forgetting that a user should have final say what settings he wants to play himself. The mod author can set block damage higher and tell the user that is the right balance, but he doesn't know how good the player is and what his tastes are. Not "one size fits them all" in gaming, not even in mods. Sure, a mod author still can do it, but then he does a disservice to the players who want to play his mod and limits the appeal of his mod.

Imagine if an overhaul mods would set the difficulty setting to one specific value and didn't allow to change it, because the mod author in his hubris thinks the mod should only be played at that difficulty. Would you applaud this mod author that he did you a service with that?
 
There is one food already that has no smell. I hope they don't change it. It's Yucca.
I look at it as a legacy nod, I use it as a supplemental food, and as a risk reward
thing for going into the desert. I think it has the lowest benefits in the food group.

But since I go through the other biomes constantly from the beginning, it makes it
feel like a reward, either that or blueberries. There should be one such food in each
of the upper biomes. Very low yield, no smell as a reward for the risk in exploration
especially when you are just wearing a groot suit.

@meganoth
Expand your thought in regard to your post. It would be detailed, it would take some
one with a lot of patience and attention to detail. If it were done and set to a sub menu
non intrusive for a basic logon. Then a few of the config, xml, could have a page setup.

It would or could be a way for TFP to address two groups 1 old and 1 new. The old group
are those that don't mod for one reason or another, but make pimp requests, for micro
changes. The new group are the console users, that can't dig into the files. It would be a
TFP controlled sort of modding extension. But in order for them to share their plethora
of changes among each other there would need to be a collected single file like a database
or a cvs that they could share. But I feel for the team member that it is assigned to.

It would def be a big sales point, if it could be achieved. The most important logic point
would be getting the varied accumulated changes in the sub-menus to be interchangeable
for continuity, between platforms. But it has to have some limit or it will become 7 days to
survive configuring the Game. Zombie survival game. That's a mouthful.
 
Last edited:
meganoth said:
Why would the game option UI need to be changed. All that the mod would be changing is the value of an internal variable initially set by inizialization code.

You are forgetting that a user should have final say what settings he wants to play himself. The mod author can set block damage higher and tell the user that is the right balance, but he doesn't know how good the player is and what his tastes are. Not "one size fits them all" in gaming, not even in mods. Sure, a mod author still can do it, but then he does a disservice to the players who want to play his mod and limits the appeal of his mod.

Imagine if an overhaul mods would set the difficulty setting to one specific value and didn't allow to change it, because the mod author in his hubris thinks the mod should only be played at that difficulty. Would you applaud this mod author that he did you a service with that?
Click to expand...

It's a matter of how you look at it.

Game options are just settings in xml. Simple mods are just modifications of settings in xml. If game settings override mods, then mods become limited in what they can and cannot do, and those limitations grow as more options are exposed in the user interface.

From a development perspective, assuming that maximizing modability is a Requirement, the best option in my opinion to resolve that conflict is to have mods override settings. This means that the developer can expose more settings in UI, should they choose to do so, without worrying that they are further curtailing the game's modability. As far as how that conflicts with the user experience: it shifts the responsibility to deal with that onto the mod author.

If a player does not like what a mod author has done with their mod, and that mod author has not exposed a way to fix that, then the player can choose to uninstall the mod.
 
@4sheetzngeegles @Sapient6 : You are misunderstanding what I am saying. This is not limiting the mod author in any way if relevant options (i.e. options the player sees in his options UI) are still changeable by the player as long as the mod author can set the default any way he wants in XML.

Example zombie block damage: The mod author wants to change it to double of what it is in vanilla for his prefered balance. So he sets the default to 200%. Everythings good, a player sees the default of 200% in the options UI. Whoever wants to play like the mod author wants, keeps those defaults. But imagine a player who wants to play that mod (especially on a console) and his horde base gets crushed every time. Should he not have the option to change zombie block damage to 100 or even 50% ?

In another words: The server owner of a MP game or the player in a SP game should always have the last word about what settings he plays at, thats what options are for. But the mod author or the game developer sets the defaults of those options.

Naturally options might become irrelevant. A setting about empty jars becomes irrelevant if the mod author removes empty jars completely. That is ok as well, but doesn't invalidate the general rule that options the player sets in the UI should have the last word.

I never said that "game settings made by TFP (assuming you meant that) should override mods". Is my english so bad? I suspect we have a different definition of the word "game option" here and talk at cross purposes.
 
Last edited:
I understood what you posted. What I posted was a potential extension on your
thought. Just saying it would need to be carefully detailed, and tempered in it's scope.
Just going from the past, it potentially could creep out of control. But it has the ability
to make it a more widely marketable game. Along TFP design sensibilities. A more
amicable game, allowing for micro-modifications to make it each persons own. Once
again marketability. That was/is the underlying draw of the game engine itself. Everyone
takes it personally. Because they can put part of themselves into it. This would potentially
expand that.

But I looked at Sapient6's thought process also. TFP protects it's processes jealously
because the processes they created are personal, so do the modders feel in the same vein.
Somewhere down the line there could be a happy ending for all. But, it is going to take
some actual brain storming.

So both of you are right from your viewpoint, and Riamus also, now all it would take is the
most unbiased person with most even temperament, on the team to initiate it. I am unbiased
and always look at the potential of things.

Balance
 
4sheetzngeegles said:
@meganoth
Expand your thought in regard to your post. It would be detailed, it would take some
one with a lot of patience and attention to detail. If it were done and set to a sub menu
non intrusive for a basic logon. Then a few of the config, xml, could have a page setup.
Click to expand...

You talk about that it needs to be handled with attention to detail. And it could be done in a sub menu. But you never say what it is. Needless to say you left me behind somewhat confused ;)
 
meganoth said:
I never said that "game settings made by TFP (assuming you meant that) should override mods". Is my english so bad? I suspect we have a different definition of the word "game option" here and talk at cross purposes.
Click to expand...
There's some sort of confusion there, for sure. The way I see it, it's never really an issue. If a mod changes something that has a setting, the mod author will have to take that setting into account. Whether that's leave alone, edit the options, or remove entirely; that's up to the mod and modder.

Anything else feels like a bug .. if "TFP settings" force 'run' on zeds that a mod wants to never run, it's a mod bug.

A server owner chooses whatever settings they want, but a mod is Buggy if it doesn't actively ensure that all the settings are compatible with the mod. If an unresolvable conflict would appear, the modder can just hide a setting, instead of purely disrespecting it.
 
Apologies; Your base post, spoke of allowing for in-depth customization. I imagined
the potential, positives, negatives and a balance of the two. The part I was referring
to being handled carefully, is the options that would be added, and especially how
they would be added, and by whom, so that it actually becomes a resolution and not
another Merry go round of activity. It could be a decent feature or addon, but after years
of observation and reading, depending on whom would be delegated on the team to do
it, there is the potential of it to either be biased in its focus, similar to your reference regarding
mods and Sapient6's response, or being in-cohesive and a bit scattered in roll out and not
provide the intended functionality. Which will just turn into another stream of arguments.

Personally I like the thought of the idea, you presented a good foundation, that if done well
has the scope to cover pc console modders non-modders and server admins, in one move.
I just meant that the person that does it can't be in a bad mood, when they do it.:ROFLMAO:
 
meganoth said:
You are misunderstanding what I am saying.
Click to expand...

I'm not misunderstanding, I am just disagreeing. The problem with defaults is that defaults are a ship that might already have sailed. All is good if the mod changes defaults and is applied before the game world has been created and started, but what about the case where the mod is installed later? Limiting it to only affecting defaults knee caps that completely.

But all the same I concede on the technicality that a hypothetical mod that changes server\game settings is almost certainly a poor design all around.

I think theFlu hit the nail on the head far better than I did. It isn't so much that the mod should override the setting, it's that the mod should interpret the setting. Take the given example of a mod that affects zombie running. The setting the user or server admin changes should determine whether or when zombies will "run". The mod should leave that alone. It should not even affect the default.

Instead, the mod should determine what "run" means.
 
meganoth said:
You are forgetting that a user should have final say what settings he wants to play himself. The mod author can set block damage higher and tell the user that is the right balance, but he doesn't know how good the player is and what his tastes are. Not "one size fits them all" in gaming, not even in mods. Sure, a mod author still can do it, but then he does a disservice to the players who want to play his mod and limits the appeal of his mod.

Imagine if an overhaul mods would set the difficulty setting to one specific value and didn't allow to change it, because the mod author in his hubris thinks the mod should only be played at that difficulty. Would you applaud this mod author that he did you a service with that?
Click to expand...
You are looking at this in a very limited way. You mentioned overhaul mods, so let's take a look at one like DF or UL. There are a LOT of changes in those. Some I like and some I don't. I don't use those mods because I don't like some of the changes in them. I don't have any option to change those things if I want to use those mods unless I want to edit the mods directly. Are those mods bad because "the mod author in his hubris" thinks that the player should play the game in a specific way, such as with LBD? No.

Mods are there to create a different way of playing the game. Some may be just UI, but we're talking about mods that change how the game works right now. Players have a choice whether or not to use a mod. They decide whether or not to use it based on what the mod does. If the mod aligns with how they want to play the game, they will be more likely to use the mod. If the mod doesn't align with how they want to play the game, the probably will not use the mod. That's the nature of mods in any game. A mod author does not ever have a requirement to make things optional to players, though they can certainly do so if they want. Is it better if they do? Sure. But it isn't necessary.

Let's say a mod author is making a "hardcore survival" mod. They remove all "easy" options. Zombies can only sprint, zombies do more damage and players do less damage, no air drops, permadeath, etc. Such a mod wouldn't be for players who want to make it "easy mode" again. Players shouldn't be able to override those options in that kind of mod. Players who don't like that kind of gameplay just won't use the mod, while those who like it will use it. And just to be clear, the mod I'm imagining here would do more than just pick the "hardest" game options; it would also add more things to make survival gameplay more challenging. Now, yes... the mod author can edit the game option UI to remove or change all game options that are seen by the player. That would be the better option so that the player can't even touch those options. But it shouldn't be required in order to prevent options from overriding the mod.

And let's say the mod just changes what the game options mean. Let's say that the mod changes "walk, run, sprint" to all have increased speed, becoming "run, sprint, super sprint". You can change the game option, but the result will be the new speeds. Is that bad that the player can no longer choose "walk"? If the player doesn't like the mod doing that, the player just doesn't use the mod.

In the end, I don't really care. I don't use many mods, so it doesn't affect me.
 
Guys, this discussion started because I made a post listing disadvantages of having lots of options and one was that such settings should also be tuneable by xml and that creates technical problems. Then a few guys gave a counter-argument to this and I said "Ah, I made a mistake, that purely technical problem has easy solutions and I came up with a very simple one". A solution to exactly one specific imagined problem which assumes that the mod author has an option value he wants to change but keep! And when he does that he obviously wants the user be able to change that value.

And you continue to list and discuss other setting constellations that have nothing to do with the limited case I was talking about.
 
meganoth said:
And you continue to list and discuss other setting constellations that have nothing to do with the limited case I was talking about.
Click to expand...
Hmm. I'm riffing around a couple thematic issues you seem to have raised in your posts; roughly, and trying to be fair:
1) Moddable xml is somehow mechanically in conflict with a settings UI.
2) Some form of "user agency" -conflict between player/TFP/user with mods doing weird things.

For 1) I don't really see a problem. Both are the same type of thing, setting values; xml is "closer" to the code but could entirely cover populating the settings UI - just as well as it can populate loot containers. Any complexity that arises is the headache of a modder, but they're not technically incompatible.

For 2) I don't see a real conflict; there's no moral or legal reason to "refuse" mods that want to do things that Some User doesn't like. The user has the option of not using that mod, or requesting a change to it, but if a user installs a mod and it doesn't allow to set some setting to a value he'd like; that's on him. It's just not a mod he should be installing?
 
theFlu said:
Hmm. I'm riffing around a couple thematic issues you seem to have raised in your posts; roughly, and trying to be fair:
1) Moddable xml is somehow mechanically in conflict with a settings UI.
2) Some form of "user agency" -conflict between player/TFP/user with mods doing weird things.

For 1) I don't really see a problem. Both are the same type of thing, setting values; xml is "closer" to the code but could entirely cover populating the settings UI - just as well as it can populate loot containers. Any complexity that arises is the headache of a modder, but they're not technically incompatible.

For 2) I don't see a real conflict; there's no moral or legal reason to "refuse" mods that want to do things that Some User doesn't like. The user has the option of not using that mod, or requesting a change to it, but if a user installs a mod and it doesn't allow to set some setting to a value he'd like; that's on him. It's just not a mod he should be installing?
Click to expand...

Well, I see no problems either. But if you want to continue talking about imagined problems to imagined listeners, be my guest ;)
 
You must log in or register to reply here.
Back
Top