White-Gandalf

June 27, 2023

@RipClaw: Yes, the principal dependency was told by TFP, but they "forgot" to implement an ingame description of those dependencies in about half the cases. The workbench, specifically, has not a single line of text describing its dependency on any perk point investments.

The only way to get those dependencies for sure is to analyze the contents of the XMLs.
Now, imagine making a stream and then switching in stream over to XML editing to get crucial infos needed for progressing ingame.

Even if the audience accepts such a "gameplay" style, the randomness of character development remains completely in the hands of dice.

Back in the old days, 7DTD had a roleplaying element of character development in it. That one is gone, too. With so many other good elements.

The amount of modding before 7DTD becomes enjoyable again grows with every alpha released.
I don't see the game developing in a direction that could eventually be titled "final". The "unfinishnessity" grows ever bigger.

June 27, 2023

Just to ride that horse a little longer: I carefully read all the perk point descriptions in the new alpha to get ANY hints on how they would influence the dice rolls.

Fact is, there is not a single line of description telling what perk actually would up the dice rolls for workbenches. Since Perks and Skills are gameplay wise completely decoupled (with the dice roll modification only being invisible and untouchable underground), without a description somewhere in the game, you are forced to go analyzing the XMLs.

THIS is the complete contrary to what i consider a "good" ingame experience.

Consider making a stream and having to regularly switch over IN STREAM to some XML editor or even excel worksheets, where you extract the documentation that TFP "forgot" to implement in the completely reinvented perk/skill system...

This is simply big.bull.@%$#.

Only on top of making the whole perk/skill system dice rolled. Did i say "BBS"?

June 27, 2023

On 6/22/2023 at 2:34 PM, meganoth said:

Nice idea, but somewhat time-consuming and expensive for TFP to do as they would have to optimize and balance the LBD system as well and if the "player base" would then want perks back they would have to scrap all other work they have done in the meantime and integrate that with the perk system again. Also they could not add bandits at the same time as that would influence the vote as well.

Maybe a better way would be to actually provide two versions, one with perks and one with LBD. So everybody can have what he wants. Drawback is that TFP would have to support both versions.

