well thanx much.... hopefully I can get somewhere on my script learning....... hitting all the compile errors to get past them to then see nothing happen was rather .... underwhelming lol...
thanx for the time guys....
Rollback Post to RevisionRollBack
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
I followed SoulCarveRRs idea, and used script to create a lot of triggers.
Because I think create trigger for each keypress and each player could work.
I use thread, where ever I can.(thread is basically a function that calls a trigger)
Every key Press Event will show a text message, i think it is faster then issue order.
About Script
WASD_main_script is where all the trigger will be created.
The Events will just setup a variable. And a periodic loop will check the variable and move the unit.
the Function TriggerEnable() is just noch fast enough, i can't use it to activate the keyUp trigger in time.
functioncall if(!runActions) { return false; } cost maybe 100 ms for each call. That is just a guess.
That functioncall exist in every premade trigger.
Result
If I play singleplayer on bnet, i still have 0.2 - 1 sec delay.(not the best, make me sad)
I like my jump. :D
Some Thought:
The best way to learn galaxy is write some triggers and study it in script editor.
Some of you guys could do it better. Let me know about it.
Other WASD concept,without time loop:
Last keydown event set an extra variable to indicate it is the last event
using a while loop to check if it is still the last and do its job.
That is useful, if u think the "every 0.05 seconds of real time" is not good enough.
there will always be a slight delay.... this is due to the why b.net registers players input to prevent cheating..... i dont think wc3 even did it this way.....
its not something a shooter game would normally do....
eh what can you do...
Rollback Post to RevisionRollBack
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
Every key Press Event will show a text message, i think it is faster then issue order. About Script
No it is not. There's some fundamental misthinking here. Issue order is just as fast as Text Message ( = instant ). They only thing that causes delay is the key input itself.
You could be dropping a million nukes at key press and it would still be just as fast as showing a Text message (well.. a MILLION nukes would probably lag.. a lot.. you get what I mean).
Starcraft synchronizes it's triggers as much as possible and every machine executes code themselves, to make sure that almost everything is executed at once and synchronously.
The only part where this system doesn't work is with user input. The computers cannot predicts what keys some player will press next. That's the ONLY place the delay comes from.
functioncall if(!runActions) { return false; } cost maybe 100 ms for each call. That is just a guess. That functioncall exist in every premade trigger.
Faaar less. To give you some directions: When I run a 30-digit long string through StarCode (doing a TON of string comparisons and searchings which are rather bad for performance) then this takes Starcraft about 13.5 milliseconds. And that's with the overhead of the trigger debugger.
A simple if-then with a boolean comparison needs a few nanoseconds to be computed.
And again - these things don't create network latency. They only create lag (performance lag) when there's soo many of them at once that you feel it lagging.
I don't know about you, but I've never seen a program that lags from a few too many if-thens. Maybe if you have a few hundred..
I use TextMessage, because Issue order move, need time to accelerate the unit.
And in my case. There is another trigger(every 0.05 sec do someting), that changes the move with delay.
I want to ONLY see the delay of the keypress event, sry for my bad expression.
About the "runAction" parameter (the if then else call) :
I just don't understand this parameter, i mean what is it? , where can I set it.
is this parameter = trigger initial on?
is this parameter = trigger is enabled? ( event still fire in the background?)
I thought if I don't check this variable,this function will always return ture.
less trigger instance could be blocked. This is just believe, I have no clue, how i should check this.
@SouLCarveRR: Go
We want to know the limit, I know there is a delay. Don't give up so easily.
My basic idea is always disable the current trigger for 0.05 sec. Prevent some spammed sync. reduce traffic.
The first try was deactivate keydown until keyup is fired.
So if I keep pressing W, there will be no second run of the same event.
but the triggerenable() is just too slow.
I started to disable and enable the same trigger in the same function call.
No, actually I think runActions is a relic from earlier patches. It was used to stop the trigger from running when it was disabled (runActions is a parameter, not a global variable).
They changed the handling though.
I think now it only exists so triggers are backwards compatible (if they removed it then all "old" triggers would suddenly break).
In short: runActions seems to always be true.
PS: If I remember correctly the official limit is 125ms. That's the inherent minimum delay that battlenet imposes on maps. Everything higher should stem from suboptimal connections between the players.
Ah yeah I havent been making any updates to this because well.... now that Im actually writing some scripts.... its time consuming getting them to work.... basically Im relearning how to do shit that would take me about 5 minutes in GUI....
Hopefully Ill see proformance increases by using script... either way its a fun little programming exerise for myself..
maybe Ill have something concrete to show this weekend.
oh ... and Im basically writing this to have 2 different modes....... one is where the player can control movement the other is not...
also im doing FPS like doom... not TPS so yeah running into some hiccups becuase follow unit isnt really meant to do this...
Rollback Post to RevisionRollBack
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
Do it like me, combine script and GUI.
The strengh os script is, u can build custom triggers. And u can code math function very fast.
It looks shorter,because u don't need to write 14*14 trigger in our case. :D
My functions like jump or trace enemy are in GUI, it is not slower. Because at the end, the GUI will be compiled to galaxy.
The speed optimation from myself, could all be done with GUI.
for FPS, there is a broken FPS engine on sc2mapster.
the camera is working.
U can also follow an invisilbe unit. Maybe it is better because u don't need colision detection. :D
the goal here is pure script..... I can make perfectly good custom functions useing GUI as well... only real difference is with scipt you can declare events at run time... which I still havent really attempted...
The GUI does add some pieces of code that are unneeded but for the most part I think it has very little effect on proformance.
since it looks like the women will be busy this week end I should make some good progress
If you only want to learn script because you hope to get a performance boost then go back to GUI.
Yes, you CAN script more efficiently in pure galaxy, but you won't notice a difference (as long as you avoid bottlenecks like the for-each GUI functions and whatnot).
The difference in performance is minuscule.
@s3rius: Go
well thanx much.... hopefully I can get somewhere on my script learning....... hitting all the compile errors to get past them to then see nothing happen was rather .... underwhelming lol...
thanx for the time guys....
@FuzzYD: Go
Thanx fuzzy your example works perfectly for what I wanted
Custom Script "HelloWorld" Event Sample
@SouLCarveRR: Go
Ay, no probs. Good to know it's working as you need it be : )
I followed SoulCarveRRs idea, and used script to create a lot of triggers. Because I think create trigger for each keypress and each player could work.
About Script
Result
Some Thought:
@avogatro: Go
there will always be a slight delay.... this is due to the why b.net registers players input to prevent cheating..... i dont think wc3 even did it this way.....
its not something a shooter game would normally do....
eh what can you do...
Just to clear up misconceptions:
No it is not. There's some fundamental misthinking here. Issue order is just as fast as Text Message ( = instant ). They only thing that causes delay is the key input itself.
You could be dropping a million nukes at key press and it would still be just as fast as showing a Text message (well.. a MILLION nukes would probably lag.. a lot.. you get what I mean).
Starcraft synchronizes it's triggers as much as possible and every machine executes code themselves, to make sure that almost everything is executed at once and synchronously.
The only part where this system doesn't work is with user input. The computers cannot predicts what keys some player will press next. That's the ONLY place the delay comes from.
Faaar less. To give you some directions: When I run a 30-digit long string through StarCode (doing a TON of string comparisons and searchings which are rather bad for performance) then this takes Starcraft about 13.5 milliseconds. And that's with the overhead of the trigger debugger.
A simple if-then with a boolean comparison needs a few nanoseconds to be computed.
And again - these things don't create network latency. They only create lag (performance lag) when there's soo many of them at once that you feel it lagging.
I don't know about you, but I've never seen a program that lags from a few too many if-thens. Maybe if you have a few hundred..
@s3rius: Go OK thx for the info.
I use TextMessage, because Issue order move, need time to accelerate the unit. And in my case. There is another trigger(every 0.05 sec do someting), that changes the move with delay.
I want to ONLY see the delay of the keypress event, sry for my bad expression.
About the "runAction" parameter (the if then else call) : I just don't understand this parameter, i mean what is it? , where can I set it.
I thought if I don't check this variable,this function will always return ture. less trigger instance could be blocked. This is just believe, I have no clue, how i should check this.
@SouLCarveRR: Go We want to know the limit, I know there is a delay. Don't give up so easily.
My basic idea is always disable the current trigger for 0.05 sec. Prevent some spammed sync. reduce traffic.
The first try was deactivate keydown until keyup is fired. So if I keep pressing W, there will be no second run of the same event. but the triggerenable() is just too slow. I started to disable and enable the same trigger in the same function call.
@avogatro: Go
No, actually I think runActions is a relic from earlier patches. It was used to stop the trigger from running when it was disabled (runActions is a parameter, not a global variable).
They changed the handling though.
I think now it only exists so triggers are backwards compatible (if they removed it then all "old" triggers would suddenly break).
In short: runActions seems to always be true.
PS: If I remember correctly the official limit is 125ms. That's the inherent minimum delay that battlenet imposes on maps. Everything higher should stem from suboptimal connections between the players.
@s3rius: Go Thx i can remove that thing. While u edit your last post, I changed my last post a lot, to make my idea clear.
Edit:
the interval of the move handler should be 0.05. = 20 times in a sec. Now i played the game for 2 min, 20*60*2 = 2400. but I got only 960 run...
OK minimum interval for time period check is 120 ms
Another Issue about camera
If I play my game, the mouse cursor disapears even after the game in bnet menu. I don't know why...
125 to be exact.
@avogatro: Go
Ah yeah I havent been making any updates to this because well.... now that Im actually writing some scripts.... its time consuming getting them to work.... basically Im relearning how to do shit that would take me about 5 minutes in GUI....
Hopefully Ill see proformance increases by using script... either way its a fun little programming exerise for myself..
maybe Ill have something concrete to show this weekend.
oh ... and Im basically writing this to have 2 different modes....... one is where the player can control movement the other is not...
also im doing FPS like doom... not TPS so yeah running into some hiccups becuase follow unit isnt really meant to do this...
@SouLCarveRR: Go
Do it like me, combine script and GUI. The strengh os script is, u can build custom triggers. And u can code math function very fast. It looks shorter,because u don't need to write 14*14 trigger in our case. :D My functions like jump or trace enemy are in GUI, it is not slower. Because at the end, the GUI will be compiled to galaxy.
The speed optimation from myself, could all be done with GUI.
for FPS, there is a broken FPS engine on sc2mapster. the camera is working. U can also follow an invisilbe unit. Maybe it is better because u don't need colision detection. :D
@avogatro: Go
the goal here is pure script..... I can make perfectly good custom functions useing GUI as well... only real difference is with scipt you can declare events at run time... which I still havent really attempted...
The GUI does add some pieces of code that are unneeded but for the most part I think it has very little effect on proformance.
since it looks like the women will be busy this week end I should make some good progress
@SouLCarveRR: Go
read my script above... Opensource is for people to open it.
EDIT:
maybe edit the data->camera-> max distance.
I forgot, if I changed this from 400 to 50 in that version.
@avogatro: Go
camera works just not happy with it yet
If you only want to learn script because you hope to get a performance boost then go back to GUI.
Yes, you CAN script more efficiently in pure galaxy, but you won't notice a difference (as long as you avoid bottlenecks like the for-each GUI functions and whatnot).
The difference in performance is minuscule.
@s3rius: Go
why is "for each" bad? I use it all the time and what is with "pick each"?
Eh, well it was for-loop, not for-each:
http://forums.sc2mapster.com/development/map-development/11071-a-warning-to-mapmakers/
@s3rius: Go
I thought the most recent patch they cleaned up some of thier for loop generated scripts....
oh and in that hello world example.... why do I have to declare the functions as bools and returns...
why cant my functions just be voids?
@SouLCarveRR: Go
Triggers NEED to return a bool. That's how they work. It's got something to do with the debugging.
Might be that they cleaned up the mess they did with their loop generation. I wouldn't know. I don't use it at all.