Staredit Network

Staredit Network -> UMS Assistance -> Into and after random battle dilema
Report, edit, etc...Posted by Orc on 2004-02-19 at 18:49:25
I used the

Conditions:
Always

Actions:
wait 0 miliseconds
preserve trigger
comment "no wait"

Trigger to make getting into battles randomize faster, but it's to fast now, you get out of a battle and you have like 3-7 seconds to move before getting into another battle...Does the no wait trigger run on how many times you multiply IT or how many wait 0 miliseconds there are...?But if I cannot make it less fast that way, how else can I?

I made my trigs like this...

Conditions:
Current player brings ay least one any unit to 'battle area one'

Actions:
Wait 2200 Miliseconds
Randomize 'area 1 switch 1'
Wait 2200 Miliseconds
Randomize 'area 1 switch 2'
Wait 2200 Miliseconds
Randomize 'area 1 switch 3'

That was for randomizing, but was going to slow even when I took off miliseconds...

and this is for getting into battles...

Conditions:
'Area 1 switch 1' is cleared
'Area 1 switch 2' is set
'Area 1 switch 3' is cleared
current player brings at least one any unit to 'battle area one'
player one brings at least one any unit to 'p 1 location'

Actions:
Move units from prison, give party unit to cpu, play wav, etc

But wehn it comes time to get out of the battle, what if another players party unit was in the same area as yours, and you were both in the battle, it would give both units to one player...If you want to know the trigs I used for OUT of battle lemme know tongue.gif I got wayyyyyyyyyyy to much free time for this
Report, edit, etc...Posted by Mini Moose 2707 on 2004-02-19 at 21:46:34
The 2200 MS Waits in the randomize trigger should be screwing up with 0 waits. The more zero wait triggers you have the longer it will take for you to see a standard two second wait (it happens eventually, depends on how many) If you want to increase time between battles increase the number of switches, or use some other form of wait for each randomize.

Conditions: Player suffers at least 1 death of someunit.
Actions: Subtract one death of someunit.
-Preserve trigger

Conditions: Player suffers exactly 0 deaths of someunit.
Actions: Randomize the switches.
-Set deaths for someunit to whatever number would provide a big enough wait.
Report, edit, etc...Posted by (U)Bolt_Head on 2004-02-20 at 12:56:36
It seems to me you have a wait delema, You need to make your hyper trigger owned by only one player. Then you can run waits properly when there owned by other players.

I don't see a reason to have waits between your switch randomizing.

Can you post the map. I can bet you money that if I have the map and a clear description of what is wrong and what you want i can fix it.
Report, edit, etc...Posted by Volka on 2004-02-20 at 13:13:17
QUOTE((U)Bolt_Head @ Feb 20 2004, 12:56 PM)
It seems to me you have a wait delema,  You need to make your hyper trigger owned by only one player.  Then you can run waits properly when there owned by other players.

Nope! Wait actions are universal. They apply to all players.
That's why waits commands screw up everything,and that wouldn't work.
I just try to avoid using them. Maybe you can figure out a way to do what you want without using wait actions within your triggers.
Report, edit, etc...Posted by (U)Bolt_Head on 2004-02-22 at 17:20:41
QUOTE(Volka @ Feb 20 2004, 01:13 PM)
Nope! Wait actions are universal. They apply to all players.
That's why waits commands screw up everything,and that wouldn't work.
I just try to avoid using them. Maybe you can figure out a way to do what you want without using wait actions within your triggers.

I know how waits work and what I said is correct.

And a tidbit of information, Waits only interfere with other waits owned by the same player, But the hyper effect you get from them effects all players.
Next Page (1)