V2.6 Stable

Roland said:
Now now now....things are not that bleak. Try 2.6 with 0% jar return and just ignore the dew collector. I've found that I actually enjoy dumping all my sand in the forge now and crafting jars to fill up and boil on the campfire. I've also enjoyed installing a well in my base near my campfires. If I want a dew collector for its sexy profile on the roof of my base I'll craft one at some point but it's nothing to avoid playing 2.6 over. The way I see it, the dew collector is a lateral choice to the campfires now. Do it if you like them or don't do them if your campfire setup is good enough.

So far in my play with 2.6 and my testing of 3.0 I haven't tasted any hint of BI curdling in the TFP milk. It still all seems 100% fresh TFP for now.
Click to expand...
I'm not saying I won't play it. I already have a mod to remove jars from dew collectors. It just left a bad taste in my mouth and I've played enough to be bored anyhow. I'll play it again eventually.

Although a lot of the lack of interest in watching posts comes from that bad taste, it is also a lot to do with the kinds of inane posts and troll posts we've been seeing over the past months. Seeing a dozen off topic posts of back and forth about stuff that was answered and explained repeatedly gets really old, even when using the ignore option since that only hides one side of the conversation.

Old Crow said:
And I thought Dano was the doom and gloom guy.
Click to expand...
Yep. But that doesn't mean I have to be happy about everything. At least I'm not writing dozens (probably hundreds at this point) of posts saying the same thing. But I have no problem making it clear that the changes push me away from wanting to play the game. TFP won't care what I think about it, but they should see that their changes aren't liked by everyone so they understand that not everyone likes the changes regardless if the loud people make it seem that way.
 
Last edited:
im just happy that the parts i dont like can be turned off. Finishing off my 2.5 game in2.6 and the next game will have the stupid biome progression off. i gave it a go but its not adding anything to the game just an artificial slow down to getting to the next biome. its so easy to cheese .
 
Tialas555 said:
As I understand it, fataal will always ignore me on the issue of optimizing the server core? Since he hasn't answered this question for several months with repeated mentions, he answers the rest of the questions
Click to expand...

That is a pretty good assumption if what you state is true. That’s how I would take it as well.
 
Riamus said:
Faatal said they plan to have both 3.0 and 4.0 out by the end of the year. Knowing TFP, I don't hold out hope for that to happen, but I'm thinking around March next year for 4.0. I expect 3.0 will be out this year, and probably by the end of summer since it's mostly just a bunch of options.
Click to expand...

Pretty sure I saw a timeline somewhere and for the past multiple years they've either released updates in June or December, and one time in July. As a realist, it's logical this pattern will continue, so at the earlier I'm betting June (maaaaybe July) for 3.0 and Dec for 4.0, but the realist in me says Dec for 3.0 and June-Dec 2027 for 4.0
 
It's just that I see that the game developers don't optimize at all, they're even too lazy to enter a few lines in their threading engine, which greatly optimize the server side:
// BEFORE (broken):
entity.aiClosestPlayer = player;
entity.aiClosestPlayerDistSq = distSq;
entity.aiActiveScale = scale;
emodel.JiggleOn(false);

// AFTER (safe):
Volatile.Write(ref entity.aiClosestPlayer, player);
Interlocked.Exchange(ref entity.aiClosestPlayerDistSq, distSq);
Interlocked.Exchange(ref entity.aiActiveScale, scale);
// Remove JiggleOn() from background thread — Unity API is main-thread-only
// Queue it: MainThreadDispatcher.Enqueue(() => emodel.JiggleOn(false));

// BEFORE (broken):
[HarmonyPrefix]
static bool Prefix(EntityAlive __instance) {
if (IsFar(__instance)) return false; // skip EVERYTHING
return true;
}

// AFTER (safe — lightweight update preserving physics):
[HarmonyPrefix]
static bool Prefix(EntityAlive __instance) {
if (IsFar(__instance)) {
// Keep minimum physics so zombies don't fall through blocks
__instance.entityPhysics?.ApplyGravity();
__instance.entityPhysics?.CheckGroundContact();
// Skip AI tasks, pathfinding, animation — these are the expensive parts
return false;
}
return true;
}


// BEFORE:
private static readonly int CacheDurationMs = 2000;

// AFTER:
private static readonly int CacheDurationMs = 500;
// Or better — use velocity prediction:
// var predictedDist = (entity.pos - (player.pos + player.velocity * cacheAge)).sqrMagnitude;


Even due to this, players will be able to more than write an optimizer that will change threading options and increase the server FPS by at least 2 times with 20 people online
 
Tialas555 said:
It's just that I see that the game developers don't optimize at all, they're even too lazy to enter a few lines in their threading engine, which greatly optimize the server side:
// BEFORE (broken):
entity.aiClosestPlayer = player;
entity.aiClosestPlayerDistSq = distSq;
entity.aiActiveScale = scale;
emodel.JiggleOn(false);

// AFTER (safe):
Volatile.Write(ref entity.aiClosestPlayer, player);
Interlocked.Exchange(ref entity.aiClosestPlayerDistSq, distSq);
Interlocked.Exchange(ref entity.aiActiveScale, scale);
// Remove JiggleOn() from background thread — Unity API is main-thread-only
// Queue it: MainThreadDispatcher.Enqueue(() => emodel.JiggleOn(false));

// BEFORE (broken):
[HarmonyPrefix]
static bool Prefix(EntityAlive __instance) {
if (IsFar(__instance)) return false; // skip EVERYTHING
return true;
}

// AFTER (safe — lightweight update preserving physics):
[HarmonyPrefix]
static bool Prefix(EntityAlive __instance) {
if (IsFar(__instance)) {
// Keep minimum physics so zombies don't fall through blocks
__instance.entityPhysics?.ApplyGravity();
__instance.entityPhysics?.CheckGroundContact();
// Skip AI tasks, pathfinding, animation — these are the expensive parts
return false;
}
return true;
}


// BEFORE:
private static readonly int CacheDurationMs = 2000;

// AFTER:
private static readonly int CacheDurationMs = 500;
// Or better — use velocity prediction:
// var predictedDist = (entity.pos - (player.pos + player.velocity * cacheAge)).sqrMagnitude;


Even due to this, players will be able to more than write an optimizer that will change threading options and increase the server FPS by at least 2 times with 20 people online
Click to expand...
Did you test that in an actual game? :unsure:
 
got a question about biome progression quest kills.
To get the radiation gear for the wasteland one of the quests is to kill 5 mutated and 20 zombies.
after you have killed 5 mutated why do thy then not count as biome zombie kills?
i got my 5 and had 15 kills as well. killed 3 more mutated and still on 15/20. is this by design or is it overlooked? i realise the the first 5 you kill cant be counted in the 20 but after you have the 5 then they should count for the general 20 you need.
 
spud42 said:
got a question about biome progression quest kills.
To get the radiation gear for the wasteland one of the quests is to kill 5 mutated and 20 zombies.
after you have killed 5 mutated why do thy then not count as biome zombie kills?
i got my 5 and had 15 kills as well. killed 3 more mutated and still on 15/20. is this by design or is it overlooked? i realise the the first 5 you kill cant be counted in the 20 but after you have the 5 then they should count for the general 20 you need.
Click to expand...
It's by design. Look at it this way; kill 5 Mutated and 20 of Any Other Kind of Zombies (Mutated not included).
 
You must log in or register to reply here.
Back
Top