Main > General Discussion

Rebuilding

<< < (3/4) > >>

Carn:
at this point it might be a placebo effect, players thinking they can spam it fast enough makes it seem faster

Dutch Vanya:
Guuuuys, i just wanted to believe muse actually fixed something...

Extirminator:
Frame counting to check time accurately, I checked it after the fix, and it was a tiny bit slower. As I am already used to spam clicking, with the added faster rebuilds, and with what people said about the initial delay at the beginning, I still think spamming is better - at least for my own gameplay.
I am the kind of person that played too much times on hull side mob so if I play on balloon side I go nuts because everything is mirrored. I can't deal with gameplay change drastically so I never bothered to switch to holding.

Hilary Briss:
Have to say also feel Spam Clanking is faster.

+ You can slip on yer other tool and keep on Clanking

Spam Clamking is a good way to get Spanners clank as it were.

Queso:
As the person that spent months (I was doing other things too) fixing this, I can tell you a hell of a lot about the problems here.

First off, the hold down to fix was broken for a good long time. In fact, the systems weren't even designed to work properly initially for very strange reasons. Holding mouse used to send a packet of "fix this thing" every time the ANIMATION was set to play. Animation timings and gameplay balance change independently over time, so these were all out of sync. To fix this I later changed the system to instead send a swing at the proper gameplay database min cooldowns. Doing this also required a lot of weird changes to the swing animations in first and third person. (First person is still a little broken for reasons unknown. I am not a technical artist and there are some ancient bits of code down in those systems that never get touched anymore.) Now in theory this would fix the issue. However practice and theory rarely align. In situations with significant jitter on a network line (ie not LAN) some messages would arrive too early and not swing in time. Some swings that SHOULD be perfectly timed were coming in earlier than expected because ping was lower for this packet. (I missed it the first time because the only test case I could pull off was on lan or on good network conditions till it went live.) To properly fix it, the system had to accept some packets that came in slightly early (but not too early, we wouldn't want the system to be abusable). The repair would then be delayed until it could actually be accepted (in reality a very small number of server ticks). Now in some network conditions this still won't be AS fast as spamming the server with repair requests, but it should be near identical in most network cases. Now in theory spam clicking was actually IMPROVED by this fix though because you could get spam clicks in that forgiveness window and always have perfect timing. Meanwhile held down repairs can come in late if ping is increasing over this time period. However the difference should only ever be a server tick or two even with decent line jitter.

If you want to scientifically test it you should use a program like FRAPS to record and count the number of frames from the first mouse input being received to the time the part appears to be fully repaired on the UI. Timing it by hand is not precise enough to notice any differences at the time scales this fix might still be iffy. The animation however is still pretty broken and that can significantly affect perception of the problem. That and the fact that rapid clicking was ingrained for years in people's minds and you get the result of people still doing it. Hell I still do it and I fixed it!

Navigation

[0] Message Index

[#] Next page

[*] Previous page