Yea but Player Number is an integer, so filling in a value of 1, would mean player 1
If you want to program in more modular ways you would never use a static value of 1, rather in this you would put dialog items in an array and then only show the dialog item when player number = index array number, thus in theory it would be ready for infinite amount of players
But for now you should just use static values, get to know the editor - good habits will develop
You have 2 dialogs but you only need 1 still, you can simply add both texts to the same dialog, ontop of eachother, and hide the wrong text for each player. Just a bit more efficient
An easier way, if these adds share a characteristic such as unit type, would be to just Remove Unit and get all units from the entire map belonging to the enemy player (and possibly sort them by unit type)
Like this
Unit - Remove (Unit (Number of Living units in (Any units in (Entire map) owned by player Any Player matching Excluded: Missile, Dead, Hidden, with at most Any Amount)) from (Any units in (Entire map) owned by player Any Player matching Excluded: Missile, Dead, Hidden, from the game
Although this looks complicated, it is actually only
The problem is that the thing you are doing inside the actions of your periodic event cost too much time. Normally, even at 0.01second, this is not a problem. Unless you are using any sort of loops in there. Anything that can cost any realistic time (a wait loop for example) will stay alive until expired. At 0.01 this created 100 of these loops per second.
The longer these loops last, the more threads are created.
If its not too long, post your periodic event action list.
First problem:
Make a global variable of type Dialog Item. Set Variable (Last created dialog item) to it. Now you can check if that was the button which was pressed. You can check with Used Dialog Item = variable.
The second problem was that you called 2x Map Initialization at the same time. Your pause was being run before the timer was created.
0
Yea but Player Number is an integer, so filling in a value of 1, would mean player 1
If you want to program in more modular ways you would never use a static value of 1, rather in this you would put dialog items in an array and then only show the dialog item when player number = index array number, thus in theory it would be ready for infinite amount of players
But for now you should just use static values, get to know the editor - good habits will develop
0
You have 2 dialogs but you only need 1 still, you can simply add both texts to the same dialog, ontop of eachother, and hide the wrong text for each player. Just a bit more efficient
0
You dont need to cut back, only optimize
0
I see, but these 2 dialogs do the same but for another player? Since they are called nearly the same
0
There is only one button so only one trigger is needed
Any number of players can press it
You simply call for Triggering Player to see which player in fact pressed it You are thinking far too complicated
And no there is no variable changed event but you can simply call a different trigger by doing Run Trigger when you change your variable
0
An easier way, if these adds share a characteristic such as unit type, would be to just Remove Unit and get all units from the entire map belonging to the enemy player (and possibly sort them by unit type)
Like this
Although this looks complicated, it is actually only
and then the same thing, just recreate above
0
You can use Triggering Player for that. Which will be the one who pressed the button.
For example:
Event: Any Dialog Item is Used by Any Player
Condition: Used Dialog Item = StartDialog
Actions: Hide StartDialog for Triggering Player
Just a random example, but you can base alot of stuff on this.
0
I like your coding, very clean :)
0
@DoubleElite: Go
Unit - Move Unit Instantly
0
The problem is that the thing you are doing inside the actions of your periodic event cost too much time. Normally, even at 0.01second, this is not a problem. Unless you are using any sort of loops in there. Anything that can cost any realistic time (a wait loop for example) will stay alive until expired. At 0.01 this created 100 of these loops per second. The longer these loops last, the more threads are created.
If its not too long, post your periodic event action list.
0
First problem: Make a global variable of type Dialog Item. Set Variable (Last created dialog item) to it. Now you can check if that was the button which was pressed. You can check with Used Dialog Item = variable.
The second problem was that you called 2x Map Initialization at the same time. Your pause was being run before the timer was created.
Attached is your fixed map.
0
Hmm version 0.1... I gotta wonder how awesome 1.0 will be then :) Looks quite promising
Btw, nice picture on that video :P
0
Event - Any Unit Dies
Conditions:
0
I believe it is something like gv_Varname or lv_Varname for local vars
The Varname being the script identifier of the variable in question
For functions it will be the script identifier aswell (possible with func_ infront of it, not sure)
Not experienced with custom script but I picked that up
0
Yep use a dialog
Now in order for your map to continue after your intro is done, you'll have to use the Wait action. Simply create those dialogs and Wait 10 seconds