(Actually we have two versions available, one with perks and one with LBD (DF). But for some the availability of a mod doesn't count)

Is that a kind of joke?

TFP have completely reinvented the skill/perk system with EVERY alpha out there since at least A15.
Every alpha, they have thrown every thing they had into the bin and completely redone the whole system.

How on earth would you better describe "time-consuming and expensive" than by what TFP HAVE ACTUALLY DONE all the time? <shaking head> <LOL>

June 27, 2023

You are lucky not mining beneath a building - with WALLS!! Or beneath a trap field - with TRAPS!!
The bug is some of the very well-hung ones, lurking in the code since the beginning of the last decade.
I was teleported into walls as well as into traps as well as right into the arms of wandering zombie groups - back till Alpha 13. And i would rather expect that bug being there for far longer already.

June 27, 2023

The Skill system in A21 works out as a pure dice game. Well, guys: I was below 10 when i came out of the age of having fun rolling dice. I switched to chess in those years in the last millennium.

In my first run, i am now in week 4. And all the Avatar has learned is how to make steel tools.

BUT: Without the dice puking out steel tool parts. Not at the trader. Not as quest rewards. Not as loot. Nothing. The Avatar is just far too low on level that those things could have a chance to pop up in the loot lists.

BUT 2: Without letting the Avatar learn the workbench skills. At the end of week 3 (imagine, yes?!), the dice rolls lastly gave him the opportunity to learn a FORGE !!!

A FORGE !!! At the end of week 3 !!!

You can't tell that your grandchildren at the campfire. It's just awful.
At least, i got a chance to buy a workbench from the trader in week 4. But i had to quest two days in a row just to get my fingers on that beauty!

So i'm now stuck with an Avatar having the ability to make hight level steel tools - IF he WOULD have the possibility to use that skill. But since he doesn't, i'm stuck with a completely mis-skilled guy. What he was granted by the dice, he is unable to use. What he needs direly he isn't granted by the dice.

I have watched some guy playing Skyrim "on dice" - with every decision, including perk development, being decided by dice roll. THAT is exactly how i'm feeling being forced to play 7 Days nowadays. In 7 Days we are back on the level of "Mensch ärgere Dich nicht" - where all you can do as player is somewhat strategically steer the dice control wheel a little and then hope for the best and live with the worst.

I don't put that on the plus side of the ideas of the funpimps.

==========================

Would there be a possibility to mitigate that catastrophic mis-skilling?

Yes, of course there is: You could, for example, make the dice rolls in line with what the Avatar DOES in the game. Instead of with what the Avatar FINDS - per pure dice rolls. So you would reduce the dice-rollingness of the gameplay from TWO mutually reinforcing Levels - as it is at the moment - to one level less. THAT at least would be a tiny little step in the right direction - you know: "having FUN" and such shenanigans.

If you correctly implement that principle, you land back at "learning by doing" - just randomized by dice rolls.

But the funpimps could have saved whole 5 Alphas with each completely redesigning the perk/Skill system. Just use your working time for USEFUL things like gameplay issues that lurk in the code since decades already.

March 25, 2022

On 2/28/2022 at 5:51 PM, Boidster said:

The principles of secure client-server gaming netcode over TCP/IP were developed by 1971?

Well: Unix was invented 1969. Not 1971. You have my commisaration

And, by the way: Unix is only one little example of correct client-server division of accountability.

For Noobs in programming: Make a simple google search for keywords like "top ten programmers mistakes client authentication". The Top-10-Lists nowadays mostly don't even include the crucial mistake to let clients do the authentication by and fpr themselves. This blatant beginners mistake is so abysmal wrong that only in beginners courses for web programming, you will have a chance of getting instructed to NOT do it. In all other cases, it is taken for granted that a programmer has no way of being THAT bloody dumb to fall for such a basic pit.

February 28, 2022

A few moments ago, a hacking nipper showed me that he can do everything what SHOULD only be possible with admin rights when he simply joins a game of me.

If, in a client-server-system, the client has the possibility to activate things on the server that he shoud not be able to do, then said client-server system has a crucial flaw in its communication system. If it would have been designed correctly, those actions would NEVER be possible.

Every commercial client-server system crawling on its last toenail does this right. The principles were developed more than half a century ago. How in the hell does 7 Days get this that wrong?

February 22, 2022

Meganoth got that right: The problem at hand has nothing to do with determinism in relation to RE-LOADING a saved game. It has to do with determinism in relation to the CONTINUATION of the game AFTER EXITING it.

To clearify it by example: I am now on day 130 in that series where i took the pictures above. At the time i took them, i already had about 30 times the exact same contents of the vending machine - during the 60 days before. And i had them only 30 times out of 60 because i didn't search that machine more often, just that 30 times i mentioned. Up to the current point, i WOULD have seen 130 times the exact same contents (and never anything other) in that vending machine, IF I HAD continued to visit it every day in my series. Because i always cut episodes at 6:00 o'clock. Thus, when i LOAD the game to CONTINUE playing, the random number generators are restartet, and always with the exact same initialization vector.

This last aspect ("always with the exact same initialization vector") is the culprit at hand.

The fact that those initialization vectors are dependent on the name of the game does in no way conflict with the fact of the described bug. Since the name of the game does not change between sessions in the same game.

The solution to the problem is extremely simple: Just do NOT use the exact same initialization vector! There are a multitude of methods available to get randomized initialization vectors. Every CPU nowadays has some built in, every operating system nowadays has multiple ones built in, every crypto library provides you with some - it should be a miracle to miss all and every offer presented to the programmers.

January 22, 2022

expected behavior: The RNG used for certain operations in the game should get seeded with different seeds on every game load.

experienced behavior: The RNG used for certain operations in the game is wrongly seeded with the same constant seed on every game load.

tip of the day: While not being sufficient for cryptographic usage, you should AT LEAST incorporate the date and time stamp into the seed!

I firstly confirmed this fact in A19 with the contents of loot bags, which after reaching a certain level kept being the exact same for ever. Every first loot bag i opened in the game had the exact same content.

I reported that as a bug, but that report never got an answer, and the bug never got fixed, as i can now see in my first longer series in A20. Nowadays, the bug first occurred with vending machine contents being the exact same for the whole game EXCEPT if i had opened some loot box or bag beforehand - which occurred exactly ones in my 70 game days so far.

Since the deviation from the pattern occurred AT ALL, this confirmed that it is NOT INTENDED that vending machines do have the exact contents on every try.

Since the deviation from the pattern occurred exactly ones in about 30 tries, it is confirmed that the pattern is no rare coincidence.

See the following picture of vending machine contents i picked from the last videos (from the last few days): The one exception to the right was the one i wrote about three sentences further up (and which triggered the deja-vue-effect)...

Since the development of the character in this series was still in early stage, the contents of loot bags until now kept changing with every horde night. I will attach screenshot evidence about the boguous RNG as soon as i get repeating loot bag contents in this series.

January 21, 2022

Electric Fences used to be buggy all the time in previous alphas, but in this alpha 20, they went a dimension further up. See in this video at the linked timestamp:

1. dimension:

Expected behavior: When repairing, fence wires always get tightened

Experienced behavior: When repairing, fence wires sometimes get redirected into nirwana (indefinitely in a vicinity, and working at that wrong placement along the wire)

2. dimension:

Expected behavior: As long as not damaged, wires should work and thus damage incoming zombies

Experienced behavior: During horde night, wires suddenly stop working all at ones, while being damaged only to a certain portion of all wires (During repair, it is shown that only a portion of the wire receivers were damaged in the horde night, some are completely undamaged, some only slightly - those should never had stopped working during horde night)

In previous alphas, it was common place that wires arbitrarily changed their connections points between the tip and the bottom of the fence posts. Now in the A20, they get repositioned to complete nonsense while being repaired.

January 8, 2022

Thus goes the saying: Everything was better back in the old days!

January 8, 2022

Out of couriosity, i went back to previous alphas to compare the bugs....

For a more simple notation, i define shortcuts for the mentioned bugs:

VS: vertical stability bug (instantiating connection to bedrock does not propagate bedrock support vertically upwards)

VC: vertical chunk bug (stacking more than a chunk height of blocks disables weight calculation further up)

BS: bridge building bug (combining heavy and light blocks horizontally beside each other leads to collaps far below glue value)

VS VC BS

A20 bug bug bug

A19 bug bug bug (going upwards in versions, the versions with the most accumulated bugs so far)

A18 OK bug (1) bug

A17 OK (2) bug OK

A16 OK bug (1) OK (going backwards, the version with the most correct functionality so far!)

A15 OK OK bug

(1) vertical chunk bug in A16 and A18 does not allow horizontal deviation of more than 1 block; in A17, A19 and A20, you can go up to 15 blocks aside; other than that, it was the same in A16 and A18 (unlimited vertical stacking)

(2) vertical stability was buggy in A17, but it healed itself correctly as soon as any block was attached to or removed from any of the wrongly calculated blocks (the whole stack of blocks in vertical up direction was corrected at once)

Remarkably, the VS bug was absent in A18, and was existing but autohealing in A17 (thus altering in its appearance multiple times).

Remarkably, the VC bug was multiple times temporarily altered (not removed), but reappeared afterwards exactly as before.
Remarkably, the BS bug was temporarily corrected in A16, but reappeared in A18 exactly as it was in A15.

Remarkably, for the BS bug, the location of the attach position that leads to collapse was the exact same in all versions where the bug was existing, despite being gone for two versions in between. That leads to the suspicion that chunks of buggy code were preserved and reinstated. And in that, multiple times on multiple vectors independently from each other.

Guys: What the heck are you doing with your code base?!? What drugs are you on?!? Alternately, you can roll on the floor from laughing.

January 1, 2022

One of the most crucial problems that affect each and every player playing the game minecraft stile (by building structures) are the bugs in stability calculation. And those do not seem to be dismantled over the years and alphas, but quiet the opposite.

If the funpimps would allow the guy, who created the path optimization for alpha 17, to rectify the ridiculous buggy implementation of the stability model, i bet a rather big chunk of players would be thankful and glad about that decision. I would even go so far as to completely redirect all efforts that have gone into pathing stupidities since A17 - which are so perfectly pointedly described here by Rabbitslovecactus - to correcting those crucial, deep underlying bugs that strew salt into the otherwise outstanding gaming concept. Since years already.

January 1, 2022

1. KardinalZyn (https://www.twitch.tv/kardinalzyn) realized a bugged stability calculation with his castle build:

Attaching at least two blocks on top of each other to the side of some supporting column, you can stack unlimited load on top of that attached blocks.

I confirmed this bug using wood blocks.

expected behavior: You should not be able to stack more than 80 load on top of two wood blocks hanging from anywere (40 for each of them, amounting to 16 resp. 8 blocks of wood). The "stability color" of blocks hanging anywhere in the "show stability" debug view should go to deep red the higher the blocks stack. After exceeding the glue force, the hanging column should collapse.

experienced behavior: You can stack unlimited wood blocks in vertical up direction. The "stability color" in the "show stability" debug view keeps being CONSTANT for all hanging blocks in vertical up direction. See picture!

(P.S.: After further experiments, i realized that the "stability color" in the "show stability" debug view SHALL HAVE nothing to do with weights, but solely hints at the horizontal distance from the nearest supporting column. As with current buggy behavior, under certain circumstances, blocks get vertically miscolored because of bug (3). As soon as bug (3) gets fixed, the different coloring in vertical direction should disappear!)

You can repeat that sideways attachment on the "impossible" hanging tower. You can repeat that up to 15 times with wood/concrete/steel blocks (well: limited by the height of the world model, but not otherwise).

Example attached as picture.

2. That is not the only bogus appearance of stability calculation.

While building the "Völkerschlachtdenkmal von Leipzig" project, together with AsmodisdeSanktis (https://www.twitch.tv/asmodisdesanktis) i discovered that vertical support does not get recalculated after removing supporting blocks under a front of blocks that afterwards was hanging on a thin line of a single block height that was by multiple times too weak to hold the weight of the front of blocks. Only after going into debug mode and forcing "recalc stability", the front of blocks got colored in deep red.

3. Thereafter we discovered the next bug in stability calculation: After reinstalling support pillars under the hanging block fronts, were the supporting pillars have uninterrupted connection to bedrock, the stability for the blocks vertically above that newly reinstated pillar get a wrong stability calculation - as if they were not going up on the support column, but as if they were hanging sideways from the last inserted block of the support pillar.

expected behavior: ALL blocks vertically above any block with uninterrupted connection to bedrock ARE blocks that have uninterrupted connection to bedrock as well. All those blocks should be colored deep green in the "show stability" debug view.

experienced behavior: ALL blocks vertically above the last block of a newly reinstalled pillar with uninterrupted connection to bedrock are calculated as if they were hanging sideways from said last block.

This is essentially the inverse to bug (1) and (2): In THOSE, the hanging load does NOT get SUBTRACTED from the remaining load potential, thus leaving the blocks above with much too strong load support.

In the case of bug (3), the unlimited support from bedrock does not get propagated to the blocks directly vertically above the last block inserted after reaching previously hanging blocks, thus leaving the blocks above with far too weak load support.

Here is the video where at the beginning, i investigate bug (3):

Further experiments revealed that those "unlimited towers" as described in Bug (1) are only possible in randomly generated world. If you start a session in the navezgane world, those towers are not possible. There, the collapse of towers gets correctly calculated.

Thus arises the suspicion that the "unlimited tower" bug stems from a quick and dirty workaround for collapsing POI's in the Alphas since A17. Back then, collapsing POI's were a common appearance in all randomly generated worlds. I can perfectly well imagine that the funpimps simply limited the stability calculation as long as you play on such a randomly generated world to quickly get rid of those game breaking bugs. And that those code lines got preserved because they went out of focus.

Just another P.S.: Since more videos emerge on youtube these days about this family of buggy stability calculation, there are proposals that these bugs would have emerged only with the current A20. I can assure - from tampering with them explicitly in A19 - that these bugs are NOT new to this Alpha version. They were very probably already build in at least with Alpha 15, but back in those days i had no clue what the collapses resulted from, and i had no knowledge of the debug menu. But the manifestations of the phenomenons were rather equal to what we see today: structures with very high redundancy in structural integrity suddenly collapsing for no apparent reason.

=================

Just another bug from the same group of bugs...

expected behavior: IF you are able to attach a block further OUT at a hanging structure, attaching that same block further IN to the supporting point should never be impossible!

experienced behavior: The complete @%$# you can see in the video. It curls up my toenails when i try do describe that @%$# with words

======================

P.S.: Just another stability bug...

Sometimes, blocks show up having purple placing frames, suggesting that the thing would not be placeable. Despite no restriction on placeability at all.

I had have this type of bug on the terrain floor after removing the upper layer of top soil. But only on certain tiles, not everywhere.

And i had have it on certain occasions while placing forges and workbenches in my fortress:

All is well placeable, nothing gets destroyed. Nonetheless, the purple frame suggests it would be destroyed when placed.

October 28, 2021

Since at least A19.6 (but maybe earlier without me noticing) the random generator that is responsible for controlling the content of yellow lootbags is initialized an every game load with the exact same value, so that the first lootbag i find after every game load has always the exact same content. I have made a video series from my last solo game on youtube where you can proof it for yourself (

). Since around day 70 or so i always get a lootbag with a chainsaw, a recog and something plus. I'm literally swimming in chainsaws and regocs.

Only around day 100 or so i recognized the penetrance of constancy of the lootbags content and began making jokes about it.

The specific content will surely be different depending on other game parameters (name? settings?), but the constancy of the contents of loot bags over game loads is the problem at hand. You should check your code. Maybe some programmer made a mistake?

October 10, 2021

On 9/25/2021 at 9:59 PM, warmer said:

Survive 7 days without needing to kill a zombie

That would be an interesting end game achievement of sorts. This means you have crafted a self sustaining base and that in an of itself is my personal "win" goal when I play 7 days to die. If I can survive and get everything I need without leaving my land claim for 7 days, and without killing a single zombie myself, then the game has ceased to be a challenge, and in a certain sense, you have beaten it.

Well: that's usually the way i START the game. I never go into POI's as long as i am not strong enough to do so, and i am usually not strong enough until after several weeks. Since i always play permadeath style survival with always running (at least jogging) zombies, death in a POI or in the wilderness is simply no option, while hiding and stealthiness is an absolute must. Self sufficiency is the precursor of adventuring.

But to secure the environment of a whole city with a far stretched network of traps or autoturrets is for sure something for end game.

October 10, 2021

On 9/19/2021 at 8:47 AM, Gamida said:

Speaking of securing a large area. Do you know or could you find out if putting down player blocks will stop zombies from spawning on them. I have heard sometimes it doesn't work. Would be nice for those areas sligltly larger than your land claim area.

I was thinking along the lines of digging up the ground around the area and replacing it with something like dirt blocks.

Since A16 - i believe -, the attribute "CanMobsSpawnOn" is off by default. Thus, all blocks that are player made will not allow any zombies - Bloodmoon as well as random spawns - to spawn on them. Only blocks that are explicitly marked as "CanMobsSpawnOn" will allow those spawns. The player made block has to be the highest in the column from bedrock to ceiling.

Those blocks, however, do not suppress spawns in POI's.

Thus, you can suppress Bloodmoon hordes as well as all random spawns including screamers by sealing a huge enough area with player made blocks (f.e. woodframes).

October 10, 2021

I don't know for sure the exact details of the scripts working in the background, but i'm pretty sure of the following dependencies:

When clicking on "Login Twitch", the game must be able to start a web request via a browser - the one the PC owner has configured for his system. This browser must be able to execute javascript from the source "twitch" AS WELL AS from the source "localhost". I assume that the game opens a temporary http server on the client side when initiating the authorization request, where it waits for the authorization script from twitch to do a redirect to that temporary service on the client side (game on localhost). If either the script execution or the resource loading from twitch or the script execution or the resource loading from localhost is blocked (which, for example, is the case in my case per default), the "Login Twitch" will fail.

What you need to do if you have security measures in your system default browser in place, is to allow those resources and script executions from twitch and localhost.

Since the funpimps don't give away any text containing information on the "twitch settings" dialogue, i had to search the internet for help on this topic. I landet here in this forum. Since even here in this forum, the posts are completely wischi-waschi about the real problem, i had to play around with atomic ideas picked from them. Hopefully, a little technical text will be of help to technicians who are very well aware of terms like "browser", "security breach", "security measures", "script execution prevention" and so on, but have a rather hard time to interpret the babble of IT amateurs... Yes, such a text will not be understood by normal people, but "normal people" never have the problem at hand - which occurs solely to people who HAVE knowledge of IT things, because only those people will ever do anything to protect themselves appropriately from threats on the internet.

September 18, 2021

I usually play "permadeath-style" and difficulty adapted to my knowledge of the game. With that rule in place, i'm holding back from massively riding POI's. This has led to never having run out of unknown (and thus: interesting) places so far with about 8000 hours invested since A14.

There is a gameplay style which streamers and especially youtubers are highly addicted to, that involves perpetually and uninterruptedly raiding POI's SWAT-style until none remains unknown. This leads to a very intensive gameplay - which is what attracts viewers -, but at the same time minimizes the amount of time you can spend until you run out of goals. As long as you do not adhere to THAT style, you are guarantied to have a very long way to go.

In late game, i usually begin the building of prestige buildings. Since the funpimps are still having bugs with structural integrity simulation, those buildings tend to become mysteriously unstable at some point, were i usually start over.

But up to that point, i never run out of ideas to do in the game.

If you really are in need of stimuli, tale a look at youtubers like "Z-Nation FFS" or "J.C.'s Channel" or twitch-streamers like "Macinvisible"! There are a multitude of gamers out there that play 7DTD minecraft-style with building of huge fantasy and/or scifi worlds.

And in my humble opinion, THAT is where the true strength of 7DTD as a voxel based game plays out. There are endless many of games out there that let you chase enemies and raid POI's. But there are only a handful games that give you infinite freedom to build and destroy everything from atomic building blocks. Which, by the way, is THE ONE game that humans of all ages have been playing from childhood up to senectitude from earliest civilization stages up to modern computer age, independent from the materials that constitute the building blocks. That is the one reason why minecraft is so incredibly popular.

So, to round it up: The one thing you need in late game is: Fantasy style building!

September 17, 2021

I forgot: In addition to the underrating of meat, there is a bug in the animal definition (reported a long time ago) defining boars and deers at 1% of all game - letting chickens and rabbits make up 98%. The only visible animals in abundance are wolfs. Especially dire wolfs at night.

September 17, 2021

There are exactly two use- and helpful answers in this whole thread, both by meganoth. The rest is silly @%$#chat. It looks to my brain as if you want the newbies to be scared away...

September 17, 2021

I completely agree to the thread starter.

While accepting opposite opinions, my opinion simply goes strictly along the lines that the thread starter and some supporters outlined here.

And they did a good job in that: They systematically assembled all the aspects that drove me to write my own versions of "Localization.txt", and they perfectly listed all the aspects that i changed that texts to.

The problem possibly is the difference in personality that the funpimps and a certain bunch of players express.

For me, for example, systematicality, predictability, structuredness, intuition is crucial for having fun. I am a programmer and a perfectionist. All things that go against that principles lower my fun. The same seems to count for the thread starter. And the same seems to count for at least part of the people who try to become used to the game.

For the funpimps, at least parts of said principles are not so relevant. They prefer hilarity, fantasy, mystic in their expressions of descriptions.

For me, that difference is not an unscalable obstacle: If i want the babble of the funpimps, i move my "localization.txt" to a backup place. When i want to have a clear, systematic, structured, intuitively comprehensible GUI, i put my own "localization.txt" back in place. At least THAT was done well by the funpimps, that players have the possibility to adapt their gaming environment to their liking.

Maybe, in the long run, the modding community could provide an alternative "localization.txt" with all supported languages in the most wanted expression colors...

September 17, 2021

In my games, trees usually begin to vanish into invisibility at some point (usually when about one or two hundred new ones were planted). And only when the player char is looking in certain directions. Interestingly, their shadows still keep being visible and correctly rendered. And their invisibility occurs only occasionally, not always. It's usually OK in the first minutes after game loading.

Thus, everything around that exactly the same as what the thread starter is talking about and showing off. Except with trees instead of with workbenches and doors and so on.

Since it is dependent on the angle of view of the player char and it has appeared with recent versions only, i assume it having to do with optimization of the rendered scene content. Only in the latest versions (19 branch, i think), there were optimizations of suppressing things that should be behind the player. From that aspect, there could be some wrong calculation of the viewing direction of the player char. But since the shadows of the trees are still rendered, it looks like those trees are not only suppressed at a wrong angle, but also not sufficiently suppressed.

But since all that occurs only after some time of gameplay, there seems to be a bug at the bottom of the whole thing that is triggered from excessive scene loading. It looks like we are still poking in the dark at this point.

September 17, 2021

Well: I'm in with the thread starter regarding the value of meat. It is somewhat out of proportion.

Using meat as the main source of food in vanilla leads to having to eat multiple bears (not boars, you know?) per day.

While in a fantasy setting and even more in a game, proportions are subject to balancing, this mostly doesn't bother anyone. Thus trees grow faster than in real life by a factor of 100'000 and nobody becomes upset about that. As long as it goes in favor of simplification.

Meat is downplayed for that balancing by a factor of about 1'000. As that does not directly go in favor of the gamer, the gamer is eventually slightly upset about it.

Where i have an objection is the aspect that one egg is equal to 7 portions of raw meat in the recipe of Bacon and Eggs, for example. That amounts to the meat being nearly invisible razor thin slices of ham. Being one cell layer thick or so in that range.

What i did since alpha 17 was to define a modification where i bring all recipes in a somewhat intuitive relation to each other, where calories are not created out of thin air or pure water, but respect the incorporated ingredients and their cooking state (raw being less nutritious than heated) and have the cooking perk strictly correspond to the value of the buffs. That way it feels perfectly balanced and intuitive in gameplay. You still need a bear or two boars per day, but at least not a whole horde of them to survive.

September 17, 2021

Hi folks, i am again in the phase of a late game with building of bigger and somewhat experimental structures. As with every second game in 7DTD, buildings in this phase tend to become mysteriously unstable. While looking at the mess in this particular case, i realized a specific pattern of the broken structure that i have often seen at prefabs when those partially collapse after making an overhang react to structural integrity.

The case

The structure at hand has a span of slightly bigger than a (single one) chunk (19 blocks squared).

By pure chance, it has been built over the borders of three chunks so that it's load bearing walls lay in the outer chunks, while its hanging content lays in the inner chunk.

The redundancy of the structure is slightly below 200%, thus both walls are at least partially needed to hold the hanging content.

While building the structure, there was no problem at all: Everything was holding in place, with so much redundancy that i could temporarily attach and remove frame blocks in abundance.

After quitting the game, then doing stuff elsewhere, then returning two days later, i found the hanging content crumbled except a triangular part.

The hypothesis

Turning the visible pattern over in my mind and calculator, i came to a hypothesis as follows:

When approaching the structure from a state of unloaded from simulation, the game engine loads chunks of blocks. When loading the chunk with the hanging content of the structure, only the northern and western walls are loaded, but the chunks with the eastern and southern walls are still unloaded.

After having loaded the middle chunk, the game engine immediately starts the simulation of structural integrity for this chunk - instead of waiting for at least all the neighboring chunks to have been loaded into the simulation.

This leads to the simulation engine seeing a chunk of hanging blocks supported only from two sides and being slightly overloaded in relation to the load bearing capacity of said sides (since with all four walls being slightly below 200%, it is now slightly below 100%). This results in the partial collapse of the hanging blocks into a triangular shape.

================

A possible solution

If simulation of structural integrity is started only for chunks whose neighboring chunks are all loaded into the simulation, the problem would become irrelevant.

That's because the rules of the game state that the maximum supported length of an overhang is the length of a chunk - 16 blocks. With this rule in place and honored, it is not possible to construct a structure with more than a length of 32 blocks (two chunks length) hanging between walls. With no more than two chunks length hanging AND having the neighboring chunks loaded, it would become extremely unlikely to have a load bearing wall missing.

You could even render this completely impossible, if you only define the maximum supported length of an overhang to be exactly one chunk minus one block (=15).

But without delaying the structural integrity simulation until neighbor chunks loading, you will forever have cases like the one described here frustrating the customers.

another possible solution (possibly more simple)

If you would let the not loaded chunks be calculated as infinitely load bearing, the problem would not arise as well.

a possible workaround

Gamers can avoid having that issue by building bigger structures with incremental chunk loading in mind: If i had build the structure crossing the chunks exactly in its center, the thing would not have collapsed. Since in that case, the chunks would not have overhanging parts that exceeded the load bearing of the respective parts of the chunked walls.

The better way, of course, would be to have the calculation fixed in the game engine.

===================

Description of the attached picture

The perspective distortion of the image makes it look like it could be a non-quadratic structure. It is quadratic, 19 x 19.

Looking NNW. I entered the area from NE. The fighting platform at ground level is collapsed except a triangular part in the NE corner.

The fighting platform had a steel frame, concrete filling and walls all hanging between the steel plated outer walls at the west and east side.

The chunk borders run immediately beside the west and east outer walls, to the inner side of them.

Sign In

Profiles

Forums

Store

Articles

A20 Bugs

A21 Bugs

Events

Posts posted by White-Gandalf