Jump to content
Report an Alpha 21 Bug!

White-Gandalf

Members
 View Profile  See their activity

  • Posts

    101

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

White-Gandalf's Achievements

Hunter

Hunter (4/15)

10

Reputation

  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 started following Skill system in A21 is practically the same as pure dice play - no planning, no intelligent gameplay possible , A21 is... definately better... but... , Learn by doing instead of reading? and 1 other
  3. 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"?
  4. 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>
  5. 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.
  6. 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.
  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
    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.
  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
    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.
  11. White-Gandalf started following World Model discrepancies between Clients and Server - Bombs freezing in Air
  12. 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.
  13. White-Gandalf started following A 20.4 - AI improvement implemented?
  14. White-Gandalf started following Heatmap goes into lock, Screamer's scream doesn't call in Zombies and Explosions can damage non-exposed blocks
  15. 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?
  16. 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?
  17. 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!
  18. 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.
  19. White-Gandalf
    Could you please post a link to the previous bug report?
×
×
  • Create New...