Every protoss unit is prepared as if it would be warped in with a flash; presumably this would have happened when built with the production structure itself.

Certainly, it would look more fluid than emerging out of nothing fully formed.

It is even set so that units are "warped in" when out of transports. This is set in the Zealot's iscript for example.

Yet the warp flash code only works on buildings for some unexplained reason.

I have tried several units.dat and iscript fixes to try to make the Zealot for example have a flash, with zero success.

Anyone has any ideas or had any luck?

I believe making them like buildings or like archons would work, possibly. Maybe. But this would mess with the AI and many other things.

The main point, then, is to have this work when units are first spawned by their regular method... but how?

To get the building warp in effect on any unit it needs to have order 48, order state 1, order signal 1.

To get a unit with the warpin animation to have the warp flash overlay (draw function 17 effect only) it needs to have order 174, order state 0, order signal 1.

Hopefully this information would be useful for you as I don't know how this can be implemented within a mod. Although I do have some ideas.

I don't know how to implement those orders, I only know this



Are they hardcoded?

So far, I only got probes to have some warp in effect at map load (not when built within the game), this is strange.

My other efforts have been fruitless.

I wanted that, when Protoss warps in a unit, it is disabled for a time as the warp effect "coools off" (as it happens in buildings)

This is also a quality detail. Notice how Zerg units do have an emerging from egg animation, but the two others just spawn there

When a unit begins training, it already starts playing Iscript while it's hidden, so depending on which animation you're putting the warp flash in, it may be playing out while it's training, and not when it finishes training.

Ideally you'll want to hook or patch the training secondary order (0x00468420) with GPTP so that it makes the protoss units play the WarpIn animation upon training completion.

Since you also want the unit to remain frozen until the flash fades out, you want to set the "disabled" CUnit status flag (0x400) as well, and hook or patch the warp flash update function (0x004D8590) to clear the "disabled" flag when the warp flash is done.

I can provide more info if GPTP modding is within your scope.

I don't know enough of GPTP.

I know the pySuite and Firegraft

I'm not doing firegraft, rather doing the hex edits directly in the .exe, since Firegraft is always detected as a virus (both the editor and the packaged mod version) and I want to provide the downloaders of the mod with something clean and easy to install.

What are the disadvantages of GPTP and does it give false positives, make the game unstable, etc.?

* * *

I didn't know that about animation play when training. Where is that animation and how can I make it display one? That would be cool for the "Warping In" project.

* * *

My probes are already flashing when built, but, as you say, they move while flashing as well. And the flashing animation resets while they move; it only stops (forever) when they are standing still

I though maybe NOBRK (maybe plus a simple wait) or something like that could help? So nothing interrupts the warp flash code.

Here is my iscript up to now (anyone can use it too):


Also, you need to set the probe warp flash image to "graphic turns" for it to coincide.

Post has been edited 2 time(s), last time on Jan 25 2026, 5:52 pm by NimoStar.

It won't give false positives unless you add code that would. The self-executable MPQ (firegraft/mpqdraft) is what triggers the false positives as it's what attaches to the StarCraft process to modify its memory. The game will become unstable only if you write bad code or if the code provided by the template is bad. The downsides of GPTP are pretty much all under your control.

I think NoBrkCodeSection will work. Should prevent both player orders and following rally point until it ends (but will still allow right-clicking, which will queue the order to be performed when NoBrk ends). The problem remains that the animation is performed before the unit finishes training, and units don't play a different animation upon completion from regular training. Only buildings will play the Built animation after being trained.

Well the code I posted already plays the animation after regular training. Although I can't give any specifics about how that works, it was trial and error mostly.

Now the challenge is making it pause while it happens.


So GPTP doesn't require a self executable or real-time memory modification?

Well the code I posted already plays the animation after regular training. Although I can't give any specifics about how that works, it was trial and error mostly.

Do note I'm using SpecialState1 which might be the reason, not only the build state.

Now the challenge is making it pause while it happens.


So GPTP doesn't require a self executable or real-time memory modification?

It does. It's a plugin loaded by Firegraft/etc., it's just that it's a template from which you can easily write your own game modifications.

Well that's too bad. As I said, Firegraft triggers a false positive for around 100% of windows users that autodeletes the thing, so I'm not using it at present


* * *

By the way, I already got the working code (EDIT: not really, see below everything):


You can adjust the "wait 60"

But this does affect balance since Protoss units will take a bit more to be functional

You should set a bit of faster recruit time to offset it, though not as high as the wait period

* * *

This flashes while beggining them map/spawning via triggers. By not having the "probeinit" go to "SpecialState1" this could be changes

I was right to suspect the SpecialState1 was the key

This state also appears in hatching Zerg eggs. Therefore its what trigger when the unit appears (not when it starts training)

A similar code (along with the direction fix in the images.dat warp entry) can be applied to every Protoss unit

* * *

This only retains the white warp flash at the end of a Structure's sequence, not the blue dark effect before.

I am unsure on how to do orders with iscripts (including ones that trigger different rendering/recoloring modes). If anyone has any tips on that, it will be greatly appreciated


* * *

EDIT: Well screw me, this code, while more refined in regard to preventing probe movement, still doesn't work as I thought,

As told above, the probe will start the animation invisibly when it starts training

The problem was that being impatient, I was testing this while using the "Operation CWAL" cheat, thus training finished almost instantly and I could see the anim.

That's also a "fix" though it involves near-instant training for the anim to display.

I still think this is possible without firegrafting, and that the zerg eggs show that by animating at the end of the morphing sequence, so I will keep my tests...


* * *

Also another idea to make this work given limitations:

Have the training time be near zero, but the warp-in sequence be very long

To avoid a single structure having unlimited production capability, give it a long nobrk animation that functions as a cooldown. The only disadvantage is that all the units produced from that structure will share the same cooldown (but not the same warp-in animation time)

* * *

An extra edit/idea:

Since in normal melee gameplay, the time of unit training is never changed, you can make it "wait" until its precisely done and THEN trigger the warp in animation.

This has some disadvantages though, such as when the unit is made by map triggers, or if the training time is altered from Use Map Settings.

Theory: The "wait" only part doesn't have to be nobrk though, since it will normally be before the unit is made. If the training time is lowered, then the unit warp in sequence will be interrupted and overruled by any commands (even rally).

Post has been edited 5 time(s), last time on Jan 28 2026, 6:10 pm by NimoStar.

I will inform on my "progress"

Technically, the "Wait" before warping in works "perfectly" as expected

with the wait total duration being = to the unit building time (in units.dat)

The Wait can be put in the Build sequence or in the WarpIn sequence.

Here's an example iscript


However I have a disgrace

My game is crashing with a certain code, seemingly randomly

I don't even know if this change is responsible or something else





Can anyone with advanced disassembler/hex programming knowledge tell what this code is about?

Its consistently crashing from the same "instruction" ( 4E1CF6 ), even if the location changes slightly

Related to button strings. It's probably crashing when you're mousing over one of the command card buttons, maybe the rally button since that's the nearest to your mouse cursor in the image. If the button's tooltip has an empty string, it will crash.

If that's not the case, an .ERR file will be more useful.

You are right.

It was a string from a button and thus totally unrelated to the warp in sequence

The warp-in sequence I posted thus works as flawlessly as can be expected given the programming.

The problem was I was adding detailed descriptions to units, and the description of the Dragoon ran out for too long.

It was invaluable to have this info related to the code disassembly, thanks.

Well so just so everyone knows, they can use the latest Probe sequence and instructions to make units warp-in without ill effects known so far.