Staredit Network

Damnation, it didn't work
I didn't even get a placement error... Theory on why not follows:



I tend to disagree. Upon a quick inspection of the trigger format (quick as in a crash course ONLY on what I needed, namely disable/enable, so I don't know how to, say add a new trigger via bytehacking YET ). Anyway, apparently ANY trigger involving locations gets disabled automatically upon saving.

You can easily check this, because a trigger with an "enabled" state has a mark of byte 06, while a "disabled" one has 04. You'll see that there should be 2 04 bytes in the whole file, both corresponding to "move location" and "create at location".

Second proof, When I first tested, I changed the bytes to 06 to enable them, which resulted in a placement error (one which I don't get now, and the marine, is of course, missing as well).

Either that or a 0x0 location is ignored in the creation, but from mapping experience it would result in 2 things: either the unit is created to a small offset from the original location (typically left I think since the grid placement starts from coords 0x0 meaning top left), either a placement error. And I got neither.

Which makes me believe it's hopeless (!@#$%^&*).
Still, I'll think of other possible methods. But I am curious about something. What if only UMS maps have locations ? What I mean is, what if the EXE dynamically creates locations ONLY if the game type is UMS ? That might explain why it doesn't work in Melee (I didn't test in UMS yet, but I THINK with a 35% probability of being right) that it will work... If it does, I will blame Blizz for yet another modding limitation

... yes yes, I know, not their fault... but after 8 years and all patches, I'd say we don't need a "n-th" version of LT (which gets released on every new patch that changes something fundamental in the game), but rather say, new triggers, new actions, new conditions, new orders and netorders (dat editing + mem patching), easier coordonation from techs and upgrades to orders so that we can implement things easier and maybe more unused units... the list can go on...

I mean I do appreciate 1.14 stopping 90% of the cheats and hacks, but after 8 years I actually expected more modding support, considering that WC 3 modders even get their own script that is as close to the internal workings of the game as possible which lets them change about ANYTHING in it. ATM I only have theories on how to replicate that script in StarCraft, but I need a lot of help in making it happen.*sigh*

a) can you for example make some triggers that display a text message or whatever if some player BRINGS a whatever to anywhere? This should be enough to check out if the locations are aactually present in melee.

b) the standard triggers in SE do not use any locations. They use the command-conditions. And if those triggers are used in melee as well, they don't require any locations.

I meant code injection.

No. The reason is because strings are present ONLY in maps, not triggers. Using triggers to display text will make them point to the last string entry... imagine this:



This imaginary code would mean that NoOfStrings is updated everytime you add or remove a new string so that you can simply iterate using:



The problem is, NoOfStrings will point to the last used string... that is the only one present IN EVERY MAP: "Force 4". So whatever it is that you will want to display (which is not something like the map name, map description, force name etc.), it will display "Force 4". Locations do exist, but it is a pain to access them forcefully (and not being able to resize or move them properly is another problem).


I know, but I want to do stuff that is location-specific. In the end I might resort to limitations, but I'd appreciate some more latitude from Blizzard

Ummm.... Ouch?

Really, doesn't seem like you know much about SC strings...
(btw, it's i++; , not ++ i; )

SC loads the strings section into memory, basically a huge bunch of data, containing the actual 0-terminated strings and some other stuff.
When I want to display some string, SC searches its offset which is also included in that bunch of data, and then goes to that offset and reads one szString from there on.

Anyways, what I meant is that you should create a test... mod... or whatever this is, which displays some string, lets say string 1, or whatever. Something from 1 to SomeSmallValue. String 0 is a NULL-string in the case of DisplayTextMsg.
With this test you could make sure if locations can be used at all in melee.

04 is NOT the disabled code. The second bit means disabled, at least according to the specs I was looking at. When I get home tonight I'll try and verify this.

I can't decide if what you said is true or not, because .trg files DO have strings in them. I have no idea what process SC goes through when loading a .trg file for a GOT game though.


Do you seriously not know the difference between prefix and postfix increment?

Actually it does not matter in this case... From what I know. Let's put it that way: I never used prefix increment yet.
Dunno if you know, but you might take into account that my editor is my VERY FIRST program (after the obligatory "hello, world!" console stuff). I learned all my programming - within a few months including a huge pause of 2 months - from the internet and the MSDN library, all by myself.

So much about that.
Not that I was really serious about that, anyways. I knew of the existance and roughly the differences of the two increments. Any I never would write ++ i; in a statement where I can use i++; as well.

One is a postoperator, the other is a preoperator. Personally I like preoperators as they seem cleaner. And there is no difference between them as Heimdal pointed.

And I think you're confusing the strings I meant with the ones I meant If you refer to triggered strings, I think they are where in the map... they get put in memory after map load me thinks. Anyway... long story short, I tested and I can't decide for sure how well forced locations are handled... which IS a problem


Strange, that is the only difference I had by comapring 2 files with the SAME triggers, one had a trigger enabled, the other file had the same one disabled... Also, by modifying the 04 into a 06 it actually gave me a placement error and a created Marine which yours didn't give. Hmmm, weird... on the other hand, I am used to this when it comes to StarCraft


Should be the same... Anyway, you are right about them containing strings, but I am not sure if they are used... I think it's more like a match-up with the real thing in maps, thought this is just a rash conclusion (which seems unlikely since an index is more efficient and results in less processor overhead too). Anyhow... I am not sure what string editors load the strings from... A check would be good.

Still my main foundation on this is that even though you'll delete all trigs, you'll have the map description, team names etc... all which are saved in the map since it'd be pointless to save them in trg files. And it seems silly to have 2 string resources: trg and chk.

I didn't mean to insult your intelligence spinesheath - sorry for that. It looked like you were correcting him for something that was perfectly fine. Misinformation is a big problem round here and it kind of bugs me =P.

There is one HUGE difference between ++i and i++ that's not obvious. If i is an iterator, ++i can be much faster. I'll leave the why part for you to figure out =P. So, it can be good practice to just always use ++i even when it doesn't matter.

The CHK specs I was looking at may have been incorrect and I didn't take the time to verify them. However, I know for sure that 04 is the "always display" flag. I'll have more info on this later...I could be totally wrong too.

Another thing I know for sure is that SC loads the entire STR section into memory as it appears in the CHK - there's no separate runtime structure for it. Which means that it would be rather difficult to add strings to it. But again, I have no idea how GOT stuff works.

See, Heimdal? I am not the only one with imperfect programming knowledge
In THIS CASE there is no difference between them, and Heimdal didn't point that out (though he certainly knows). In other cases, you'll notice differences between them.

You didn't insult me, nono but the way you said it does make me assume that you think I am an experienced programmer, while I in fact am NOT. I am learning fast, but I don't know a lot yet. And I mostly only learn the programming stuff that I need for my editor.
For example I REALLY don't know about iterators (no need to explain, though, I got a look at it in MSDN library, and decided that I am not interested to go into detail ).

Ah, what I forgot to ask: what strings are saved in TRG? And please write some specs

And Nomad, did you already get out if locations are used in Melee at all or not?

EDIT: While I do not know everything, the stuff I say seriously is usually correct.

Off-topic about strings (you'll see why)... I have a feeling GOTRGs work the same as CHKTRGs but the difference here is between Melee/FFA and UMS. Moving on...



No and it's PISSING ME OFF... The reason why I am unsure is because I fear that as with strings, in Melee strings might be disregarded (not sure), which means locations might be disregarded too... In other words, I am not 100% sure (yes yes I will test, but I got a lot to do the upcoming week), but I think there are no locations (apart from Anywhere) in Melee/FFA. So, I think the location I thought I was using was in fact Anywhere (which is the only explanation as to why it didn't move on my Command Center... OK let's assume Anywhere can't be moved... but Location 0 should... it didn't... which leads me back to my point). When I'll have time I'll test the UMS GOT. And if I am right, I'll curse some more lol...

Regarding what spines said about non-locational triggers... This way it's really easy to say, start Z with 3 drones and an overlord (Remove 1 unit is easy doh ), but impossible to add another one (unless I want unit placement error on hunters ).

My guess is "Start Location" is a placeholder for another virtual location (the other would be Anywhere... yes yes, Location 64 but you know what I mean) called "Start Location", which would just move on the unit called "Start Location" and build the required starting units there... in case of "User Select", that is. I am pretty sure about this theory though... but not in full detail... Well, all I'd need is a way to access the Start Location virtual location (not the unit) and it'd all be fine, even thought I wouldn't be able to do the other things I planned, I'd at least have ONE location that I could move around and stuff... so it'd still be something

One location + mobile grids = entire map.

If you can move around the start location location then you can do this.

Well yeah, the problem is I don't think I have one in Melee... and if I do have one (not Anywhere), then it means I have more, which means I can use at least 8-9 per player (some players might need less if any at all, since the chances of 8 players ALL having the SAME race are ... well small unless someone wants to really do a stress test on my triggers at which point I'll settle with 7 per player and 7 more as back-up or for whatever

There can't be any locations for the start locations. At least no locations like the ones we can use.

Hmm, one thing comes to my mind... how does SC set the standard melee setup (nex + 4 probes and so on)? Is it hardcoded or do they use some kind of triggers for that as well?

If there is an "anywhere" location, the others are there as well. It is unlikely that Starcraft has a different locations-memory-structure in Melee and UMS.

Why not ?! Just cos it can't be accessed doesn't mean there isn't... lots of conditions and actions weren't accessible yet EUD proved there were...


Obviously hardcoded as explained before...


There is an Anywhere all the time, but I don't see why you think it's unlikely Melee handles locations differently ... since triggers aren't normally allowed (SC wasn't supposed to be modded in the first place) they might not have included dynamic support for it in SC.

You need to get more arguments, otherwise I jsut think you are assuming thinks without proper foundation

Because of what I know/guess about the way SC is programmed.

The locations are obviously loaded into memory as one block. I don't think they would load a special only-anywhere-location in melee. Either all 64/255 or none at all. Especially when anywhere is location63. It just doesn't seem reasonable to me.

Since there is this block of a fixed number of locations, you can't simply add some for the starting locations. At least they would not be locations of the same type we know. Maybe there is a seperate structure that is used for that, but then it certainly can't be accessed by triggers.

Well I already pointed that out... that is all I needed, IF ONLY they made it accessible...
Anyway, as I said, imo, optimal efficieny (read optimizing iterations, calls on functions, variable accessing and so on in a way that it wastes as little time and resoruces as possible) as well as common sense tells me that if I would program a game, I wouldn't bother the memory to load something I won't use... Since, from my point of view nobody knows about the way I programmed StarCraft - heck nobody can even break the MoPaQ format, I won't load locations since it'd be a waste of time since they are only used in UMS

... still, if they are created nonetheless, than the only explanation is that locational triggers are ignored. But that is not the case since "Create unit" works, so I am inclined to believe my original point that only Anywhere is used in Melee. Anyway, I am not all knowing so you might be right... I'll know for sure when I'll test in UMS

EDIT #1:

bleh... tested... It appears the UMS GOT doesn't have a TRG files associated with it. Well this is of course, logical, since he loads the TRGs from the map, but I was expecting one, dunno why. This seems to strenghten my theory (which is not a good thing).

EDIT #2: I tested with 8 locations - 1 for each player in Melee, and same result: it's created at 0,0.

EDIT #3: Hmm, I must have been drunk or something... You're right about 04 Heimdal... strange though... guess I bytehacked the comment then. It's strange that your trigger didn't create any units though...

Anyway, this seems a lost cause atm, unless there is a way to avoid placement errors and somehow move the unit to the start location (which is pointless, since if it was possible I'd jsut create it there directly...).

!@#$%^&*

To strengthen my theory: All the switches take up space in memory even if not used (in UMS at least), lots of death counters, hell, even all the 1700 unit structures are there right from the start instead of being added when needed...

Then why won't it work ?!

Couldn't you make a sort of virtual location using units and other locations?

So lets say you want a 8x8 location and you have 4 4x4 locations, you could have them center on some units so that they form one big location.

Although, this would be very annoying and unfunctional it could work.

Yes but I am not talking about mapping here. And locations seem to not be used at all