Staredit Network

I'm not talking about unit sprites (well maybe I am, but not specifically). Specifically what I'm talking about is finding the sprite IDs for things like bullet puffs or spells effects, using disable doodad on them (like in an always trigger or something), and checking to see if they turn into any kind of trigger-detectable unit or unit sprite (I think you can detect unit sprites with triggers).

Someone told me this idea awhile ago (well, something along the lines) and if it could work it would make the perfect gunner system. However, I'm skeptical about a few points, and since I honestly haven't ventured very far into this kind of stuff, I was wondering if anyone knew anything about this.

I think once upon a time triggers could effect sprites (like trees, road signs and whatnot) but it was disable due to strange things happening, like trees moving or being killed.

Triggers don't seem to have any bearing on sprites at all. I don't know of any way you can detect or effect them.

Thinking about this instantly remimded me about using EUD's.

Since I could change the properties of units using the simple EUD's that were discovered at the time, it doesn't seem illogical that there is some sort of similar data that would've been found to start manipulating sprites.

I'm not completely sure, I can find out from DeathKnight for you. And Unit- Sprites can be detected by triggers I think, well I know for sure that they can be affected (like setting health % and stuff). I'll have to talk with DeathKnight.

The idea might be possible, but before we can disable sprites, we need to know their unit numbers. Unless I am much mistaken, Sprite and units use a different set of numbers. Sprite number 0 is the rock sprite created by so many bugs in starcraft, unit number 0, however, is a terran marine. If we can get editors to accept sprites, not units, then its possible to disable sprites, and possibly even move them. However, we first need to get editors to accept sprites, and I honestly have no idea as to how to do that.

Its being awhile since I've dabbled in this field of Starcraft, but I think this is right:
Its not possible to detect sprites with triggers unless using the EUD methods.
Sprites lie in a different bit than units. Lets take the condition "Bring" for an example.

Bring 'amount' of 'unit' to 'location'. (what the condition looks like)

Bring '1' of 'marine' to 'anywhere'. (what the condition looks like when completed)

What this would look like in EUD style conditions =

Bring '1' of '0' to 'anywhere'. (unit 0 being the marine).

In order to get to sprites you would need to get to the bit that sprites was located in by using a large number for the unit, (pulling a number outta my a$$), like 10070053. So the trigger would look like this:

Bring '1' of '10070053' to 'anywhere'. We all know there's no such unit as '10070053'; the unit number pushed the information and accessed a different part of Starcraft. But, we all know as well, Blizzard patched it, thus eliminating EUD's and their beautiful and endless possibilities
I think thats right...

It may use some other method than this, but lets assume when the game checks a "Bring" condition, "Player 1 brings at least 1 Terran Marine to Location 1", for example, It searches all the unit slots (there about 1700, right?) to find all the marines owned by player 1, and then checks to see if any are touching location 1.

Well, sprites aren't units; they don't occupy a unit slot. The triggers shouldn't be able to find them using such a method.

I suppose it's possible for a "exteded unit ID" to work on a sprite, but I find it unlikely. Triggers tend not to work on exteded units anyway.

Well I know with certain units, as said before, you can turn them into sprites with disabling. I suppose if there's no unit ID for a sprite you obviously can't perform trigger actions on it, but what about the list of unit IDs beyond the normal set? Would using a perpetual "disable doodad" action for any in the map produce the effect of turning any sprites into units (or unit sprites, or whatever) possibly?

Someone told me there was a way to 'get' sprites, but I can't seem to get out of them how they did it lol.

I'll find out if the Set Doodad State trigger works on exteded units.

There may be another problem though. Sprites may not have the same properties that units have. For example, if you find out the number to use to set the doodad state for a sprite, what player does it belong to? All Players might not work.

Don't expect to be hearing lots out of DeathKnight, a cop got shot at his school and his internet died.



Only solution I see is to do lots of research then make either a brand new editor or a plugin for an existing one that will add a secondary triggering system that uses the sprite IDs instead of the unit IDs. And of course, if we could get that to work then we could obviously make a tertiary one that used tile IDs. We could develop the secondary and tertiary one together and make a doodad triggering system. ;o

*Opens C++ manual.*



What exactly do you mean by get them...

Also, see above.

You don't need to make a new editor to use unit IDs in triggers, StarForge can do that if you edit some of it's data files.

In the .lst files, just change anything that says "Unit Unit" to "Number Unit", it's that simple.

It would take endless testing to find a sprite's 'unit number' if it is theroriticly a hhuge number like .

So, the search begins for the begging, or the middle, or we may overshoot it. We are shooting in the dark, arent we?

Hmmm... I nominate you to look for those values.

EDIT:
Just looking at colors...

I have a memory map that deathknight and I worked on a while back (mostly deathknight). Things have been moved in 1.13f but for all I can tell it just seems that they were shifted and the relative positions of everything is the same. I should be able to find the area of sprite memory..

My testing with the Set Doodad State trigger was inconclusive. Is there anyway to find out how thr trigger functions directly?

I can post the machine code of the set doodad state action if you're interested. I'm almost positive that action only affects units, since the "doodads" in question were always unit-sprites, which actually go into the unit array in SC.

The list of currently active sprites starts at 0x5B4284. The array actually grows upwards in memory, so the first sprite is at this address, and the second sprite comes *before* this address. Anyway, each sprite looks something like this:

0x00 - dword - Previous GFX pointer
0x04 - dword - Next GFX pointer
0x08 - word - sprites entry
0x0A - word - Owner
0x0C - dword? - Unk
0x10 - dword? - Unk
0x14 - word - X Position
0x16 - word - Y position
0x18 - dword - Unknown pointer to Unknown1
0x1C - dword - Unknown pointer to Unknown2
0x20 - dword - Unknown pointer to Unknown3

When a marine fires, it creates a new sprite on the top of this list with sprite ID 341 (the gauss rifle hit animation). One thing that's really cool is that the owner of the sprite is the same as the owner of the unit that fired the weapon.

The base address of death counters in 1.13f is 0x5204B4, and the death counts in memory are arranged as follows:

Player 1 deaths of marine
Player 2 deaths of marine
Player 3 deaths of marine
...
Player 12 deaths of marine
Player 1 deaths of ghost
Player 2 deaths of ghost
...

Hope this helps!

Let me know if you want to see a proof-of-concept map.

Wow, I'd love to see a proof of concept for this.


(Jeez it's funny how far I'm going just to get something to shoot something else lol)

OK, I'll set to work on that. It might take me a day or so cause I gotta leave now.

A few of the drawbacks - if you know how many sprites are going to be in the map before the marine shoots, you only need one trigger. Otherwise...you're going to need a lot. This number would also be multiplied by the number of unit types firing that you want to detect AND the number of players you want to detect it for.

Hmm, that sprites part might be a problem because of other unit attacks and spells and such. I would only really need to detect the attacks on like one or two units for a few players, but there's probably gonna be lots of war going on with plenty of other spells and attacks and such producing their own sprites.

Tux, I think you missed this topic from a while back. Is that what you're trying to achieve?

Detecting sprites with triggers ( just plain triggers ) wouldn't work, i don't see how they would. If EUD's were here ( thanks to macs ) starcraft would be a different startcraft today, we could have moving tree's for Ent's or something.

You should be able to detect sprites with EUD conditions. Blizzard's patch only removed the EUD actions - you can still use the conditions.

Tux, it looks like the cooldown method would be much more useful. Let me know if you still want to see the sprite-detection stuff in action.