Which is faster?

[InfinateAnswers]

Is it faster to end a chain of if/then/else at the then action like so:

• If (All Conditions are True) then do (Then Actions) else do (Else Actions)
  • If - Conditions
    • Random_Integer Less than or equal to 22
  • Then - Actions
    • Hero - Create Winning Lottery Ticket and give it to (Picked unit)
    • Custom script: call DestroyGroup(udg_StartingUnit_Group)
    • Skip remaining actions
  • Else - Actions

or going through every if/then/else and destroying the group at the end? Every if then else would have to contain the script.

 

[Vinz]

What are you trying to do? The first option seems to be better since it in itself is a skip remaining actions.

 

[InfinateAnswers]

its a copy of that if then else multiple times with different integer conditions that spawn different items. I just want to know which way is more efficient.

 

[Vinz]

The first option. You do not need to skip as well, as Else actions will be ignored.

 

[InfinateAnswers]

they aren't nested together.

 

[Vinz]

Oh. You could put lower higher percentages in Else.

 

[edo494]

depends on multiple factors. Depends on how the Virtual machine handles if-else blocks, it may or may not be faster to return from function(Skip Remaining Actions in GUI) then to let the VM jump out from the ifs.

The second thing is, if you have anything outside the if-else nesting, it will never be reached.

Otherwise, no dont use it, it only compilcates your code, cause you have to create duplicates of "DestroyGroup", and even if it was faster, it would be so small performance gain that noone ever would notice it. You wouldnt even gain 1 microsecond from it, and to get 60 fps you need to make the frame run in 16.6 milliseconds

 

[InfinateAnswers]

maybe i want that microsecond, you dont know >.> lol thanks. I figured it would be an inconceivable amount of time.

 

[Vinz]

Perhaps move the DestroyGroup to the very end of the trigger.

 

[InfinateAnswers]

Yeah that was my second option if you didnt get that from first post =p

 

[edo494]

follow this simple rule: Destroy any created object in scope of creation(if it doesnt need to persist).

Basically, if you created the Group outside of If-else block, you should destroy it outside. It prevents potential leaks as well as removing code duplication, which in turn makes your map smaller(Ah who am I kidding, its like 20 bytes per line ). If you created the group inside the if-else block, you should remove it in the same block(the same reasoning)

I have yet to come to a GUI script that really requires "Skip Remaining Actions"

 

[BPower]

@InfinateAnswers: Why are you so concerned about gaining a minimal amount of time? Do you experience fps drop/laggs/spikes in your project?

 

[InfinateAnswers]

No i was just curious. Y'know, learning new things and all. And yeah, i created the group outside so i originally planned to put the destroy outside aswell, but then i thought i dont want the game checking every single condition before reaching the destroy group. So i just wanted to see if skip remaining actions had any merit.

 

[edo494]

game wont evaluate other ifs if they are not either after your if, or they are after the parent if(etc, this can go on forever)

 

[InfinateAnswers]

nest vs no nest, if nest isn't necessary, but an option?

 

[Tal'Rarity]

Could you show more of what your trying to do? Maybe you could solve this with a loop check in order to cut down on function calls.

As long as there is no waits or delays and fast enough per player's units then unit group outside of the nested/not nested if's should work fine.
You don't want to create stuff for a empty unit-group after all.

 

[InfinateAnswers]

• Untitled Trigger 002
  • Events
    • Dialog - A dialog button is clicked for Select_Luck
  • Conditions
  • Actions
    • Set Random_Integer = (Random integer number between 1 and 100)
    • Set StartingUnit_Group = (Units owned by (Triggering player))
    • Unit Group - Pick every unit in StartingUnit_Group and do (Actions)
      • Loop - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • (Clicked dialog button) Equal to LuckiestButton
          • Then - Actions
            • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
              • If - Conditions
                • Random_Integer Less than or equal to 22
              • Then - Actions
                • Hero - Create Winning Lottery Ticket and give it to (Picked unit)
              • Else - Actions
          • Else - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • (Clicked dialog button) Equal to LuckyButton
          • Then - Actions
          • Else - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • (Clicked dialog button) Equal to NonBelieverButton
          • Then - Actions
          • Else - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • (Clicked dialog button) Equal to UnluckyButton
          • Then - Actions
          • Else - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • (Clicked dialog button) Equal to UnluckiestButton
          • Then - Actions
          • Else - Actions

Thats the wip

 

[Tal'Rarity]

Dialogs are for one player at a time right? Otherwise there will be problems because every click after the first player seems to return null. It is a buggy event. I even attempted to get past this bug with dialog arrays and a new dialog button array variable for each button and sadly It didn't work because it is the event itself.

Evidence: http://www.hiveworkshop.com/forums/submissions-414/system-dialog-button-254366/

I suggest to visually remake the dialog system yourself and exploit GetLocalPlayer or invisibility however looking to see what can be done about that wall.

Edit: From what I can see since it uses dialog, you can't really do much... Nested would be better if you combine it with skip remaining lines which would look better however in its current state without being nested it is fine as well as long as you add skip remaining things in each check.

 

[InfinateAnswers]

cant skip remaining i have to destroy the group =p and i think i do remember a bug with dialogs but i did fix it somehow... i cant recall.

 

[Tal'Rarity]

Here's a better idea, don't use groups. It's just one unit per player correct?

 

[InfinateAnswers]

Im just gana use the shop-dummy unit method. Jerk making fun of my dialogs

 

[Tal'Rarity]

That's a lot better and lies, I like dialogs too.

 

[Vinz]

Do it in this order:

If/Then/Elses
- When true, set <var> = item type

-> Group Pick
- Add Item Type to picked unit

That way the ITEs do not run inside the Group Pick, and you can use Skip.

 

[InfinateAnswers]

i been doing dummy shop for long time, better to use a unit than an item.

 

[Tal'Rarity]

Nope, items are better. Units cause un-cleanable leaks but they're small unless you spam 1000.

 

[edo494]

yet we spam units instead of recycling them with systems that apply buffs or do stuns

the leak is not really noticable unless you spam dozens of thousands of units