PC V2.3 Experimental

The loot cap appeared to be penalizing players who choose to stay in the same zone, rather than rewarding players for trying harder biomes.

I was spending a week / horde in each biome and kept getting loot capped.

First off, withholding a reward isn't a punishment. Rewards are earned.

Secondly, I can't think of a single open world game that rewards players for never leaving the starter/newbie area. Can you?
 
@faatal I have a proposal to make protection from natural hazards in poi 50% instead of 100%. It would be more logical, because almost all poi have a lot of holes and broken windows. This makes natural hazards useless.
I think that 100% is too much, please fix it!

I wish there could be more subtlety. Some POIs have places that make perfect sense to be completely protected. I know I've got storm shelters on a couple of my POIs. There are underground bunkers. There are player-built structures in great shape. Perhaps it boils down to being more about the blocks that are protecting you, though a block-by-block check (potentially as you move about) sounds algorithmically slow.
 
If your friend moves to each biome to start doing the next tier of quests then they’ll naturally loosely follow what the loot caps enforced.
Too bad that quest progression isn't balanced for the current level of questing to naturally continue into the next biome, while higher tiered quests appear first in the current biome.

It would have given additional incentive for people to venture into the harder biomes and not fear the double whammy of advanced tier AND advanced biome.

Experienced players understand that you can choose lower tiered quests at will, but I think many players are looking to the game for some guidance or logic for picking quests and many can get "stuck" in the first biome as quest difficulty and reward continue to ramp up without ever giving any real incentive to cross into an even more dangerous biome. Staying in place can look like the expected progression.

Such balancing could have slightly extended player progression which TFP tend to be fond of, while also prodding the player to try the next zone.
 
I wish there could be more subtlety. Some POIs have places that make perfect sense to be completely protected. I know I've got storm shelters on a couple of my POIs. There are underground bunkers. There are player-built structures in great shape. Perhaps it boils down to being more about the blocks that are protecting you, though a block-by-block check (potentially as you move about) sounds algorithmically slow.

For POIs, some kind of "biome-proof" volume would be pretty cool. You could place such a volume in spots like cellars or storm shelters or safe rooms or bunkers that would logically increase protection, while giving the rest of the POI lesser sheltering protection.
 
I wish there could be more subtlety. Some POIs have places that make perfect sense to be completely protected. I know I've got storm shelters on a couple of my POIs. There are underground bunkers. There are player-built structures in great shape. Perhaps it boils down to being more about the blocks that are protecting you, though a block-by-block check (potentially as you move about) sounds algorithmically slow.
I thought it was using the IsIndoors property, did that change.
 
The reason I thought that was the property, is when the first round of storms was created
I was inside a pre-existing sort of metal garage, with control panels on the wall. I had to move
specific distance from certain blocks, or the warning and timer would show. It prompted me
post a dream similar to zz's above. It wasn't just a closed box, it had sort of a maze between
the blocks, so I moved around through the rows and simultaneously when the timer restarted
it also got lighter.

Then I thought about it, playing around in a cleaned out POI, to see when lighting, would engage.
I think that used the light opacity property. So would something similar to combining those two
possibly work. Using CVAR properties plus is indoors plus lightopacity property. So if light above
a certain vaIue is applied to the blocks then weather indoors used the same thing it should kind
of similarly. I would like the same thing that @zztong was posting about, and simple like he expressed.
 
While this is good I wish there would be way more optimizations, the fact that around 60 zombies will lower my FPS from around 170 down to 40 is pretty bad. It would help if their logic would run in parallel (to some degree) but I imagine that it's pretty difficult with the spaghetti code, it's not exactly a secret to how the code looks like given anyone can fire up dnSpy or ILSpy and have a look and I studied more of the code then I would like to admit.
I've noticed a very significant performance issue since version 1.0. In the client, when multiple players constantly gang up on zombies, there's a significant drop in frame rate. The more players participate, the worse the performance; for those with less powerful processors, it can become unplayable.This issue occurs especially when using rapid-fire weapons, such as machine guns. In my tests, when a single player kills a zombie, the drop in frame rate is minimal and almost imperceptible. Even in a single- or double-player game, it's not particularly noticeable.At first, I thought it might be due to zombie dismemberment or ragdolling, but that's not the case. It's also not related to the AI, as disabling it causes the freezes to persist. I suspect the source is physics body collisions, which seem to be overloading the clients when zombies take damage and die.I've been testing tweaks to the "zombieStandard" physicsbodies file and have achieved a slight improvement, but the underlying issue remains. I'd like the developers to run tests with multiple players killing zombies at the same time before releasing the stable 2.3 version, so we can reproduce the performance issue and find the real cause.
By the way, I ran the tests in vanilla.
 
The reason I thought that was the property, is when the first round of storms was created
I was inside a pre-existing sort of metal garage, with control panels on the wall. I had to move
specific distance from certain blocks, or the warning and timer would show. It prompted me
post a dream similar to zz's above. It wasn't just a closed box, it had sort of a maze between
the blocks, so I moved around through the rows and simultaneously when the timer restarted
it also got lighter.

Then I thought about it, playing around in a cleaned out POI, to see when lighting, would engage.
I think that used the light opacity property. So would something similar to combining those two
possibly work. Using CVAR properties plus is indoors plus lightopacity property. So if light above
a certain vaIue is applied to the blocks then weather indoors used the same thing it should kind
of similarly. I would like the same thing that @zztong was posting about, and simple like he expressed.

