Using data editor cant possible get data from the current camera yaw. The other way of doing it relative to the unit's facing is talked just above so you can try trigger that force the unit to face the camera yaw anytime camera position is updated.
Yeah, but you mentioned offsetting a persistent by a point which is what the X/Y is for. As for offsetting by a units facing, that is tied to the Target/Source/Impact locations. For example, check this tutorial vid:
is the 8 ways still in development? ive been waiting for a save file of it so i can check out some things
Given the minuscule gain and huge efforts required I'm not planning on doing that. You can base it on the very detailed tutorials to make your own 8 way. It is not only for uses of WASD but for people to learn and understand the behavior/ability linkage in the data editor also.
My gamble is that perhaps while key-down is broadcast to all clients and synced perhaps key-up is ignored for the usually insignificant thing that it is
Key up is not as important as it does not give you the perception of responsiveness. They're just there to remove behavior, stop your unit while you're not pressing. How fast they react to key down is a problem
I can say based on the conception that melee (ladder) competitive game on battlenet does not experience too much delay issues compared to wasd map present. (why the hell would they release a network system for a RTS game if such latency is unacceptable) And all of the unit abilities is done via data editor. I might have made a mistake that causing it more delay then normal melee abilities should but that's the goal to aim for. If pro-gamers can spam 300 APM consistently and their unit is responding well. Why not ?
I don't understand the theory behind why this is meant to be less laggy than a trigger based system. The issue with any keystroke based movement system is the latency between the commands issued by the client and the response from the server. Both trigger keystrokes and the UI command card are subject to the same latency issue and, unless you are suggesting that a trigger system generates ludicrous amounts of network traffic, I can't see the advantage of using the data editor.
What I would really like to see is a video with a map using both systems side by side illustrating the differences between response times, if they even exsist.
This one is definitely less laggy than with current trigger version but not meant to get rid of the delay. The delay might improve a bit by not having to go through trigger validation. (Lag and delay are different). And yes the trigger systems generate quite a lot of traffic for Key Pressed events
Its fine if you don't use it. Its just a tutorial for exploring the data editor anyway. I hope for more creative use of the data editior by sharing it out.
In milliseconds, how much delay do you think this has, compared to the older ones? Somewhere like 50ms? Where the past WASD was like 100ms?
Well delay for command order for bnet was orginally 250ms, then down to 125ms at the end of beta. If it stays the same, I would saying this delay is 125ms, while the trigger ones is more like 250ms (yep its hard to tell how much the delay was, but easy to tell it exist)
Back to da topic: That's pretty interesting, I didn't think you could set-up the abilities in a way it would not stop the movement after the effect has been applied once. But now when I think of it... even the melee game has such buttons in it >.< Using a different mover you can also rigg the pathing in a way they would stop trying to run around cliffs but instead try to move through them (which would fail). That would make the unit less jumpy when running against a wall.
I can add more validator to check cliff level and such. And remember, this is just a beta system. The data editor is more powerful than you can think.
I made a 4 way button press via data + triggers (data in the sense that he casts a spell and I use that as an event) and from what I can tell, it doesn't lag any either. The best way I can think of making an 8 way via my method would be to make the W and S a toggle while the A and D are for changing the angle of your unit. I think this wont really be interrupting the nature of moving at all, but it would take some getting used too. I'm thinking there may be a way to reduce the transparency or something similar of the ui that you must keep up via the galaxy editor. Wc3 had custom skins and things for the ui, I'm not positive how they worked, but couldn't someone just replace all the ui with nothing?
The problem with that is you cannot detect a key up event, just key down is registered when you activate that abilities. If you decided to use the hold down button method as mine, you probably need a periodic trigger of 0.1s. periodic effects can be set to 0.01s with no lag