Quote from O)FaRTy1billion

It doesn't change anything. And most units, by default, do have 100 shields ... it's just the normal editor doesn't display this and SC ignores it.

In fact, it does something. If marine's(or any other unit without shields) max shield is 10000 or higher, every marine's HP amount will be invisible as if their HP total is 10000 or more. Wireframes work normally.

Quote from sraw531

- Making "Researches" (defined as any upgrade/research that has exactly one upgrade level) not have the ability to change the "max" ups, replacing it with either bubble buttons or something else. (Ie, current -0 -1, Max -0 -1)
- Having the ability to "Hide" things that aren't useful to most, but are still useful to some. (like upgrading the psi storm/cannon damage etc, or assuming burst lasers is useful for anything... or making UNKNOWN players own a trigger.
- Making units without the ability to ever have shields to have shields either blacked out, or preset to 0 (I dont know if theres actually anything useful in changing this, but I was always careful to make my marines have 0 shields, just incase...)

Quote from zzt

Quote from O)FaRTy1billion

It doesn't change anything. And most units, by default, do have 100 shields ... it's just the normal editor doesn't display this and SC ignores it.

In fact, it does something. If marine's(or any other unit without shields) max shield is 10000 or higher, every marine's HP amount will be invisible as if their HP total is 10000 or more. Wireframes work normally.

zzt is correct, giving any unit (terran or zerg) that can't have shields a large value will cause that units HP to become invisible when selected. For this reason it isn't a good idea just to hide arbitrary things that don't look useful. For example the last unused upgrade is actually quite useful. If it had been hidden in the map editor, then it would have been much harder to find this. So there's no real reason to hide unused upgrades or prevent you from setting a max upgrade value of 255 or whatever, because it's possible these settings could do something interesting if used in the right way.

Having said that though, having all the 'extended' player owners for triggers is indeed a complete waste of time, and that should be removed because it really does clutter the place up and confuse noobs.

Quote

Rank: Member Suggestions: (Just incase someone might ever actually use this...)

Heh, I was dreaming up some awsome new UI for a map editor, I'd be very willing to program it out; but I don't know the code structure of a map (is there a resource or source code for old map editors somewhere?) so i'd be stuck at that point

Basically for triggers I thought they should be in a kind of excel speradsheet so you can copy fields (the first field being which trigger it was), parts of triggers, whole triggers, whole groups of triggers, easily rearrange order, and so on. And of course some customizable auto-fill options (which would include quick select for filled out or patially filled triggers that you frequently use)

Some cooler jazz for unit selection (option to resort into your own custom selection groupings), right click on map when in "unit mode" and hit "generate unit", enter a ID or unit name, select what index you want it at... options for creating purposefully dynamic inverted locations for units, a highlighter that tells you whether a unit is in a location you're currently stretching/shrinking

Some accurate mission briefing colors ofc, a briefing simulator (if legal), a rough, trigger outcome caclulator (doubt it could be made accurate for a number of systems, but you could be forced to enter such dynamic data or grab what the data is with the current map layout (not what it would neccesarily be like in game)

Option to view the properties of all your units and locations if not also edit them while a trigger editor is open

And, of course, a code view so you can see everything you're adding and make all possible changes

There is an annoying bug in classic trigger editor. Upon editing a new death condition and choosing current player this happens.

I can only do the condition if I start with other variables, then player. I already miss the old version of draft I had.

That's a feature, not a bug. It's a very poorly implemented feature, but a feature none-the-less.

Ok, how to turn it off then?

You can't. Your options are:

1. Use an older version of scmdraft that doesn't have this Memory condition.
2. Work around the issue as you have been: when creating a new Deaths condition, change the unit to anything other than Terran Marine before you change the player.

This is kinda stupid. Oh well.

Quote from Lanthanide

That's a feature, not a bug. It's a very poorly implemented feature, but a feature none-the-less.

It should not exist because the Memory condition is already selectable, iirc.

Quote from O)FaRTy1billion

Quote from Lanthanide

That's a feature, not a bug. It's a very poorly implemented feature, but a feature none-the-less.

It should not exist because the Memory condition is already selectable, iirc.

Yep, I see that it does. I think the old version of Scmdraft I was using didn't have a separate Memory condition, but the new version I got definitely does.

In the older version you had to go through Deaths to get to the memory function.

Quote from Sacrieur

In the older version you had to go through Deaths to get to the memory function.

Oh THATS what that shit is. It would randomly transform to that when I modified the integer first.