Is there a way to make bunkers and terran lifted buildings invisible in a given area without having to explore the area? Trying to set up a fire jungle scenario that players are going to be exploring.

Post has been edited 1 time(s), last time on May 27 2018, 8:01 pm by Nib-.

bunker invis: http://www.staredit.net/wiki/index.php?title=Bunker_Disabling_and_Stacking

as for flying invi buildings: not possble as far as im aware. maybe with eud editor? you can remove buildings detected t the air layer, though.

You can make units / buildings invisible by giving them a 0x0 placement size with EUDs. The units will still block pathing, can still attack (which will produce weapon graphics), but cannot themselves be targeted by units or selected by any player, maybe them effectively invincible. I'm unsure if AoE spells will affect them or not. Unsure if they give vision or not since my testing was in a full-vision area.

Setting placement size in this way will affect all units of that type in the map. You can change this value at any time and it will instantly update all units - so you can make everything invisible or visible at will.

Saw this one. Is there anyway to have preset bunkers invisible? Trying to simulate a fire in the jungle with bunkers on fire/invisible. Would the only way be disabling and then moving the bunker to a location to make them invisible?


I'm not familiar enough with EUD's. Is this fairly easy to implement in terms of triggers or would there be a lot of work?

What are you trying to do, place fire sprites in a playing area, and you were going to achieve this by having terran buildings with flames air-lifted? If so, then my suggestion of changing the placement size to 0x0 will not work for this effect, because it makes the building and everything associated with it (flames) invisible.

You can place flames directly with EUDs if that's what you're trying to do, and it's very easy. There are two methods, one where once created the fire is permanent (I use this in Desert Strike Night 3.20 for building gas), and another where the fire can be removed (or moved) via trigger later, which is slightly more work to set up. If this is what you're trying to achieve let me know and I can write up instructions later tonight.

Post has been edited 2 time(s), last time on May 27 2018, 11:05 pm by Lanthanide.

Well the thought process was just the easiest way of having a firey effect. Assumed it would be bunkers and lifted air buildings. Yes! placing flames would be great! would the map still be editable with scmdraft afterwords?

Yes, it can be editable in scmdraft after doing these changes, although that requires a little more work.

There are two possible methods: one where the fire is just a sprite and can be placed anywhere on screen, but not removed afterwards, and the other method edits the Nuclear Missile unit to look like a fire effect, so it can be removed later, but takes up a unit slot in-game (so problematic if you have CCMU issue in your map).

Either approach needs you to be able to specify exactly where you want the fire via locations, which can either be static or you can move them around by centering the location on units, or using EUDs for locations you can position them directly.

I will endeavour to post a tutorial later tonight (within the next 4 hours), if you can answer my question above as to what method you want.

Burning bunkers is the way used in classic mapping techniques and produces a decent effect. Why do you want flying flames? So they're above trees? Then EUDs are the way to go. Just keep in mind that this requires an up-to date starcraft (v1.21+) and won't work with versions before the remaster. ... unless you build a 2nd version of your map that also requires EUD enabler.

Anyhow, I'm still gonna answer your question:
I'm not sure, but I think if you just preplaced them disabled they'll show normal graphics, but are unclickable, unless detected.

I think moving the bunker is only necessary if you also want to stack them or if you want to actually remove them, so they can't be seen with detectors either. Not sure if removing would even preserve the flames. So in your case, not necessary.

Post has been edited 1 time(s), last time on May 29 2018, 5:01 pm by NudeRaider.

Get EUD Editor and EUD Editor Translation from the first post in this thread: http://www.staredit.net/topic/17529/

This is EUD Editor V1, which supports "view triggers", allowing you to put EUD triggers into scmdraft directly, so you can edit the map afterwards (unlike EUD Editor v2, which does not yet support this functionality, but is otherwise more powerful and easier to use).

Now the theory behind all of this is that we are going to create Scanner Sweep units. Scanner sweep is a slightly weird spell, in that the way that it works is that casting scanner sweep actually creates an invisible unit on the playing field, which persists for a short period of time, providing vision and detection for the casting player, and crucially during this period of time it creates a sequence of Scanner Sweep Hit graphical effects on the field in a circular pattern - the familiar blue sparkles from scanner sweep. The scanner sweep unit is then removed and the player eventually loses vision of the casting spot.

