PC V2.3 Experimental

FinkPloyd said:
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.
Click to expand...

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?
 
KirillWright said:
@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!
Click to expand...

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.
 
Roland said:
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.
Click to expand...
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.
 
zztong said:
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.
Click to expand...

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.
 
zztong said:
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.
Click to expand...
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.
 
ZehMatt said:
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.
Click to expand...
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.
 
4sheetzngeegles said:
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.
Click to expand...

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.
 
EvilPolygons said:
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.
Click to expand...
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.
 
EvilPolygons said:
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.
Click to expand...
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.
 
4sheetzngeegles said:
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.
Click to expand...

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.
 
EvilPolygons said:
I highly doubt TFP is going to reengineer a large chunk of code just so that we can have more realistic storm cellars.
Click to expand...
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.
 
4sheetzngeegles said:
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.
Click to expand...

I think I see. You're suggesting that if there's an algorithm computing environmental light based on the player's location, perhaps that calculation also could inform the storms, so no additional computation would be needed. Yeh?
 
Hated said:
View attachment 36320
Hey Survivors!

Today we have V2.3 experimental for you all.

We have a lot of changes that were talked about in the Town Hall Stream with more to come at a later date.

Disclaimer:
While we worked hard to make sure save games continue without issue, please make a back up of your current save before starting the game in V2.3
We've also added a runtime function that will automatically convert the old badges to the new survival gear.
Some challenges will remain completed, while others will be optional for those that choose to complete them.
If the badges were previously unlocked, the recipes for the new survival gear should also be unlocked.

Highlights:
  • Biomes and their Challenges can be explored and completed in any order to unlock Survival Gear recipes
  • Recover from biome hazard effects while sheltered allowing players to explore deeper into each biome
  • Recover from biome hazard effects in any other biome
  • Smoothies were updated with unique names and icons
  • Biome Badges have been changed to Survival Gear with updated icons to look more thematic to the game's style
  • Survival Gear will be dropped on death with those settings enabled
  • Players are allowed to craft additional gear items in the case of death or even for other players
  • Even without Survival Gear, storms no longer require players to escape the biome they are in while taking shelter
  • Plague Spitters no longer cloak
  • Lower chance of infection from Plague Spitter Insect Swarm
  • Tree stump bees have been changed to a non-infecting version
  • Tree stump harvest event has been updated to guarantee honey "IF" bees are spawned
  • Several zombie types will now target animal or player corpses that were previously ignored
  • Added a 2nd column of icons to use for custom map waypoints
  • Several tweaks to zombie AI
  • Dew Collectors have a lower activity heat value

Here is how you participate:
  1. Right click on the game in steam
  2. Click on properties
  3. Click the “betas” tab
  4. The drop down menu will have latest_experimental available <— you want THAT
  5. Select that and wait for the game to download

Have fun!


Here's what changed since V2.2 stable:

Added
  • Bee Swarm entity variant for tree stump game event
  • Bee Swarm hand item with non critical debuffs
  • Updated icons for Biome Survival Gear
  • WornItemMods min effect requirement
  • HonkEvent for vehicles to allow game events to fire based on honking the horn.
  • AI wander and look are more active while alert
  • AI randomly turns during look while alert
  • Second column of icons to use for custom map waypoints

Changed
  • Removed erroneous second set of tags from ammoCrossbowBoltExploding
  • Disabled biome Wear, Loot, and Time challenges
  • Biome Badges are now separate weather items per biome.
  • Removed RepairItemsMeshDamage property from jail doors since they don't have a door frame stage
  • Taking shelter without survival gear will recover biome hazard effects
  • All biome hazards now have 3 minutes of survival time without gear
  • Survival gear is now dropped on death with drop on death settings
  • Updated icons for biome hazard reducers
  • Removed food and water stats from Black Lung Serum and Fallout Flush
  • Increased food, water, and health stat on Scorcher Stew to be inline with other stew stats
  • Increased water stat on Sunstroke Tonic
  • Updated the recipe for Scorcher Stew
  • Tree stumps now roll once for honey, then again for bees. Bees always come with honey, but not all honey comes with bees.
  • Reworked buff weights for a lower chance of infection from Plague Spitter Insect Swarm
  • Reduced dew collector activity value
  • Replaced plague spitter fade with a low rate of wandering
  • Storm messages will no longer say to leave biome
  • Biome Hazards recover in any other biome
  • Improved AI wander position variety
  • Increased AI alert time after investigation point reached
  • Increased rate AI interest distance returns to the default value
  • Updated shotgun shell icon to match other shotgun ammo icons

  • Fixed
  • AI ranged projectile attacks would start when the target was dead
  • Frostclaw, plague spitter, spider, cop, mutated and demolition zombies would not eat animal corpses
  • Water is not visible through glass
  • Distant water seam if near water is to the side
  • Underwater distortion could be clipped at certain angles
  • Trader Bob VO Trade 17 line cuts off
  • Air drop marker still shows when setting has it off
  • NRE when spawning insects after destroying tree stump using vehicle
  • Icon background textures not cleared when switching between containers - second issue
  • AI wander random range was 1m too short and only used 1m increments
  • Biome spawned AI move speed increase from storms did not happen at night
Click to expand...
When is this 2.3 update coming to console?
 
zztong said:
I think I see. You're suggesting that if there's an algorithm computing environmental light based on the player's location, perhaps that calculation also could inform the storms, so no additional computation would be needed. Yeh?
Click to expand...
Exactly, I just got too detailed in trying to show how, since I don't code I could only explain it
from how I physically saw it happen. The only other change would need to differentiate between
whole block, and broken block. So windows would work right also. 0-100 would be for buff timer
speed, for increase and decrease, instead of Wham---There it is. to make it feel dynamic.
 
You must log in or register to reply here.
Back
Top