Re: grenade bug needs to be fixed
Posted: Mon Feb 12, 2018 2:18 pm
So, how many urgent points are on that list before this one here?
I do care about this, but in retrospect it looks like it wasn't a priority.hi_leute_gll wrote: ↑Sun Mar 11, 2018 9:47 pm So this map isn't finishable since 7(!) weeks now. It really doesn't seem like heinrich cares about this at all.
Could you test whether #1091 fixes the problem? You need to be on the exact Binary map, with no changes. I can provide you with compiled executables if you tell me which operating system you're on.hi_leute_gll wrote: ↑Sun Mar 11, 2018 9:47 pm Also after talking to other people I didn't hear a single argument for the "fix", except the Race-Servers. But well...why would you destroy gameplay mechanics for hundreds and thousands of DDrace-players, to fix a server which has almost no active players?
PS: The pr seems to do what it is supposed to do. I asked a more skilled player to test it properly, we'll see what he says.hi_leute_gll wrote: ↑Sun Mar 11, 2018 9:47 pm Also after talking to other people I didn't hear a single argument for the "fix", except the Race-Servers. But well...why would you destroy gameplay mechanics for hundreds and thousands of DDrace-players, to fix a server which has almost no active players?
You don't destroy gameplay mechanics for hundreds and thousands of DDRace players. At least that's not the intention. You fix a bug that's not particularly interesting, as it requires frame-perfect grenades in the common case (when the grenade lifetime hasn't been set to 0 as on the map Binary).hi_leute_gll wrote: ↑Sun Mar 11, 2018 9:47 pm Also after talking to other people I didn't hear a single argument for the "fix", except the Race-Servers. But well...why would you destroy gameplay mechanics for hundreds and thousands of DDrace-players, to fix a server which has almost no active players?
The idea is that people won't create new maps based off this bug.hi_leute_gll wrote: ↑Fri Mar 30, 2018 2:27 am First of all, I understand your approach to create a general structure for different cases of bugs. Anyway, I wonder why you hard coded the map's name and hash. This basically means that every time someone wants to fix something (which is not related to this bug) he needs to ask a dev to change the code to make the map work again. Also if someone finds another bugged map it needs to go through the development-process to be added.
Yes, the code becomes more complex when there's a single map relying on a bug. I tried to limit the impact on the code, putting most of it in the new files.hi_leute_gll wrote: ↑Fri Mar 30, 2018 2:27 am Besides that I think you are overdoing it. You basically make the code more complex to make a single map work. That alone should show you that something is going wrong here. I don't think that we now should start to alter the physics and then code additional physics for every map which brakes due to that. In long-term that would end in a big mess and inconsistent gameplay experience.
Thanks.hi_leute_gll wrote: ↑Fri Mar 30, 2018 2:27 am I asked a more skilled player to test it properly, we'll see what he says.
Maybe I didn't explain myself properly: If someone alters the map (e.g. a design fix), then the hash of the map would change and thus he would need to change the code. Also if e.g. people use this map on other servers/locally, alter things to try something out, etc. then the map just doesn't work anymore.heinrich5991 wrote: ↑Fri Mar 30, 2018 4:58 amThe idea is that people won't create new maps based off this bug.hi_leute_gll wrote: ↑Fri Mar 30, 2018 2:27 am First of all, I understand your approach to create a general structure for different cases of bugs. Anyway, I wonder why you hard coded the map's name and hash. This basically means that every time someone wants to fix something (which is not related to this bug) he needs to ask a dev to change the code to make the map work again. Also if someone finds another bugged map it needs to go through the development-process to be added.