It's actually quite remarkable how bug-free Staredit actually is for such a complex editing tool. During its entire history (from 1.00 to 1.05), there were only two or three noticable "errors" (the major ones probably being the "save cancels 'set next scenario'" and "settings dialog value resetting error") -- but also dozens of upgrades and additions. Other than that, everything it does is completely logical. Nevertheless, no one is perfect, and there are a few "bugs" in Staredit 1.05 that might be worth knowing about. If you know that they exist though, you might just be able to use them to your advatage -- thus making them "quirks" instead of bugs. =) This article will be on going, as I discover or receive and confrim reports of more "bugs."
Non-rescuable Rescuable Units
I found this one a while ago during my development of New Avalon II, though I'm sure I was not the first (since it is pretty simply accomplished). Here are the requirements:
Player X is rescuable.
There is a Unit Y owned by Player X on the map somewhere (either preplaced or created -- it doesn't matter)
You use the trigger action "Move Units" to move Unit Y. It doesn't matter where you move it, just that you use the move trigger action on it.
Now, try to rescue Unit Y. Surprise! It is no longer rescuable. For some odd reason, moving a rescuable unit will disallow any player from ever rescuing it ("bug"). However, this can be useful in some instances -- for example, now you can have rescuable and non-rescuable units of the same color.
Another little oddity you might want to know about is that if you rescue a transport or a bunker that has rescuable units inside, you will not get control of those units inside. If you exit those units, they will become much like those described above: non-rescuable units of a rescuable color. =)
Units for Non-existent Owners
This "bug" is just as simple to pull off:
Player X is human. Player X is not present. (i.e., that human slot was never filled when the game began)
Player Z is another player. Doesn't matter who is the owner so long as this player is present.
There is a Unit Y owned by Player Z on the map (either preplaced or created -- it doesn't matter).
Use the trigger action "Give Units to Player" to give Unit Y to Player X.
You'd expect Starcraft just to ignore that action since there is no Player X in this game right? Well, it's actually kind of funny. Unit Y will be given to a Player X -- same color and slot as if that player where actually present. However, this "virtual" Player X will automatically be designated as an enemy to all players and will be an enemy of all players (i.e., everything will attack it and it will attack everything). Also, there is not much you can do trigger-wise to effect this unit because its owner (Player X) is not technically present, and thus Starcraft will ignore all triggers and trigger actions involving it. Wierd, huh? =) Well, I'm not sure what utility you can get out of this one, but it's nice to know about.
I actually discovered a little later that this trick is even easier to pull off. All you have to do is "create unit" for a non-existent player and the unit will be created as it is above: hostile to everyone. Be sure to make the actual trigger for an existing player though, otherwise it won't run. =)
The String Limit
One thing you never want to do is go over the "string limit." This is when you have more than 1024 lines of custom text (a line of custom text is like the map name, unit names, each display text action, location names, etc.). If you go over it, sometimes Staredit will give you a simple error message telling you that you can't input anymore lines of text until you delete some old ones, but more often, it will just start behaving badly:
If you import a sound after you're over the string limit, it will not show up in the sounds list (list of wavs). It will be in the map. It just won't show up. =) This is because each wav name takes up a string, and if you're over the limit, it can;t write in the wav name. The reason this sucks is because you can't use the wav in a trigger, but it will still take up space in your map. =P
You will not be able to make any more locations. It won't give you an error, it just won't work.
Sometimes, it will mysteriously start deleting text you just wrote without even telling you. This especially happens with things like unit names and switch names.
And, in the worst of worst case scenarios, your map will become corrupt and you'll have to start over. Its happened more than once. Just be careful.
Miscellaneous Bugs
If you make a UMS map on installation terrain and you make a player's race "user selectable" they will start out with their default town hall and 4 peons (and an overlord if zerg). Not really a bug, but some people have pointed that out so I'm posting it.
Quit Stealing Material. You’re probably only posting this for minerals, i'll have you fined for that. If you post any other tutorials that you didn't write then a warn level will pursue.
Now I doubt you actually wrote the Anti Hacking Tutorial but i don't want to try to prove you didn't.
QUOTE((U)Bolt_Head @ Dec 22 2004, 05:45 AM)
Di wrote that tutorial, so he must have.
[right][snapback]113461[/snapback][/right]
Nice one, but why didn't you posted the link where his post of this Tutorial is at then?
QUOTE
Units for Non-existent Owners
This "bug" is just as simple to pull off:
Player X is human. Player X is not present. (i.e., that human slot was never filled when the game began)
Player Z is another player. Doesn't matter who is the owner so long as this player is present.
There is a Unit Y owned by Player Z on the map (either preplaced or created -- it doesn't matter).
Use the trigger action "Give Units to Player" to give Unit Y to Player X.
You'd expect Starcraft just to ignore that action since there is no Player X in this game right? Well, it's actually kind of funny. Unit Y will be given to a Player X -- same color and slot as if that player where actually present. However, this "virtual" Player X will automatically be designated as an enemy to all players and will be an enemy of all players (i.e., everything will attack it and it will attack everything). Also, there is not much you can do trigger-wise to effect this unit because its owner (Player X) is not technically present, and thus Starcraft will ignore all triggers and trigger actions involving it. Wierd, huh? =) Well, I'm not sure what utility you can get out of this one, but it's nice to know about.
I actually discovered a little later that this trick is even easier to pull off. All you have to do is "create unit" for a non-existent player and the unit will be created as it is above: hostile to everyone. Be sure to make the actual trigger for an existing player though, otherwise it won't run. =)
The String Limit
One thing you never want to do is go over the "string limit." This is when you have more than 1024 lines of custom text (a line of custom text is like the map name, unit names, each display text action, location names, etc.). If you go over it, sometimes Staredit will give you a simple error message telling you that you can't input anymore lines of text until you delete some old ones, but more often, it will just start behaving badly:
If you import a sound after you're over the string limit, it will not show up in the sounds list (list of wavs). It will be in the map. It just won't show up. =) This is because each wav name takes up a string, and if you're over the limit, it can;t write in the wav name. The reason this sucks is because you can't use the wav in a trigger, but it will still take up space in your map. =P
You will not be able to make any more locations. It won't give you an error, it just won't work.
Sometimes, it will mysteriously start deleting text you just wrote without even telling you. This especially happens with things like unit names and switch names.
And, in the worst of worst case scenarios, your map will become corrupt and you'll have to start over. Its happened more than once. Just be careful.
besides, the part about units owned by player that arent here is already widley know, besides you don't need the "give units" trigger, you can just create unit for that player. And the string limit: well no DUH.
Wow, that sux, -100 minerals.
So what was he doing?
Just copying and pasting somethng from a tutorial. Cause if he did, thats pretty lame.