Whats the logic behind eatting and smelling after.

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.
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.
 
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.
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.
 
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.
different foods having different smell ranges makes sense to 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.
 
There are actually downsides to options from the viewpoint of developers:
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 :)
 
This often generates bugs because a developer forgot about one of the options when changing something.

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

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.

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.
 
Back
Top