The actual.

When creating the unit it basically does:
Is it a reaver/warbringer/carrier/gantrithor? If yes, for(i=0; i<UNIT.hangar && i<getHangarMaxByUnitTypeAndUpgrades(player, unitID); i++) createUnit();

So like a reaver with a hangar count of 0 takes 1 slot as expected, one with a hangar count of 4 takes 5 slots, and one with a hangar count of 100 takes 5 or 11, depending on if it is upgraded or not (or a hero)
EDIT: I think. I didn't actually check upgrades. I jsut saw a reference to a function that checks max capacity XD

Post has been edited 1 time(s), last time on Jan 26 2018, 9:23 am by FaRTy1billion.

Ok, the editor works again so that fix is good.

My trigger still doesn't work though. I can now type in UnitID: -9, but it will update it to 65527. If I type in -10 then it changes it to 65526, so that conversion is correct at least. I tried setting IDs 65528, 27 and 26 to 1, 2 and 3 just to check in case my index was off by one: didn't show up.

Salient parts of my trigger are:


The trigger is firing correctly because the marine gets created each time, but the leaderboard never updates, indicating that the trigger isn't setting kills for khaydarin crystal powerup like it should.

If I add this action:

Then when the trigger fires the kills for khaydarin crystal are increased by 4 and this is reflected on the leaderboard. So that rules out some sort of leaderboard bug, and confirms that it is possible to set kills with EUDs in SCR. That address is for P4's kills for that unit; I want to have this trigger owned by P4 and P8, hence use "current player", rather than an EPD with a fixed memory location.

As an aside, I don't know why this value is 1,073,741,719 in scmdraft. According to EUDDB the kills table starts at -2736 for player id? Chkdraft displays this as memory address 0x58A1C0.

Triggers store the unit ID as a uint16, so -9 underflows to 65527. Try that same trigger in 1.16.1, it may be a bug in the EUD emulator with address widths.



The offsets displayed in scmdraft are the index in the death table. So 1,073,741,719 would be:
deathtable[1,073,741,719]

Since entries are 4 bytes
=> deathtable + 0xFFFFFE5C
=> 0x0058A364 + 0xFFFFFE5C
=> 0x000000010058A1C0
That gets truncated to:
0x0058A1C0

The triggers crash in 1.16.1.

I think what I'm trying to do is actually illegal. I want to keep the player value the same (current player) but change unit ID to a negative. Using EUDTrig, it seems that the normal approach for accessing the kills table, is that you HAVE to change the player value to a negative number. Which fundamentally means this action will never work, if you keep the player fixed.

It's only if you're address memory after the deaths table, that you can change the unit ID while keeping the player ID fixed.

What I suspect is happening is that the unit ID is unsigned __int16. So it won't wrap around to a negative offset, it will just access memory past the deathtable. The wraparound for player IDs is due to an unsigned __int32 overflow, since its a 32bit program.

Right, that explains it. I'll give up.

Just use EPDs. Whatever unit ID you are using just multiply it by 12 for player ID and it will work correctly.

Setting the 'transmission' field in 'Set Transmission' to no text (clicking the text field and clicking 'ok') crashes SCMDraft.

Set doodad state offers only 4 unknown options instead of named ones.

Pasting a value into the 'wav' field in 'Set Transmission' crashes SCMDraft.

Post has been edited 1 time(s), last time on Jan 27 2018, 5:43 am by Pr0nogo.

I need to leave to catch my train in 20 minutes, so you get the 5 minute fix version. Download is updated, which should fix all three bugs, but no support for pasting sound filenames yet. That is planned but no time

Thanks for finding those !

Thanks.



Creep is not removed correctly in some cases. Can't replicate it yet, but I cut a bunch of zerg buildings/creep generators and pasted them elsewhere, and the creep didn't get removed.

Can you add filtering to "Unit properties" window? It will be good to find all map revealers, for example.

That's nice to have, but maybe sort by name can work?

As wormer mentioned, you can click on the column headers to sort the list

Doodad sprites are now rendered over the placement squares = harder to see accurate placement info.

Still an issue.

edit: would be amazing to have the unit properties popup receive the same update the classic trigger editor received (let us open multiple + click on stuff in the editor simultaneously).

Post has been edited 1 time(s), last time on Jan 30 2018, 4:58 pm by Pr0nogo.

Recent versions of scmdraft do not seem to be supporting UTF-8 characters properly.

If I put <e2><80><80> in a Display Text field, then if I close the triggers and re-open them, scmdraft converts it into   and this is also what is displayed inside Starcraft. I am referring to this document, which Heinermann made a few months ago when UTF-8 support was first added: https://pastebin.com/zqEc1a5M

The codes are for scmdraft and he says they work for him in the version that he's using, so I'm assuming it was broken recently?

Also if I get one of those characters in Character Map and paste it into the string editor, they initially appear with their correct widths, but after saving and re-opening the editor, they're replaced with normal spaces.

These UTF-8 whitespace characters are necessary, because the width of a standard space is rendered differently in SCR graphics vs classic graphics, so it's impossible to get any text to line up identically on the screen just using normal whitespace characters; the UTF-8 ones are needed to get around this behaviour in SC.

Scmdraft crashes on startup if I don't have any audio outputs enabled in Windows.

Attachments:

" " would be what "<e2><80><80>" represents (smcd only does <>s for values <32), so that part is correct. But if SCMD supports utf8/unicode now (or has a different encoding), then those will be interpreted as " " instead of as a single utf8 character.

EDIT:
I id a different conversion and got " ".. try that? XD

It looks like SCMD does support utf8, but it gets converted wrong so everything jsut turns in to "??"

Post has been edited 2 time(s), last time on Feb 2 2018, 8:28 pm by FaRTy1billion.

I don't support UTF-8 yet (Except via scripting access), since I haven't finished switching the UI to Unicode. That is a very unfun project, so it has very low priority.

Also, I'm not sure if you know this, or perhaps it has been changed, but as far as I know you can't use UTF-8 strings and EUD triggers in the same map.



Good to know, will look into it.

Bah. That would explain it, then. Heinermann was able to input it using scmdraft, but he was just doing a sample map.

Guess I'm screwed then and will have to make do with what I have.

Any chance of making trigger comment strings not be stored in the internal map string database? I'm using 97% of the available string space in my map and I'm going to be adding dozens more strings in the future. I've been through my triggers twice and trimmed as much as I want to from my comments without them becoming really terse and cryptic.

I believe chkdraft stores strings in the file, but not in the normal string table.

This could be an opt-in setting, so people know that they're using a scmdraft proprietary feature (or you could be compatible with chkdraft's method).

Only things that should go into the actual map string table are unit names and display text.