SC2Mapster

Quote from SouLCarveRR: Go

If your nesting 6 loops deep your doing something wrong IMO

also when doing heaving looping put a wait in for .01 this helps keep you from overloading the trigger system in SC2

I really dont understand what you could possibly need to nest 6 loops deep. sounds like terrible logic to me.

The actual problem you ran into that you stated at the top of this post is due too to much code in a single trigger. I had this problem myself. So I took a good chunk of my code and moved it to an extrenal function that this trigger would call. That solved the -Code jump out of bounds (Try reducing the size of very large functions)"

Yes, of course you're doing something wrong if you have 6 nested For loops. =) That was just an example of how to break it with a single trigger.

As a note, however, it is not due to one large trigger. When I encountered the error, I reduced the size of the function that caused the error and started working in different triggers to see if the issue would still occur (ones without any nested loops at all), and adding more than a few lines of code caused the error to crop up again.

EDIT: Adovid, in regards to your last post, compare the code from While and For loops. You seem to be implying that the way their For loops is setup is intentional and is more efficient than any other way it would be setup. That is false.

Compare the code from While and For loops. They both use While loops in their code. The only difference is For loops include several hundred If statements as well and a ridiculous amount of duplicated code. While loops are more efficient. This isn't some weird veiled attempt on Blizzard's part to make For loops run more efficiently.

Quote from Molsterr: Go

as I said there, "interesting" . And ive already submitted it to the news thread ^_~

Though... im a for loop user.. I dislike the while for w/e reason... Has anyone else -confirmed- this? just seems so random.

Yeah, I love for loops too... so much, in fact, that I coded my own custom for loop action so I could have the same functionality without all the code mess and/or hassle of setting up whiles properly. =P

I just posted in the Blizzard thread as to how you can verify it yourself Molsterr, shouldn't take more than 5-10 min to test. Go ahead and give it a whirl.

This is just a link to my thread in the Blizzard forums, but I think it's incredibly important all mapmakers read it.

http://us.battle.net/sc2/en/forum/topic/628237153

Quote:

Hey guys,

I've included a TLDR and examples at the bottom if you want the short version, otherwise...

Just giving you a quick warning. Was working on some semi-complex triggers in a map tonight and I hit save. Guess what error I get?

"Code jump out of bounds (Try reducing the size of very large functions)"

Great. Just what I needed. First, it appears the limit on the size of code seems arbitrarily small (I didn't have any extremely large functions), and that means I can't finish any of my triggers, meaning the last 100 hours I've put into this map were wasted.

So, I scan through the generated code to figure out what's taking up so much space, and lo and behold, it's two specific triggers. Both have nested "For" statements. One of them has relatively uncomplex actions within the for loop, but has 4 nested loops. I start comparing code sizes. The entire set of generated code is about 240,000 characters.

The function with 4 nested loops is taking up a whopping 100,000 (!) characters of that, and the other nested function is taking up another 80,000. WTF!

I took a closer look, and it appears Blizzard's implementation of nested For loops is extremely messy. So, I decided to try something, and changed one of the 4 nested For loops to a While loop (the outermost loop) with exactly the same functionality, so instead of 4 For loops, it's 3 For loops and 1 While loop. The generated size of the function dropped from 100,000 characters to 40,000 immediately. I replaced the rest and have not had a problem since.

TLDR: Nested For loops are VERY inefficient and generate ridiculously large blocks of code, which will take up a large part of your space allocated for triggers. USE WHILE LOOPS INSTEAD OF FOR LOOPS if you will be nesting them and avoid the hour of frustration I just endured.

P.S., Blizzard, it would be extremely grand if you could clean the nested For code generation up for us! =D

Okay, here's the example. Both functions are completely identical, one using nested While loops, the other using nested For loops.

CODE GENERATED FROM WHILE LOOPS: http://pastebin.com/7C0fY9zy

CODE GENERATED FROM FOR LOOPS: http://pastebin.com/2ueAmHug

For reference, this was the trigger version of the For loops (in text form): http://pastebin.com/HffSa1Zf

That should be a very simple block of code generated.

If that doesn't make you stay away from For loops, I don't know what will.

Quote from edcbabe: Go

You can issue units to attack all enemy units near a point - they will attack all enemy units along the way too.

Check my map if you need the exact code.

Cheers :8)

