Whats the logic behind eatting and smelling after.

faatal said:
I explained how it makes sense, you just don't agree with it. I know many people who like it. You open the food to eat it, so the smell is in the air. It does disappear at a rate that I consider quickly. We like it and find it fun. We gave you a setting to turn it off of you don't like it.
Click to expand...
I think there should be the option of smell sensitivity like with jars refund, so that people who like the mechanics in general but not the particular settings can make it more unique to their taste. Like make canned food have lower distance of smell cuz it is cooked and chemically processed food not the raw meet, but make smell linger for longer so that canned salmon gives you 10 m radius of smell but it is persistent for 2 hours and zombies identify more smelly things easier. Or veggies that raw or cooked have short but consistent small for 15 meters if they are spicy or heavy flavoured.
 
Novus25 said:
I think there should be the option of smell sensitivity like with jars refund, so that people who like the mechanics in general but not the particular settings can make it more unique to their taste. Like make canned food have lower distance of smell cuz it is cooked and chemically processed food not the raw meet, but make smell linger for longer so that canned salmon gives you 10 m radius of smell but it is persistent for 2 hours and zombies identify more smelly things easier. Or veggies that raw or cooked have short but consistent small for 15 meters if they are spicy or heavy flavoured.
Click to expand...
Although I'd like different amounts of smell (including none) for different food, I don't think that's a good thing to include in options. We can't have options for everything in the game, and that just feels too far into the micromanagement category to me. That's really what mods are for, though that doesn't help solo console players or console players who host the game. But faatal said they're going to adjust smells for different food, though they aren't likely to set any of the food to no smell, unfortunately.
 
Riamus said:
Although I'd like different amounts of smell (including none) for different food, I don't think that's a good thing to include in options. We can't have options for everything in the game, and that just feels too far into the micromanagement category to me. That's really what mods are for, though that doesn't help solo console players or console players who host the game. But faatal said they're going to adjust smells for different food, though they aren't likely to set any of the food to no smell, unfortunately.
Click to expand...
different foods having different smell ranges makes sense to me!
 
grz__ said:
The photo may be a joke, but including options to adjust things is a good thing. I don't know how anyone could perceive that as bad.
Click to expand...

It is, I am so for settings as well. Didn't take much around literally, definitely not from me.
 
There are actually downsides to options from the viewpoint of developers:

Working on the game gets more and more complex the more options you have. Because any changes to the game need to work with any setting of those options. This often generates bugs because a developer forgot about one of the options when changing something. Just as an example: A setting to turn of traders would need additional changes in a lot of code that assumes there are traders on the map.

In the case of TFP there is another major problem: A lot of the game is controlled by XML to be easy modable. There is no good way to have something tunable by option and also modable.

Additionally options could need changes to XML as well when the XML depends on some options setting. Practically TFP would either need to write conditional parts into their XML dependant on option settings, a bad solution as XML is not really a programming language, with conditions it probaly becomes unmaintainable very fast. Or TFP could make complete XML files load conditionally dependand on options, a really really bad solution as an xml file that depends on 2 options needs 4 different versions, an xml file that depends on 3 options would already need 8. Urgh.
 
meganoth said:
There are actually downsides to options from the viewpoint of developers:
Click to expand...
There's also downsides to us players. A simple, relatively neutral example, is day length. We can't discuss pretty much anything without mentioning how long our days are. With such a simple change, we're experiencing and talking about different games. The more options there are, and the more ambiguous they are, just finding the "best set of settings for me" is a massive trial and error. You'll have to test out each, and try and guess their interactions based on short descriptions - and most people don't bother to even read a description fully.

Picking up a new game, a massive set of switches is just plainly overwhelming. For a game that's meant to be played for about 50 hours "per game", you can't iterate through them all that fast.

If we get a decent chunk of more (and more) settings, I would at least hope to see some "pick a game style" -groups of default settings, "survival", "shooter" etc.. like pregen maps for settings :)
 
meganoth said:
This often generates bugs because a developer forgot about one of the options when changing something.
Click to expand...

Very true. And, more paths through the code, or subsystems, means more testing for your QA folks. Plus more unanticipated complications in game play.

meganoth said:
In the case of TFP there is another major problem: A lot of the game is controlled by XML to be easy modable. There is no good way to have something tunable by option and also modable.
Click to expand...

I think this needs clarification. Lots of XML provides options, but they are typically data options, like "how big do you want the map" or "how fast should zombies move at night." Options that turn on/off subsystems CAN be in XML, but you are turning off major chunks of XML.

For instance, you might let the players choose between 3 lighting systems in XML. Then, also in XML, you have the configuration for each of those lighting systems. Only one of those configurations will be active, depending on the first choice of which lighting system will be used, but you could mod the configuration in each of those systems.

All that said, complex runtime decisions aren't well served by XML.
 
theFlu said:
Picking up a new game, a massive set of switches is just plainly overwhelming. For a game that's meant to be played for about 50 hours "per game", you can't iterate through them all that fast.
Click to expand...

Gate the massive selection of options behind a button that says "Expert Options for Game Nerds"? Then have red text across the top that says "any changes made here may permanently ruin your game (FAFO)."

...wait, that's exactly the same as just relegating them to xml edits only. Nevermind.
 
Sapient6 said:
Gate the massive selection of options behind a button that says "Expert Options for Game Nerds"? Then have red text across the top that says "any changes made here may permanently ruin your game (FAFO)."

...wait, that's exactly the same as just relegating them to xml edits only. Nevermind.
Click to expand...

Well, I expect an option to have been vetted. XML edits, is trial and error.........and a pain if you dont know it, or have time to learn it.
 
meganoth said:
In the case of TFP there is another major problem: A lot of the game is controlled by XML to be easy modable. There is no good way to have something tunable by option and also modable.
Click to expand...
As long as mods override game options, there isn't really a problem. The problem comes if game options override mods, which would make it difficult to mod something that has an option. But if the mods override the game options, which they do now, you can easily mod anything just as easily whether there is a game option or not. There is a game option for damage or day length and yet mods can change those to other things already without a problem.
 
Riamus said:
As long as mods override game options, there isn't really a problem. The problem comes if game options override mods, which would make it difficult to mod something that has an option. But if the mods override the game options, which they do now, you can easily mod anything just as easily whether there is a game option or not. There is a game option for damage or day length and yet mods can change those to other things already without a problem.
Click to expand...

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.
 
meganoth said:
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.
Click to expand...
All the settings in a settings-UI are essentially "setting of numbers". Some might be named, but Walk, Jog, Run are as much a 1, 2, 3 as anything. Making the values themselves defined in the xmls isn't an issue beyond changing reading order.. the actual problems might show up with settings that Don't reflect xml, but change some hard-coded behavior instead. Then again, if a mod is going to touch those, it won't be a simple xml mod anymore.

For prio with options vs mods; that is up to the modder anyway. A mod can edit the settings themselves, so the "defaults" might mean nothing, or not even be there in the modded version. Setting "run" in a mod that only has crawlers .. for a simple example ;)
 
You must log in or register to reply here.
Back
Top