I see a few problems arising if you have doodads/units of your own that may be covering the invisible mouse over testers. Alternatively, if you set your testers to a high enough level as to not be occluded, you would be unable to test the mouseover for units below? However, an interesting and innovative proof of concept none the less.
An interesting theory, and to my knowledge the server does indeed run game logic at a specific interval, once every 1/32th of a second, though using triggers we will use only every second frame (1/16th). However I see no reason as to why the data editor would work it's magic outside of these frames when the rest of editor's functionality is so closely tied to it.
PS. Even the number used for the built in latency (125ms or 1/16th of a second) is a result of this.
PPS. Again, I would like this system to pan out but without some sort of side by side comparison it's all just *feeling*.
That last section of your post is my point exactly. Everyone is comparing the feeling of WASD latency to that of controlling units in a melee game. I would stake money on the fact that the trigger based input systems experience the same delay in responses as mouse issued orders. But they don't *feel* the same?
You hit the nail on the head. With direct movement from keyboard input your expectation is that the unit responds instantly. In a melee game you have no such expectation from the units you are giving orders to. It's the expectation of instant feedback that creates the illusion that trigger based WASD is less responsive than mouse input and I would argue that it is progammers same expectation of more effecient data based system that is causing the feeling of improved responsiveness.
I understand you believe it to be less laggy, but why? What advantage does a data table based WASD system have over a trigger one that reduces the delay in responses? And how do we know, beyond our belief that it *feels* less laggy, that it is in fact faster?
Don't get me wrong, I would really like to find a more responsive system than triggers, however I do not believe one can exist. Yes, delay and latency are different but in this case our former is a result of the latter. We can not reduce the network latency, so how can we look to reduce the delay?
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 exist.
For your second issue you will want to look at the Target Smooth+ field inside the camera data tables, specifically Smooth Time Min and Smooth time Max. Try turning them down to something in the range of 0.1 and 0.4 respectively.
Is there anyone who does regular mod testing that knows how to use the Default Map option inside your GE preferences? At the moment, every time I want to test a change to my mod file, I have to close my test map, close down starcraft, save the mod, re-open the test map, and test the document. It's especially annoying when you're trying to debug some trigger issue one line at a time. It would be ideal if I could simply test the mod directly without having to load up a secondary map. Any tips?
Syncourt, you are looking for something called Banks. Banks are used inside the trigger editor to store and access data across multiple maps. It's how the campaign deals with things like tracking mercenary/tech purchases for use inside missions outside of story mode. Banks will allow you to store the progress of a Hero in one map and utilize it in another.
Hello ocktober17. Are there any particular MOD/Map ideas that you are particularly interested in working on? Perhaps you could also provide a link to some of your own works if you have available.
Unfortunately, as has been established, there is no way to track mouse movement by itself without having the player trigger a Click event. The ONLY method of tracking mouse movement without relying on said events is to tie it's relevant movement to the position of the camera. This does however mean that you cannot lock your camera onto a unit.
All I meant was I misread your original post which led me to believe it was built ontop of the VS Framework as an Integration Package, ie. adding the galaxy/andromeda language into the VS IDE.
Vestras, first off, I love the project and the idea to build it ontop of the VS framework as an integration package. I was looking through the site and I came accross your talk of extensions for the project. What are your plans for this feature? I know .NET 4.0 has included Microsoft's new Managed Extensibility Framework. Is there plans to make use of this and, if so, when do you see it becoming available?
You would experience the exact same latency issues using ability commands as you would using key listen events. The only advantage I expect would be less network overhead, however a well structured key listen system should not generate that much overhead anyway.
0
I see a few problems arising if you have doodads/units of your own that may be covering the invisible mouse over testers. Alternatively, if you set your testers to a high enough level as to not be occluded, you would be unable to test the mouseover for units below? However, an interesting and innovative proof of concept none the less.
0
@RileyStarcraft: Go
An interesting theory, and to my knowledge the server does indeed run game logic at a specific interval, once every 1/32th of a second, though using triggers we will use only every second frame (1/16th). However I see no reason as to why the data editor would work it's magic outside of these frames when the rest of editor's functionality is so closely tied to it.
PS. Even the number used for the built in latency (125ms or 1/16th of a second) is a result of this.
PPS. Again, I would like this system to pan out but without some sort of side by side comparison it's all just *feeling*.
@RileyStarcraft: Go
That last section of your post is my point exactly. Everyone is comparing the feeling of WASD latency to that of controlling units in a melee game. I would stake money on the fact that the trigger based input systems experience the same delay in responses as mouse issued orders. But they don't *feel* the same?
You hit the nail on the head. With direct movement from keyboard input your expectation is that the unit responds instantly. In a melee game you have no such expectation from the units you are giving orders to. It's the expectation of instant feedback that creates the illusion that trigger based WASD is less responsive than mouse input and I would argue that it is progammers same expectation of more effecient data based system that is causing the feeling of improved responsiveness.
0
@progammer: Go
I understand you believe it to be less laggy, but why? What advantage does a data table based WASD system have over a trigger one that reduces the delay in responses? And how do we know, beyond our belief that it *feels* less laggy, that it is in fact faster?
Don't get me wrong, I would really like to find a more responsive system than triggers, however I do not believe one can exist. Yes, delay and latency are different but in this case our former is a result of the latter. We can not reduce the network latency, so how can we look to reduce the delay?
0
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 exist.
0
For your second issue you will want to look at the Target Smooth+ field inside the camera data tables, specifically Smooth Time Min and Smooth time Max. Try turning them down to something in the range of 0.1 and 0.4 respectively.
0
Is there anyone who does regular mod testing that knows how to use the Default Map option inside your GE preferences? At the moment, every time I want to test a change to my mod file, I have to close my test map, close down starcraft, save the mod, re-open the test map, and test the document. It's especially annoying when you're trying to debug some trigger issue one line at a time. It would be ideal if I could simply test the mod directly without having to load up a secondary map. Any tips?
0
@kioSkSC2: Go
Syncourt, you are looking for something called Banks. Banks are used inside the trigger editor to store and access data across multiple maps. It's how the campaign deals with things like tracking mercenary/tech purchases for use inside missions outside of story mode. Banks will allow you to store the progress of a Hero in one map and utilize it in another.
0
@ocktober17: Go
Hello ocktober17. Are there any particular MOD/Map ideas that you are particularly interested in working on? Perhaps you could also provide a link to some of your own works if you have available.
0
@XPilot: Go
Unfortunately, as has been established, there is no way to track mouse movement by itself without having the player trigger a Click event. The ONLY method of tracking mouse movement without relying on said events is to tie it's relevant movement to the position of the camera. This does however mean that you cannot lock your camera onto a unit.
0
@Vestras: Go
All I meant was I misread your original post which led me to believe it was built ontop of the VS Framework as an Integration Package, ie. adding the galaxy/andromeda language into the VS IDE.
0
Bah, I misread your post and got overely excited :P. Project still sounds great, will keep an eye on it.
0
Vestras, first off, I love the project and the idea to build it ontop of the VS framework as an integration package. I was looking through the site and I came accross your talk of extensions for the project. What are your plans for this feature? I know .NET 4.0 has included Microsoft's new Managed Extensibility Framework. Is there plans to make use of this and, if so, when do you see it becoming available?
0
You would experience the exact same latency issues using ability commands as you would using key listen events. The only advantage I expect would be less network overhead, however a well structured key listen system should not generate that much overhead anyway.
0
-DELETED-
0
-DELETED-