Staredit Network

How do you remove one building and put another in it's place, I need to have this in separate triggers in my map but I keep getting unplaceable messages. I was surprised to not find a tutorial on this.

Thanks

why do you need seperate triggers? are you using deathcounts?

when it says it unplacable, it means its unplacable, as in something is in its way(or maybe your location isn't tile-locked?(can that be a problem?)). for units, this can be fixed by creating them somewhere else and then moving them to their final location, but for buidlings you're stuck i think.

Try removing the building at the spot first, if that still doesn't work, try adding a very small wait in the trigger.

Do you mean you want a building to be STACKED on another building? If so, its actually quite simple.

First: Place 2 buildings. Building X (the one you wish to move) and Building Y (the one you are going to move Building X to). Stack Building Y as many times as you'll need in the same spot. Create a trigger that removes one of the stacked Building Y's from the stacked pile. Continue the trigger so that Building X is moved to the Building Y location. Because one of the buildings was removed, StarCraft registers it as an empty space and allows you to move a building there.

The size of the location that you're using to replace buildings has to be the same size as the building that you're going to replace it with.

Even if a building was there previously, if it was on unbuildable terrain, you cannot replace it.

Besides that, it's just remove unit, create unit. If these are all part of a far more complex system, you can split it up into separate triggers if you need to, just make sure the conditions for create unit trigger has the fact that there are no buildings in the location where the building is going to be created.

nothing else that anyone's mentioned is wrong; do you know how long the wait would have to be?

I added the wait before the create, but for some reason the create triggers won't work at all! I tried disabling the wait, and I got the unplaceables again. With the wait activated nothing happens at all.

And the remove is before the create.

May we see the map?

That is caused by wait blocks. You cannot run more than one wait at a time for any player. Trying to do so causes the second wait to wait for the first one.
Since you are using hyper triggers, the 100ms waits at the bottom of the trigger list end up waiting a loooong time.

The unplaceable errors seem to stem from the locations being centered on the wrong units. For example, it removed my supply depot and then tried (and failed) to create a hydralisk den at one of my SCVs, instead of where the supply depot was.
With the map having over 100 un-commented triggers, it wasn't within the power of my attention span to locate the defective trigger(s). =(

I think that switching out units and buildings randomly is a bad idea. Even if you find out what's wrong with your current system, there will be other problems; unfixable problems.
Plus, even if you somehow manage to get it working properly, the balance of the game will be hopelessly distorted.

I'm sorry about that; I did it in staredit, quickly.



As I told you; the map is not near completion; I have only completed less then half the triggers and came across a problem. Not wanting to go over and fix it for each trigger one by one; I wanted to figure out the mistakes early, so I made a "choreographed" version of the map, with the randomizers disabled and only one possibility per building size.



I'm sorry to ask, this might point out my lack of experience, but; how does the fact that I'm using hyper triggers affect my wait times? I believe that there are switches causing the trigger to only fire once.

Thanks for the help

actually, from what i know, hypers don't cause wait blocks. the fact that you have waits do. like kenoli said, you're experienceing wait blocks because you can only have one wait running at a time.

think of it like this(assume condition is always):

you want a marine to die exactly 1 millisecond after it is created

wait 1000ms
create 1 rine

****

wait 1001 ms
kill all rines


with that trigger you may expext the rine to die 1001 ms after the start of the game, but in reality, it will die at 2001ms into the game because the 1001ms didn't start 'ticking' until the first 1000 ms wait was done.

note:yes, i know this is a stupid example, but it works.

Hyper triggers ARE waits, and they are the most common cause of wait blocks.

how is that applicable though? or does he have non-hyper waits for the same player as the hypers?

i always thought hyper caused wait block because they ran through triggers so much faster, reducing the time between triggers with waits.

that'd be the hyperless triggers running(2s represent the normal trigger 'lag'):

WAIT - 2s - TRIGGER - 2s - TRIGGER - 2s - TRIGGER - 2s - WAIT

total of 8s between waits. this would help reduce the wait blocks by 8s

with hypers:

WAIT - TRIGGER - TRIGGER - TRIGGER - WAIT

for the grand total of no time whatsoever between the waits.


if i'm wrong, which i guess i am, mind explaining. i really don't get that tutorial.

Ok. To cut down on confusion, seeing as how staredit is the only easy way to view my triggers, here are some of my triggers:

Trigger

Description:

Remove trig

Players:

¤ all players

Conditions:

¤ 'remove' is set

¤ '1r' is cleared

¤ '2r' is cleared

¤ '4r' is cleared

¤ '8r' is cleared

¤ '16r' is cleared

¤ '32r' is cleared

¤ 'building' is set

¤ current player commands at least one 'Protoss Nexus'

Actions:

¤ center location labeled '4x3' on Protoss Nexus owned by current player at 'anywhere'

¤ remove 1 Protoss Nexus for current player at '4x3'

¤ clear 'remove'

¤ set '4x3'

¤ display for current player "Before: Nexus"

¤ Preserve trigger

Trigger

Description:

create trig

Players:

¤ all players

Conditions:

¤ '4x3' is set

¤ '1c' is cleared

¤ '2c' is cleared

¤ '4c' is cleared

¤ '8c' is set

Actions:

¤ remove all any unit for current player at '4x3'

¤ wait for 100 milliseconds

¤ create 1 zerg hatchery for current player at '4x3'

¤ display for current player "After: Hatchery"

¤ show minimap ping for current player at '4x3'

¤ Clear '4x3'

¤ Preserve trigger

I have hyper triggers, as well as a trigger to randomize each numbered switch, as well as the 'building' switch. This is an example of two of the many many triggers, however; the majority look almost exactly like them. And it has occurred to me that I should've individualized the triggers, but I wasn't really in the mood when I started to make triggers for every player.

so, thats one player's waits(hyper triggers or any other wait block) affect every other player's triggers?

Uh, no.

No, it will not.
As you may know, each player can run one wait at a time. If a wait tries to execute while another one is waiting, it must wait for it to finish. The first wait 'blocks' the second.

If you make a trigger for Player 1 that is nothing but a wait 100000ms and copy it a hundred times, it will cause a gigantic wait block for player1, but all the other player's waits will be completely unaffected.
Wait blocks are player specific. That is, one player's waits do not block another player's waits.
Wait blocks are in no way related to why hyper triggers work.

i think i get it now. so, when you said that 100 ms after the hypers created a wait block, you were just referring to that single trigger? cause i think i misunderstood and thought you were talking about the whole map.

DTBK, this is exactly why i think a tutorial about waits and hypers should be pinned in the forum. of course, it should be probly less conceptual and more practical, with 'troubleshooting.' with something like that around, posters could link to it for debates, providing undisputable evidence.

Well it depends on what you consider "related" i guess, but the reason hyper triggers work is due to the fact that every Wait(0); command forces the game to check every other trigger (thus skipping the standard 2 second pause a trigger takes to run itself)...

The reason they last is because as each Wait(0); goes through it runs into the other wait blocks each of which have another 64 Wait(0);, and when each of those runs, it checks the next Wait block, which has another 64... this compounded makes the number of effective waits go up exponentially...

As for how "other" waits tie into this to screw up, if you randomly have a wait, it gets stuck into the web of waits the hyper triggers cause, and depending on where the hyper triggers are currently, I'd imagine results may vary...

That's what I get from it anyway...

Anyway, according to that, interefering waits that end up compounding each other would be precisely why hyper triggers work

The potential for wait blocks occuring is just a side effect of using hyper triggers. You don't need wait blocks for hyper triggers to work.
You could have one trigger with one Wait0 in it as your hyper trigger and it would work, though the NEO would be very frequent.