Jump to content
Report an Alpha 21 Bug!

White-Gandalf

Members
 View Profile  See their activity

  • Posts

    101

  • Joined

  • Last visited

 Content Type 

Everything posted by White-Gandalf

  1. White-Gandalf
    @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.
  2. White-Gandalf
    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"?
  3. White-Gandalf
    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>
  4. White-Gandalf
    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.
  5. White-Gandalf
    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.
  6. White-Gandalf
    Just an addition: There are more bugs around the electric fences: 1. As long as the wires are correctly managed by the game engine, the wires are "hanging through" proportionally to their deterioration. They get straitened as soon as the corresponding "receiving" fence posts gets repaired. This tends to be erroneous at nearly the same rate as the previously describes bugs. This bug is as well preventable to some degree by exit/reload with the player standing at the location of the fences. 2. The wires tend to get wrongly connected to the fence posts when you leave the location far enough and then return (as with all the other three bugs describes previously). While normally, the wire should run from TOP to TOP of the fence posts, the wire often runs from top to bottom or from bottom to bottom (thus criss cross or even sunken into the floor, thus becoming useless). As with all the other versions of bugs around electric fences, these bugs may be prevented by exit/reload with the player standing at the location of the fences.
  7. White-Gandalf
    Just an addition: There are more bugs around the electric fences: 1. As long as the wires are correctly managed by the game engine, the wires are "hanging through" proportionally to their deterioration. They get straitened as soon as the corresponding "receiving" fence posts gets repaired. This tends to be erroneous at nearly the same rate as the previously describes bugs. This bug is as well preventable to some degree by exit/reload with the player standing at the location of the fences. 2. The wires tend to get wrongly connected to the fence posts when you leave the location far enough and then return (as with all the other three bugs describes previously). While normally, the wire should run from TOP to TOP of the fence posts, the wire often runs from top to bottom or from bottom to bottom (thus criss cross or even sunken into the floor, thus becoming useless). As with all the other versions of bugs around electric fences, these bugs may be prevented by exit/reload with the player standing at the location of the fences.
  8. White-Gandalf
    This is perfectly reliable to reproduce. I tend to play on max difficulty settings and because of that with a multitude of fences. With about 60 fences in place, those bugs would make the game unplayable. But there is a method of countering those errors: As long as the game gets reloaded (exit -> continue) immediately before the horde night at the very place of the horde night, mostly (still not always) those errors are gone. As Oxipe wrote, the error messages are NOT connected to the horde night, but to entities running through fences - as soon as those fences EXCEED A CERTAIN NUMBER. I'm still not certain about the exact limit, but having around 20 or more fences constitutes a near guarantee to get them. BUT: Exit/Reload while having the player standing at the location of the fences prevents them - mostly. Furthermore, this bug MAY be correlated to the bug where fence wires get redirected into infinity. For those not already knowing said bug: the wire between two fence posts can become redirected from one of the posts to a point in infinite distance. These wires have hitboxes and thus deliver shocks - up to infinite distance (well: at least up to the end of the map). These bugs also go away if you exit/reload the game while standing beside the affected fence posts. IF you see a wire going in this way to infinity, you can be sure to get null reference exceptions as well. Not necessarily for the SAME wires, but you get them.
  9. White-Gandalf
    This is perfectly reliable to reproduce. I tend to play on max difficulty settings and because of that with a multitude of fences. With about 60 fences in place, those bugs would make the game unplayable. But there is a method of countering those errors: As long as the game gets reloaded (exit -> continue) immediately before the horde night at the very place of the horde night, mostly (still not always) those errors are gone. As Oxipe wrote, the error messages are NOT connected to the horde night, but to entities running through fences - as soon as those fences EXCEED A CERTAIN NUMBER. I'm still not certain about the exact limit, but having around 20 or more fences constitutes a near guarantee to get them. BUT: Exit/Reload while having the player standing at the location of the fences prevents them - mostly. Furthermore, this bug MAY be correlated to the bug where fence wires get redirected into infinity. For those not already knowing said bug: the wire between two fence posts can become redirected from one of the posts to a point in infinite distance. These wires have hitboxes and thus deliver shocks - up to infinite distance (well: at least up to the end of the map). These bugs also go away if you exit/reload the game while standing beside the affected fence posts. IF you see a wire going in this way to infinity, you can be sure to get null reference exceptions as well. Not necessarily for the SAME wires, but you get them.
  10. White-Gandalf
    Summary: We have experienced world model discrepancies between clients and server in coop games. Pipe bombs get froozen for the server resp. other players while are being thrown correctly for the throwing player. Game Version: A20.6 Platform: Steam OS/Version: Windows CPU Model: three different configurations (thus irrelevant for the outcome) System Memory: three different configurations (thus irrelevant for the outcome) GPU Model and VRAM: three different configurations (thus irrelevant for the outcome) Screen Resolution: three different configurations (thus irrelevant for the outcome) Video Settings: three different configurations (thus irrelevant for the outcome) Game mode: MP host + client (on host as well as on clients) Did you wipe old saves? Yes Did you start a new game? Yes (at A20.4) Did you validate your files? Yes Are you using any mods? Yes EAC off Status: NEW Bug Description: In a coop series, during our horde nights, we use nearly exclusively pipe bombs as weapons. While in the beginning of the horde night everything works well, after some time (in our last instance after around 3 hours ingame) the game engine starts having discrepancies in the world model concerning our pipe bombs. SOME (not all) bombs start freezing mid air on contact with blocks. While freezing mid air, they are USUALLY (maybe with exceptions) NOT displayed as such for the throwing player, but for the other players. For the throwing player, they look as if they would fall as required by the physics model. On the server side and thus for the other players, they get modeled as freezing mid air. But not even that for ALL other players in the same way. You can get an impression from the matter from the videos of our last horde night: Tandemview: https://viewsync.net/watch?v=aHXeI_DzEIc&v=6MjAt7II8m4&mode=solo (videos available after 2022-11-12 12:00 GMT; problematic scenes beginning at 1:18:10) Detailed steps to reproduce the bug: 1) Build base like seen in the video 2) Start Horde night with multiple players (two sufficient) 3) Start throwing/igniting bombs 4) Repeat for about 10 times Actual result: Bombs start freezing. State of bombs start to have discrepancies between different players. Expected result: Bombs should keep falling as required by game physics. Bombs should be displayed consistently between different players. They should have the same state on the server side as on each and every client side. If a bomb sticks somewhere for one player, it should stick at the same place at the same time for all other players, too. Not that they should stick somewhere at all, that is. They should keep falling. Always.
  11. White-Gandalf
    Thanks! Yes, i didn't got the meaning of that change, so simply ignored it. Your clarification does the trick.
  12. White-Gandalf
    I have the impression that the zombie AI has been improved with the latest update... Is it possible that the AI properly attacks a widened range of block types? That's not a criticism, but to the contrary a compliment. I wanted a base that has an optimized pillar construction, but without beeing cheaty. While in the previous horde, i still had doubts about the AI attacking the pillars, after upgrading to A20.4, the zombies showed full dedication to dismantling the structure, while still being somewhat less effective than with other pillar blocks - which perfectly matches the aim of the gameplay of having some room for optimization, but not drifting into cheatiness.
  13. White-Gandalf
    Explosions, if they are defined with explosion radius bigger that the distance to the wall in question, usually damage blocks in the second raw. The damage is far less than that for the first raw, but not null. I have the impression that the filling of the volume, expressed in the block definitions as "opacity", has no influence on that ration of damage (first to second raw). Maybe the Funpimps could make this dependent on the opacity?
  14. White-Gandalf
    Explosions, if they are defined with explosion radius bigger that the distance to the wall in question, usually damage blocks in the second raw. The damage is far less than that for the first raw, but not null. I have the impression that the filling of the volume, expressed in the block definitions as "opacity", has no influence on that ration of damage (first to second raw). Maybe the Funpimps could make this dependent on the opacity?
  15. White-Gandalf
    Summary: Heat quits going up despite huge number of - deliberately created - heat sources. The screams of screamers quits calling in zombies. Either after a few had worked or even straight from the start. Game Version: A20.3 (b3) Platform: PC OS/Version: Windows CPU Model: AMD Ryzen 7 3800X System Memory: 64 GB GPU Model and VRAM: nVidia RTX 2060 S 8 GB Screen Resolution: 1920 x 1080 Video Settings: Custom (at about Medium) Game mode: SP, RWG Did you wipe old saves? Yes Did you start a new game? Yes Did you validate your files? Yes Are you using any mods? Yes EAC off Status: NEW Bug Description: In my current series ("Kill 10 K Challenge"), i tried to deliberately make use of screamer hordes. I tried to create screamer avalanches the same way as they appeared "naturally" in the last episode of my series 4 in Alpha 20. This is how screamer avalanches SHOULD and sometimes (well: always as long as you do NOT need them) DO work: This is how screamers a completely bugged (always when you want them): In detail about the bugs: (1) Firstly, the heatmap is bugged on its own. The heat, which is displayed in debug mode after double-pressing F8, "nearly reliable" goes into a kind of "lock", where it does not change on it's own despite having a huge amount of heat sources running. In this state, the heatmap reliably goes up by exactly 5% every time i put even a single sheet of wood into a campfire - independently from what other heat sources are burning. Thus, in this "lock mode" of the heatmap, i am able to reliably and repeatably create heat-wraps (and this screamer spawns) by placing and firing a wooden piece into a campfire exactly 20 times in a raw. As seen repeatedly in the video. Expected behavior is: Depending on the number and strength of heat sources (and calculating in their decay rates), the "heat" sum in the respective "heat shunk" should CONTINUOUSLY go up till wrapping around at 100% AS LONG AS the heat sources are burning. (2) Secondly, IF the heat has a wrap around at 100%, a screamer should ALWAYS RELIABLY be spawned. As seen in the video, at more than 50% of cases no screamer spawns at all. It LOOKS AS IF the screamer spawn as well goes into a kind of "lockdown", after which NEVER ANY screamer is spawned until restart of the game. (3) Thirdly, IF a screamer got spawned, this screamers screams reliably always go into a kind of "lockdown" as well. It is variable, after HOW MANY screams this lockdown initiates, but the lockdown is encountered RELIABLY and ALWAYS with EVERY try. I had a screamer that didn't spawn a single zombie (after which i declared the challenge as unsolvable by my approach), as well as some that spawned up to a handful of waves. But never did a screamer call in waves nonstop. Never was the spawning reliable. Expected behavior: Screamer SHOULD call in new waves of zombies with every scream thy emit (at the moment usually every 15 seconds as long as they see the player). (4) Fourthly, if some of the described lockdown bugs take effect, the bugs should vanish after restart of the game. Current behavior is, that the bugs vanish SOMETIMES, but not reliably and not always completely if at all. As seen in the video. Detailed steps to reproduce the bug: see second video! Actual result: complex, that's why see description! Expected result: complex, that's why see description!
  16. White-Gandalf
    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.
  17. White-Gandalf
    Could you please post a link to the previous bug report?
  18. White-Gandalf
    Could you please post a link to the previous bug report?
  19. White-Gandalf
    Summary: Enemy Animals can climb ladders despite "CanClimbLadders"="false" Game Version: A20.3 Platform: PC OS/Version: Windows CPU Model: AMD Ryzen 7 3800x System Memory: 64 GB GPU Model and VRAM: nVidia GTX 2060 S Screen Resolution: 1920 x 1080 Video Settings: Custom (about Medium) Game mode: SP Did you wipe old saves? Yes Did you start a new game? Yes Did you validate your files? Yes Are you using any mods? Yes EAC off Status: NEW Bug Description: Wolfs, Bears and Dogs are able to climb blocks of type ("class") "ladder" (specifically shapes "trellisSquare"). Since A20, there are a multiple blocks available to the player that have the functionality of "vertical climb". In previous alphas, those blocks were only available through the creative menu or by modding. Nowadays, they can be freely used everywhere. I suspect the functionality of the "CanClimbLadders" attribute being implemented as a specific condition against the original player made ladder blocks, not as a general means of blocking the traversal of blocks with the general "vertical climb" functionality (alias "class"="Ladder"). In the video linked below, you can see first a bear, then after a few minutes a pack of dogs, then a few minutes later a second pack of dogs climb the blocks of shape "trellisSquare"... https://www.youtube.com/watch?v=hgBW1VODqTA&t=6245 Detailed steps to reproduce the bug: (see video) Actual result: Animals climb ladder type blocks Expected result: Animals can not climb ladder type blocks
  20. White-Gandalf
    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?
  21. White-Gandalf
    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.
  22. White-Gandalf
    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.
  23. White-Gandalf
    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.
  24. White-Gandalf
    Thus goes the saying: Everything was better back in the old days!
  25. White-Gandalf
    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.
×
×
  • Create New...