Hallo together,

I registered just one day ago and now I have already the first question: I found this great program made by Roy, the EUD Generator. I wanted a trigger which checks if a certain hero unit is in lockdown. So first I killed all start locations - just to be sure I have the right index number for the unit - then filled the start locations back in. Then I used the index id (56), player number 1 (owner of the unit), and unit status "lockdown" to create the trigger. I got the following out of the Generator:


Then I pasted that into scmdraft (the trigger editor) and edited a second action in. The final version of the trigger looks like this:


Then I clicked on debug, since otherwise scmdraft would not save my new trigger (had to search a little bit until I found a solution to that problem).

I got the following error message:

I have no idea why or even where that line is. There is a message in status bar under the trig edit window which says always Current line: 1306, regardless of where y place the cursor.

Now after I saved the trigger, closed the window and saved the map, in the game nothing happened, after I used lockdown on that unit. Then I reopened the trigger in the scmdraft and the third number has changed! Now the trigger looks like this:


It tried a bit around, and it seems to do this after I close the trigger window. I have no idea why. For example if I make a trigger checking if the unit used a stimpack it does not do that.

Now my question what is going wrong? Is it a problem with EUD Generator using a wrong number (-1) or is it a problem with trigedit/scmdraft? What can I do?

Thanks in advance - all advice is greatly appreciated!

Kind regards,
DG

Post has been edited 1 time(s), last time on Apr 10 2012, 6:20 pm by DerGreif.

First, those errors are completely normal. For some reason SCMDraft gives you errors when you compile text triggers successfully; all they mean is that it worked.

Second, the number didn't actually change. In computing, numbers can be signed or unsigned; an unsigned number can only be positive, but has a larger range. Trying to store a signed number in memory that's supposed to be for an unsigned number causes the number to become the positive number that is represented with the same bits. In this case, the Deaths condition probably uses unsigned numbers; after all it's kind of hard to have had -7 Marines explode. I'm not sure if this makes much sense to you... Uh, trust me I'm a(n amateur) programmer?

Anyway, the issue isn't with TrigEdit, afaik. >.> My /guess/ is that the EUD is incorrect for some reason...

EDIT: Also, what's the reason for detecting Lockdown? I'm just curious.

Post has been edited 2 time(s), last time on Apr 5 2012, 11:21 am by Biophysicist.

Ah, good to know, I did nothing wrong there.
Ahhh, I understand ... nah, just kidding. I think, I might have a vague idea what you are talking about.
Ok then, seems I will have to learn some math and work it out by trial and error - or Roy can come up with an idea what went wrong. I will make some additional tests with another unit status and see how that works out.
Mission objective is to catch a bad guy - ideally alive. For the time being I worked around the issue with some estimated escape times. If the unit takes too long to reach a certain location after its escape routine is triggered, it will surrender (ie be given to a neutral player). This can be done by either using lockdown on the unit or killing it. but it would be much more elegant and not so prone to unusual and unforeseen developments during gameplay, if one could just check if the unit is in lockdown and then give it to a neutral player (ie being caught).

It is just a little style issue. But I think such style issues are important for a campaign which has a focus on the story.

And thanks for the answers! they were greatly appreciated! Maybe some other can fill in the blanks we still have here.

Kind regards,
G.

Well what Bio tried to explain is actually a property of binary numbers which is the way computers store data.
You have a set of bits which represent a number. I'll explain with 3 Bits for ease of understanding:

000 - all 3 bits are 0 which represents a decimal 0
add 1 and you'll have 001 which represents a decimal 1
add 1 and you get 010 (=2). This is because a bit can always only be 0 or 1. That means the last digit overflows to the next and is set back to 0.
I'll complete the table so you get an idea how it works:
011 = 3
100 = 4
101 = 5
110 = 6
111 = 7

OK, now you know how to add, but what's with subtracting?
As you can easily tell from the table 111 - 1 = 110
110 - 1 = 101
101 - 1 = 100
100 - 1 = 011
Did you see what happened here? The last 2 digits from 101 (decimal 5) changed from 00 to 11 when you subtracted 1.
Now imagine you had only 2 bits to store the data. Then 100 would become 00 (= decimal 0) and 011 would be 11 (= decimal -1). But 11 is also 3 in binary. So 3 and -1 are the same numbers because binary can't display negatives.

And this is what happened. Except that 4294967295 = -1 because Starcraft uses 32 bit to store deaths (memory is just a neat way of writing deaths).

---

As for the lockdown detection, you don't necessarily need EUDs here. When a unit is locked down units from enemy computers will rush in to attack. You can use that by checking if a unit leaves its location.

Well, that would work unless the player can Lockdown other units, too; if he can then the computers will rush to attack anything else.

I'll just add that Nude is on the right general track here, but if you find his description confusing, bear in mind that it really isn't confusing in practice.

