SC2Mapster

@Mozared: Go

Pity. You'd think they'd have directional LoS blockers.

I see, you're suggesting the use of the blockers as I am currently doing, but then also creating revealers to allow vision for other areas.

Is there any way to make some units ignore the LoS blockers? That way I could also potentially place invisible units to go along with the unit that should have the vision.

Due to the limited 3 ramps maximum on the default cliffs, I foregoed them and instead decided to just use the terrain editor. However if I use the doodad pathing and sight blockers, they go both ways, and you should be able to look down a cliff. Revealers are unlikely to work due to the complicated multilevel cliffs near one another. Directional sight blockers would work fairly.

Better would be sight blockers that only block units up to a certain height. Do we have this?

@Mozared: Go

Unfortunately that leads to units walking inside of the ramp, so even though that idea is 'playable' it's nowhere near optimal.

I would like to edit the footprint of a ramp, the smallest only allows a thin strip of 2 tiles wide to be built, while the graphics support 4. I would like to change it so I can use 4. I've been unable to locate any ramp details in the data editor. Could someone point me the way?

@DivinoZarathos: Go

The Hellion just dies because it's too close to the nuke?

@JacobNielsen: Go

Aren't they in the actor footprint?

@joecab: Go

Maps that wait for a key force me to alt tab and make sure I am the last person to press the key, otherwise there can be a lot of pointless loading (for me). I realize this is a suboptimal strategy when everyone uses it, but staring at a loading screen for 5 minutes ain't cool either.

There's only a few map types where this wait for key thing is allowable and I'll wait for it also.

@Polantaris: Go

Because I also have to set many water states and create a bunch of doodads etc. etc. (initialize the weather engine, etc. etc.). (I have many things I need to do 'first' so to speak).

I decided to just disable the Game UI a while while loading to cover up all the loading that takes place.

@malu05: Go

I was just hoping that maps had a property like:

Starting Camera X, Starting Camera Y, that I could set.

I'll just do it with Pan Camera, but for my map it's suboptimal, since I can't put it at the begin.

@Vitkar: Go

My map is a custom map though, not a melee map. So it does not have the melee triggers.

And it's not really a solution you know, it's more of a bypass. What I was hoping to find out is whether there was a way to simply set the starting viewpoint to a certain location (eg. per text editor)

Apparantly it is impossible, unfortunately :( I may still opt to use pan camera, but there's already a lot of initializing happening (like I said), and some of it really has to go before panning. But guess that's what I'll have to use :(

@RileyStarcraft: Go

All players have starting locations assigned. Map still starts in bottom left corner.

And it's not nonsensical, there is a pan camera when the player enters the game, it's in the "playing"-action.

I guess as bypass I could make a loop for active players to have their camera panned, but this will just increase the initialization, and I rather just have them start looking at the middle. (Also, several environmental factors need to be initialized PRIOR to the panning. This takes enough time that players can see the bottom left corner. I wish them to not see it.)

I noticed that the game camera automatically starts in the bottom left corner of a map, is there any way to change this?

(Pan Camera is NOT an option, since my map already takes its merry time to initialize, and I want players to look at something else)

@Koronis: Go

Actually I just use this timer to play the thunder sound periodically.

What does Start Timer do to a paused timer? Does it resume it? What is a timer anyway? Is it some kind of integer that is kept into an array that the engine checks?

Are you suggesting I call start timer when my weather engine initializes and then use pause and unpause behaviour for it?

I was looking for a Stop Timer function, similar to Start Timer, and found none. The problem is as follows:

My weather engine spawns a one shot timer when it's set to storm. This timer basically does nothing except play a sound, and then spawn itself again as a one-shot timer with a random delay.

The engine however can be set to a different mode within this timer. Currently I added the condition that the weather engine's state must be storm for the timer to execute its actions.

What will happen though when the weather is set back to storm (and thus Start Timer is called again) when the previous timer hasn't run out again? Is this safe behaviour? Or will it spawn a new timer that overwrites the last one, causing unpredictable behaviour?

When the engine is set to storm: Timer - Start <Weather Engine> Timer as a One Shot timer that will expire in 0.0 Game Time seconds

The relevant code:

<Weather Engine> Timer
    Events
        Timer - <Weather Engine> Timer expires
    Local Variables
    Conditions
        <Weather Engine> Engine State == <Weather Engine> Storm (Engine State)
    Actions
        Sound - Play BlastedLandsLightningbolt01Stand-Bolt for (All players) (at 100.0% volume, skip the first 0.0 seconds)
        Timer - Start <Weather Engine> Timer as a One Shot timer that will expire in (Random real between 1.0 and 30.0) Game Time seconds