The sever works on 1s ticks so if you transmit your data right after the tick minus your ping, then the feedback will come back at least 1s +2times your ping after that. And that is, providing there is no issue on the network. and no issue on the server. And the time to accept your module activation from the server is 0. Sometimes I activate 3 modules at once (shrtocuts) and 2 of them are active on next tick, but one can become active on the following tick.
And even then, it does not change that not having a direct feedback from the client is bad.
I’m fine with the toggles, but I think they should be able to be changed until the actual change takes effect.
For instance, you shut off a module and it starts blinking red until the current timer runs down… If you change your mind you should be able to switch it back on with no issue because nothing actually happened.
Feedback should be instant. You push and it starts flashing green until the module actually activates (green flash is client, activation and solid green comes from server). If you change your mind before server activates module then you should be able to shut it off with no ill effect.
To be clear, spool up, cool down, etc. are all active state changes and not affected by this, except as noted: you can que up an action, and the button will indicate that an action is qued, that decision can be changed at any time until the qued action occurs.
no, in my post I wanted to do that ot have a correct feedback of the game. And as I wrote here sometimes the game does not know if you are at range or not, so then the toggle state needs to be preloaded even if you are out of range.
then I made a post only for targeted modules because there was another application for this toggled state.
The client can do that, the event handler could change the state of the button. However that would be predictive, because the client can’t know for 100% certain the action is allowed. For example a cloak attempt may fail because a ship just passed within 2500, that would come from the server. So then it becomes just as or more confusing because the ship starts to cloak, then fails.
Agreed, if a toggle toggles on then off, why can’t it toggle back on?
That’s why you use an intermediate state. You push button and get green (or blue or something to avoid confusion) flashing until the state changes. If the action isn’t allowed then the green flashing stops, the action fails (maybe with a couple rapid red pulses and a noise to indicate failure), and you get a message as to why the action failed.
yes there is a behavior change, the client must be able to know this state, and must send data to the server to tell him you want to activate module until the server either answer fail or success.
It can happen, and like other said, try not to spam the button because it will either go on/off in a tick, or in the case of docking, reset the action)
When I am breaking gate cloak to cloak again, I press the button for the cloaking device once, then wait.
If the cloak works, I need do nothing. If the cloak fails, I get a message telling me so that flashes on screen. When I get that message I hit the button again. Because of the way it’s drawn, I can see if it flashes again, and if it does, I hit the button to cloak a third time, and so on.
It’s easy to make a mistake when breaking cloak if you’re not used to this, but that is why I practiced the technique in highsec. I still cloak up in my covert ops capable ships today when traveling in highsec. For one thing, it is good practice. For another, it can sometimes save your life, though you won’t know it when it does.
Then you’re wrong. The interface does not always correctly indicate whether a command has been received, and its actions do not always align with player intent. The player wants to say “activate this module”, but their button press could be interpreted as “activate this module” or “deactivate this module” depending on how the server processes everything. And the only counter, slowing down your sequence of commands sufficiently to see clear feedback, often gets you killed. Adding the option to shift-click or similar to send a command which can only be interpreted as “activate this module” improves the ability to translate player intent into game responses, which is a textbook definition of improving the interface. And really, what’s the argument against making the interface respond correctly with greater consistency? Some bizarre idea that learning how to manage the failures and quirks of the EVE interface is somehow “skill”, or that if you personally don’t have a problem with something then nobody else has a valid complaint?
That’s why he is a troll. He has nothing, does not want to improve the game experience. Just come here to be trash.
That, or those guys are so mediocre they can’t even realize they got used to a bad thing and being used to something that nobody else likes is the only thing they can be proud of.
The UI for module activation is broken. Theres no argument here.
It wouldnt be broken if i click a module. The cycle inmediately starts. And starts from bottom and end at where it started.
But since its broken. And it delays up to 2-3 seconds sometimes with the cycle starting on different parts of the module icon itself and ending in random points of it. There is much space for improvement.
Perhaps the feedback should happen client side even if the actual effect happens 2 seconds later on server side. So at least i know i actually activated the module. And The next few cycle could work on the desync to reflect actual server side actions on the client. Ofc this could still feel odd at some times as the active log feed on the screen would then suffer from desync.
BUT it would be still better than the current state where the cycle starts randomly on the module which causes severe OCD let alone fustration of false double activations.
So if you think there no room for improvement i feel sorry for you for being so ignorant. Just because it “works” as it is that doesnt mean it cannot be improved.