You could do it computationally like that but every layer of extra checks you put in place gets more and more expensive. It isn't a matter of "can it be done?" It's a matter of whether or not it can be done without hurting performance.

The idea I suggested (volumes) wouldn't work, either, to be honest. Mostly for logical reasons. It falls apart under scrutiny pretty fast. Like, if you place a hazard-proof volume into a bunker POI, what happens if the player disassembles the bunker? The volume is still there. Oops! Even if you do something like isInHazardVolume() && isIndoors(), the player could disassemble the bunker, build a rickety wood shack in its place, and still pass those checks. So now you need more logic to deal with that, and so on. It's a bottomless rabbit hole.
 
You could do it computationally like that but every layer of extra checks you put in place gets more and more expensive. It isn't a matter of "can it be done?" It's a matter of whether or not it can be done without hurting performance.

The idea I suggested (volumes) wouldn't work, either, to be honest. Mostly for logical reasons. It falls apart under scrutiny pretty fast. Like, if you place a hazard-proof volume into a bunker POI, what happens if the player disassembles the bunker? The volume is still there. Oops! Even if you do something like isInHazardVolume() && isIndoors(), the player could disassemble the bunker, build a rickety wood shack in its place, and still pass those checks. So now you need more logic to deal with that, and so on. It's a bottomless rabbit hole.
Okay, so what if that is simplified, instead of thinking of building individual volumes, think of outside is one big volume of atmosphere.
Outside is 100%. The player wouldn't but indirectly would be creating a volume. as they build and remove blocks.
CVAR adlib: Is person inside or outside, If inside then using the same value scheme for lights, adding a single property
value to the blocks, could effect the variable percentage multiplier for effectiveness.

Simplest image terrain or base surface under foot, is set to 100 because it blocks weather underground and plug the hole
or if you create sealed cubicle base. The only thing left is for the above ground builder, the other 5 sides of the cube. Which
is being calculated anyway, or light would not change when you go indoors. If Lightopacity property, ranged from 0 to 100,
instead of 0 to 6. Then the same property could be used to regulate, two aspects. For transparent solid windows you would
have to adjust it to max value, a broken to a lesser.

So if you built anything and it's GTE value is 100+ for being solid, the weather is blocked. And it would use a process that is already
there. The main change would be adding the opening and closing property for a weather resistance buff. That buff could then
be used also for temperature regulation, weather comes in then so does temperature change. Similar to what the clothing and
armor do now. But the foundation would have to be a common value.

Another way could be, and this would need a timer. Still setting Lightopacity to 0-100. All of the cracky blocks, no matter
which material, start the timer if player property IsIndoors applies. And the variable used is the speed at which weather
damage begins to occur. Value 100 or greater no timer, less than 100 timer and debuff.
Same way that <effect_group name="food/water balancing"> works now.
 
Loot stage caps never bothered me. Most games (even sandboxes) keep the best loot in harder zones. The push back on this particular issue was a little strange, I think.
I think it was because in this game you won't have to go to a harder area to fight harder enemies or get better loot. You can do that in the forest by just increasing your game stage naturally. You miss out on the have stage bonus, but that is all. So capping loot to force people into other biomes when there isn't really a reason to go there if you prefer the forest or some other biome didn't sit well with people.
 
Okay, so what if that is simplified, instead of thinking of building individual volumes, think of outside is one big volume of atmosphere.
Outside is 100%. The player wouldn't but indirectly would be creating a volume. as they build and remove blocks.
CVAR adlib: Is person inside or outside, If inside then using the same value scheme for lights, adding a single property
value to the blocks, could effect the variable percentage multiplier for effectiveness.

Simplest image terrain or base surface under foot, is set to 100 because it blocks weather underground and plug the hole
or if you create sealed cubicle base. The only thing left is for the above ground builder, the other 5 sides of the cube. Which
is being calculated anyway, or light would not change when you go indoors. If Lightopacity property, ranged from 0 to 100,
instead of 0 to 6. Then the same property could be used to regulate, two aspects. For transparent solid windows you would
have to adjust it to max value, a broken to a lesser.

So if you built anything and it's GTE value is 100+ for being solid, the weather is blocked. And it would use a process that is already
there. The main change would be adding the opening and closing property for a weather resistance buff. That buff could then
be used also for temperature regulation, weather comes in then so does temperature change. Similar to what the clothing and
armor do now. But the foundation would have to be a common value.

Another way could be, and this would need a timer. Still setting Lightopacity to 0-100. All of the cracky blocks, no matter
which material, start the timer if player property IsIndoors applies. And the variable used is the speed at which weather
damage begins to occur. Value 100 or greater no timer, less than 100 timer and debuff.
Same way that <effect_group name="food/water balancing"> works now.

I highly doubt TFP is going to reengineer a large chunk of code just so that we can have more realistic storm cellars.

In my opinion the easiest and least expensive way of improving this part of the game would be to lower biome hazard protection to something less than 100% if a player is inside a shelter but doesn't have protective gear. That's something that could easily be done with a mod. Maybe even just a simple xml mod.
 
I highly doubt TFP is going to reengineer a large chunk of code just so that we can have more realistic storm cellars.
No, I am asking from a modders' perspective, or more so your personal objective opinion. Do you think
that it is a possibility? I was asking where do you see the holes in the idea. They have enough on their plates.
Just like you were able to see the short coming regarding your post about the volumes, prior. So that the topic
doesn't skew you can DM me.
 
Back
Top