EvilPolygons
Survivor
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?
PC V2.3 Experimental
- Thread starter Hated
- Start date
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?
zztong
Hunter
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.
Dreyseth
Refugee
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.
EvilPolygons
Survivor
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.
4sheetzngeegles
Hunter
I thought it was using the IsIndoors property, did that change.
EvilPolygons
Survivor
isIndoors only checks to make sure you have a roof above and walls around you. It doesn't check to make sure those walls could logically keep smoke or radiation from wafting into your shack.
4sheetzngeegles
Hunter
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.
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.
Sarakatunga
Refugee
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.
EvilPolygons
Survivor
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.
4sheetzngeegles
Hunter
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.
Riamus
Hunter
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.
EvilPolygons
Survivor
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.
4sheetzngeegles
Hunter
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.
zztong
Hunter
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?