The thing that creates the blue sparkle graphics is the iscript tied to the scanner sweep unit; so you could actually give this iscript to other units with some EUD editing if you wanted, but for our purposes it's easiest just to manipulate the scanner sweep unit itself, particularly as it won't be being used by any other triggers in-game since normally they won't do anything if EUD editing is not used.

How to do it:
1. In EUD Editor, on the DatEdit + Unit + Default tab (default, initial selection), got to unit id 033, Scanner Sweep.
2. Click on the Staredit sub-tab
3. Check the box for "List units & palette". This is the only staredit flag that is of any use/interest at all - clicking this will allow us to create Scanner Sweep unit via the Create Unit trigger action. None of the other flags do anything useful in-game; they control how Staredit works (which by default reads the unit.dat file to populate it's menus etc).
4. Now click on the DatEdit + Images tab.
5. Go to entry 474, which is Flames1 Type3 (Large). This step is just to identify what flame image you want to create. There are other flames you can try, and things like zerg building blood and spell effects like stasis, feedback, irradiate, generic explosions or weapon effects etc. Unfortunately you can't get access to unit death animations (the critter deaths would be nice to access) because those graphics are buried deep inside the unit graphic files, and we don't have the ability to edit iscript via EUDs at present, so we can't access them.
6. Now click on the DatEdit + Sprite tab.
7. Go to entry 380, Scanner Sweep Hit
8. In the properties of this tab, there is a box called Images with the value 546 in it. Replace this value with 474.
9. Now click the Inject EUD menu and select View Triggers.
10. In the new window that pops up, click "Use SetTo" in the bottom left.

Now you have the triggers you need to copy into scmdraft to set up the fire graphics for scanner sweep. Note that if any player uses scanner sweep in the game when these EUDs are set (if you don't set the sprite back to its default value of 546) will get a ring of permanent flames.

If you have the latest version of scmdraft, in classic trigedit you can create an action for EUD Modify Memory. Click on the blue Address field, and that's where the initial hex value (0x661558) goes, and then click on Quantity and put in "131535", click on Set and change it to Set To. Do the same for the 2nd action.

Now to actually place your flame graphic on the field, use a normal Create Unit action to create a Scanner Sweep unit. If you just create it and do no other trigger actions, you'll get a ring of 9 flames that will permanently display on your map, which will nifty is pretty silly looking. The very nice trick here is that the first graphic created by the scanner sweep iscript is the one that is precisely on top of where the scanner sweep unit was created, and if you use a Remove Unit At Location action in the next trigger cycle, you can remove the scanner sweep after it has created only a single flame in exactly the spot you want. What is even niftier still, is that you can create multiple scanner sweep units in the same trigger, changing the graphics each time (steps 7-8 above) and placing more on the map. Then in the next trigger cycle, you can remove all of them at once with a simple "Remove Unit" action, and you'll get multiple different fire graphics (or whatever graphic you chose) in a single trigger cycle; so you don't have to take multiple cycles to set up multiple different grpahical effects on the field. If you reset the scanner sweep sprite back to its default value (546) at the end of the trigger that creates all the scanner sweeps, then players will be free to use scanner sweep normally without any impact on their gameplay whatsoever (triggers always run after all player actions at the end of a frame, so if you reset the sprite value back to normal, no players can ever be impacted).

One nice tidy way to do all of this is to have a Wait (1) action in your trigger after you've created all of the scanner sweeps, and then put the Remove Unit action after the wait, that way you don't need to use a 2nd trigger with a DC timer or any other malarky. If you have classic hyper triggers in your map then using a wait like this could cause wait blocks, but that can be entirely avoided if you use the below trigger to provide EUD hyper triggers, which works the same as classic hyper triggers (~11.90 trigger cycles per second) but avoids all wait blocking problems entirely:
- Always
-> Modify memory at at Death Table +203151 Set To 1
-> Preserve Trigger

If you set it to 0 and preserve it, then you get 'super' hyper triggers, where triggers will execute ~23.80 times per second (so any classic hyper trigger DC timers will run at double speed). Note that this might create extra lag in your map.

Note: using EUDs will make your map play with classic 1.16.1 unit limits, rather than the expanded limits otherwise available in SCR.

Good luck!

Post has been edited 4 time(s), last time on May 28 2018, 9:36 pm by Lanthanide.

Easier way: If you only need preset bunkers to be invisible and on fire, you can do it all at the start of the game and turn off each player's vision of themselves, and then turn vision back on afterwards. So basically at the start of the game, you'd turn off vision, disable the bunkers, create observers on them, remove observers, turn vision back on, and the bunkers would be invisible without having the fog of war revealed for any player.

Also, for burning lifted buildings, you do not need EUDs. You can do this the same way as bunkers by just disabling them and giving detector vision for the player and then taking it away. Inferno and I did this in a map where we have a nightclub, and we made invisible buildings above the area to make it darker. The buildings aren't usually on fire, but I just added it in to show that it's possible.



Not sure exactly why some of the buildings don't go invisible; it's probably some minor bug. It usually works flawlessly.

Thanks everyone for the help. Will most likely implement a combination of the two. Might stick with the non-EUD method for now and switch it as the map is being completed.


also Lanthanide! Thanks for the EUD guide. Will definitely use this for something else. Off-related topic would the process be relatively similar for adding shields to terran/zerg units and increasing it through upgrades?

You can do the shields for units thing via EUD editor, just edit the right fields on the units you want and use 'view triggers' in that menu.

Changing unit upgrades can't be done using the EUD Editor, you have to work out the addresses and offsets yourself manually. Also if you mean have upgrades that give a unit more shields, that's not possible as a normal upgrade itself (upgrades can only increase armor, weapon damage or protoss shield armor), but you could simulate it by using an unused upgrade, and when the player researches it, detect what level they have researched and then increase the shield value on the unit type commensurately. Unfortunately it will increase the available shields for all that same unit type in the entire game, for all players - that's fine if the player has access to units that no other players in the game have, but otherwise it's not a great solution.

With EUDs you can effectively 'clone' units however, eg you could overhaul the underlying Protoss Zealot unit to look and behave exactly like a Zergling (except unit upgrades such as movement speed, attack speed, energy etc are hard-coded to unit IDs), and when the player researches the upgrade, change the shield value on the Zealot unit - that will affect only the players 'Zerglings' but not any other true zerglings in the game. All of the cloning can be achieved using the 'view triggers' technique above, EXCEPT for changing the wireframe of the unit - for that you MUST inject the map using EUD Editor, and after you've done that the map can't be edited with scmdraft - so the normal workflow is to do that as your last step, and save the output map with a different name. If you're going to make use of the EUD Editor inject functionality, then you're strongly advised to use EUD Editor 2, as it's generally easier to use (especially the unit command card part in Firegraft) and it also has an auto-inject functionality that makes injecting the map much less hassle.

Post has been edited 4 time(s), last time on May 29 2018, 9:34 pm by Lanthanide.

So, I can replace my walls of wait 0 ms with that single trigger and have hyper triggers and be able to use waits freely? That sounds awesome, I'm going to try it out

Yes. Bear in mind that this will take you back to 1.16.1 unit limits though.

Post has been edited 1 time(s), last time on Jun 5 2018, 1:47 am by Lanthanide.

Huh? Is that a general rule? Whenever I use one of the supported EUDs SCR rolls back the the unit limits? Or is it because it's a not-supported EUD, which SCR detects and switches modes to ensure compatibility?

Maps with unsupported EUDs don't start; you get an error on load saying unsupported EUD and to report it on b.net.

Any map with an EUD in it that SCR detects will cause the limits to roll back to 1.16.1.

I'm not sure if that includes purely read-only (condition) EUDs, or only EUD actions, but I expect that the EUD detector won't discriminate between them.

Post has been edited 2 time(s), last time on Jun 5 2018, 9:06 pm by Lanthanide.

Ah that's actually unfortunate. Planning on going past the limits lol.

It might be an issue with removing the detector too fast. A detector can only detect a new cloaked unit once every frame IIRC.

I already dealt with that heartbreak as I was attached to using EUDs in my map from the get-go

Why do you need detectors? Just share vision with the bunkers on frame 0 and remove the vision on frame 100?