For me in particular, I don't want the unit attacking anything on the path, that's where the issue comes up. I got it working at one point the way you had it, but it wasn't what I was looking for. Thanks though.

@siege911: Go

        Player Group - For each player Player Loop in (Losing Players) do (Actions)
            Actions
                Game - End game in Defeat for player Player Loop (Show dialogs, Show score screen)

That should end the game in defeat for every player in group Losing Players.

Quote from s3rius: Go

@coronbale: Go

If player 1 saves his gold in P1, then starts playing another game and becomes player 2, then his bank will be loaded as P2. So there's no problem. Is it that what you mean?

Actually I believe coronbale is correct in this case.

Right now he is storing Player 1's data in a bank named "P1", player 2's in a bank named "P2", etc.

This means that if, for instance, next game the person that was Player 1 switches to Player 2, it will now attempt to load bank P2 for him, which *does not exist* (his data was saved in P1), and his save data will not be loaded.

He should be using the same bank name for all players, no matter what player # they are.

@JohnnySmash: Go

If it makes you feel any better, here's the thread that resulted from my attempt at exactly the same thing:

http://forums.sc2mapster.com/development/map-development/7375-issues-duplicating-move-attack-abilities/?unread

So far unresolved. I've given up until someone finds a solution to my issue, using a slightly different setup instead until then.

EDIT: As a note, the best way to do it that I could find was leaving it as an Augment ability and setting the "Ability Command" to Move instead of Attack, and changing the ability "Target Type" to "Unit or Point".

That'll get you pretty close, but beyond that you're on your own.

Hey guys,

Figured I'd make a post as it took me quite a while to figure this issue out in my mod.

Mods can load, read/write and save to banks just fine, however, the "Preload" action for banks does NOT work from within a mod. The map including your mod as a dependancy has to call Preload on your banks for you, or it will not open the bank properly.

Hope this saves someone a headache somewhere down the line.

Actually, that sounds exactly like a validator issue. If a validator (in the Behavior - Validator (Removal) section of the behavior) is returning false immediately, it will stop the behavior right away.

Can you do what YiffMaster requested and post a test map with your ability/behaviors added?

@FraindorX: Go

To create an FPS where you control with the mouse, you need to turn ON the following two trigger settings:

Camera -> Turn Camera Mouse Rotation On/Off

Camera -> Lock Camera Mouse Relative Mode On/Off

Enabling both of these will allow you to "look around" by moving the mouse. You can then use "Camera -> Camera Pitch of Player" and "Camera -> Camera Yaw of Player" to determine where they are looking.

You'll also need to modify the camera position to follow whatever unit you want to follow.

@Roflincopter: Go

Double check that the behavior for Charge has it's duration set high enough. If you increase the max charge distance enough it may hit the duration max before the Zealot finishes it's charge, which would end the charge early, validators or not.

@DirtyDevious: Go

I have a feeling (untested) that behavior is lost on death... As an alternative, you could create a global "Flag Carrier" variable (Type: Unit), storing the unit that is currently carrying the flag, and then change that condition to "Triggering Unit == Flag Carrier".

@TheFallenOne222: Go

Quick little bump... No progress as of yet on this at my end. May tinker with it some more tomorrow though if I don't get a solution. Anyone??

@DoubleElite: Go

Make sure when you select "Unit -> Issue Order", you set Order to "Order Targeting Point". After doing that, the "Move" ability should be available in the "Ability Command" setting. =)

@BacklitAvenger: Go

Alright, I'll play around with it on my end a bit later tonight, see if I can get you a more definitive answer.