Expanding on his small example a little more, if you had a variable that you had declared to the computer was Unsigned, then the binary figure 11 would mean "3". If you had another variable that you had declared to the computer was Signed, then the binary figure 11 would mean "-1". For signed numbers, the first bit indicates "negative" and the rest of the bits indicate the number. Nude's explanation could give you the impression that a computer was non-deterministic and sometimes 11 meant 3 or -1, but in practice a computer *always* knows whether it really means -1 or 3. Sometimes the human that has programmed the computer is confused or makes a mistake when dealing with signedness, and that's a bug/error.

To spin it out to a bit more of a useful number, 8 bits, eg 1111 1111 can represent a maximum number of 255 (which is why you sometimes see that number pop up when dealing with computers). An unsigned byte has boundary values of +255 and +0, being all 1s or all 0s. A signed 8-bit byte has boundary values of +127 and -128, where 127 looks like 0111 1111 and -128 looks like 1111 1111.

For our purposes, Starcraft always deals with Unsigned bytes. For some reason the EUD generator created a signed byte with the value -1. In a 32-bit signed byte, -1 looks like 1111 1111 1111 1111 1111 1111 1111 1111, but in a 32-bit unsigned byte that Starcraft uses, that same number is not -1 but 4,294,967,295, which is what you saw after Scmdraft turned the -1 signed integer into an unsigned integer.

As others have already mentioned, -1 is equal to 4294967295 in this case. But as nobody has yet mentioned, you technically don't even need that "at most" memory condition for what you're trying to accomplish anyway, and you can safely delete it if you so desire.

The calculated EUD is correct.

The reason the EUD isn't working is because the unit you're locking down isn't the unit at index #56. Remember that Start Locations don't actually have index IDs, so any unit placed after a Start Location in SCMDraft will have an inaccurate index ID. For example, if you place a Start Location and then a Marine, SCMDraft will tell you that the Marine's index ID is 1, when in fact it is 0.

@NudeRaider
@Lanthanide
Thanks for the extended explanation! Even with not much experience in programming I think I really got it now.



Hmm, are you sure about that? Because - as I wrote in my forst post, I deleted all start locations to get the correct unit index number:


The unit in question had the index id 64 before I deleted all eight start locations. I deleted them just to be sure I did not over see a start location or counted one twice. Then I placed them again, but they got high numbers assigned (after the unit index of the unit in question). I did that because I read first your manual on learning about EPDs/EUDs.

Are there perhaps some other units which are not counted by starcraft, for example map revealers? I have placed some of them. Or anything else I might have done wrong?

But thanks for all advice and your quick replies. I still got not around to test the generator with other units and/or unit statuses, but I will try to get aroundto it later today and then I will post the results here.

If anybody has an idea to solve this problem, please let know! Thans again to all of you!

Kind regards,
DG

Well, if for whatever reason the EUDs don't work then I can send you a mod with a plugin to change P12's minerals or something when the unit is hit with Lockdown. >.> You did say you're making a campaign, after all... So mods are usable...

Perhaps there are other units, but Map Revealers do in fact have index IDs.

Well, the ID is incorrect, I can guarantee you. I apologize for not seeing that you already checked the Start Locations. The only other reason I can think of it not working is that at least 1 unit with an ID between 0 and 55 is owned by a player that is not present when you start the game. Since IDs aren't assigned until the game is initialized, this means if you have a unit owned by Player 2 at index 0 but Player 2 isn't in the game, all IDs shift so that there are no gaps.

Basically, not all your preplaced units are always present when the game begins, so the IDs of any units placed after them will not always be the same. A solution is to either make all preplaced units owned by a computer player and give them to the correct player when the map starts, or change the index ID of the unit you're detecting to an index before any player-owned preplaced unit.

I'll attach a sample map with the EUD working in case you want to review it.

If you send me the map, I'll take a look at it and tell you why it isn't working.

Wait, why not just make the target guy index 0? That way it would never change, right?

Roy, you were right! Your EUD generator works perfectly well! And you were equally right, that the unit index id was wrong. The funny thing is, it was not that the index id was wrong, because there were units on the map which did not get an index id assigned. It was quiet the other way around! There were "units" on the map, which got index ids assigned without showing that in scmdraft: "doodad units"! That is all preplaced traps and doors were assigned unit index ids, which were not shown in the scmdraft unit roster. The ids in the roster started with zero. I was already giving up, after nothing happened even though I had deleted all other units but a ghost and the target. Then I killed all traps and doors, and suddenly it worked. Then I took an older backup and just counted all doors and traps and added them to the index id (after first subtracting the start locations). And voila - it worked! Maybe you could add this tidbit of information to your great learning tutorial for EUDs/EPDs. Should I mention that in the scmdraft thread, too?

Thanks for your generous offer! If I had not the breakthrough today I had taken advantage of that.

I tried that, but it failed - see above. It did not work, because those traps and doors got unit index ids assigned which I did not see in scmdraft.

Again, thanks to all of you who give me so much advice and helped me solve this mystery. Sorry that I am replying so late, but my kids and wife took my time on Easter.

Happy Easter by the wy to all who mind.