Staredit Network

Staredit Network -> StarCraft Editing Related -> bug in Xtra
Report, edit, etc...Posted by axblader on 2005-03-29 at 17:12:15
weird. today i was making a map and look at this:
[attachmentid=7034]

it is usually white. i opened another map of mines and found out that indeed it was white. how did this happen? i dont see a player color editor in Xtra?

Report, edit, etc...Posted by Tazzy on 2005-03-29 at 17:24:02
If i am right, On Ice maps, Its changes player 7 White to Green. Since after all you cant have a white player one a snow map Does it on normal staredit aswell. So you did not really find a bug.
Report, edit, etc...Posted by axblader on 2005-03-29 at 17:35:31
oh...darn. ok then.
Report, edit, etc...Posted by Sipher on 2005-03-29 at 21:18:22
Lol..Yeah, Blizzard decided to make player 7 green so it wouldnt blend into the "Ice World" with the White color. I believe it does it on Desert too.
Report, edit, etc...Posted by Heimdal on 2005-03-29 at 23:13:16
Yes, it changes Orange to Green on desert.

I'm speculating that it's mostly for the minimap colors, not the actual units on the screen.
Report, edit, etc...Posted by Sipher on 2005-03-29 at 23:34:08
./slap w/e fo0 tongue.gif...Lol, aye.
Report, edit, etc...Posted by Carlsagan43 on 2005-03-31 at 19:28:36
I copyed this from campcreations but there are 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.

Report, edit, etc...Posted by SA_Max71 on 2005-04-01 at 10:34:57
QUOTE
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

I have known about this "bug" for a while. However, when I first saw it in a map, I was allied with the player, and the player was allied with me. But then, we were in the same force and everyone in the force were allies with each other without the use of triggers.
Report, edit, etc...Posted by Clokr_ on 2005-04-02 at 13:39:23
QUOTE(Heimdal @ Mar 30 2005, 05:13 AM)
Yes, it changes Orange to Green on desert.

I'm speculating that it's mostly for the minimap colors, not the actual units on the screen.
[right][snapback]175918[/snapback][/right]


It changes brown to green on desert.
Report, edit, etc...Posted by Deathknight on 2005-04-04 at 22:54:05
Can you people label it as a "Staredit" bug? Because SCXE is a modification...
Report, edit, etc...Posted by Heimdal on 2005-04-05 at 17:58:48
Here's a little mistake...nothing that affects operation though.

[attachmentid=7396]

Comment is an action, not condition.
Next Page (1)