Jump to content


  • Posts

  • Joined

  • Last visited

White-Gandalf's Achievements


Survivor (3/15)



  1. Thus goes the saying: Everything was better back in the old days!
  2. 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.
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. 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).
  8. 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.
  9. 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!
  10. 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.
  11. 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...
  12. 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...
  13. 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.
  14. 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.
  15. 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.
  • Create New...