Staredit Network

Hey...are you pointing out that I'm an idiot? Well....apparently I am, because you're right. I dunno what I was thinking when I wrote that...thanks ShadowFlare!

Thats because the movement flag is only blocked if something is checked in another .dat file
what did you rename the 'Hovering' flag to? (it was in units.dat)

ADDITION: if you think thats not what it does, then I dunno what to call it

heres a list of the effects it causes on units
(old list I made when I was using Arsenal III, some things might have been caused by corruptions from it)



and one DoA added to the list "If unchecked for engine overlays, they won't be removed when the unit stops moving."

Another ADDITION: someone needs to test those with DatEdit, so we can figure out which ones where from corruption

You sure?

ADDITION:

Yeah, it completely redoes the names. It doesnt do anything about the C:/IceCC tho. I'll see what I can do.

I re-tested them, and heres my new list (I skipped testing a few since I was 90% positive they wheren't corruption-related)


sorry, but I cannot test the devourer one since my Brood War cd is missing

I think I finally solved it...

if unchecked, it issues a block command to the units control orders, and its iscript

however there is a exception for it, if the units movement is controlled by Flingy.dat,
it overrides the block, allowing the unit to use a move command even though the other commands are still blocked
(might be some way to override the block command to allow attack and stuff, but I havn't found one yet)

want proof? test it out with the drone, uncheck it and the drone can still move since it uses flingy.dat,
but it will not play walking frames since the Iscript.bin is blocked

ADDITION: I'm going to look into this a little more, to see if it changes anything else


Another ADDITION: I just tested it some more, and im 100% sure thats what it does...but I did find a new thing out

when its unchecked, the unit can still move, but when it does it stays in the first frame, just plays turning animations


if you wanna test and see if this is correct, uncheck it for the marine and copy the drones flingy.dat information to the marine, all except the sprites file field

its rather fun to play with, it lookd like the marine was floating, but without a engine!



sorry but I can't think of a name for it, good luck thinking of one

You're probably right about everything you said BroodKiller.

TERRAINFIGHTER, good find, I think you have solved it, because it now explains all the effects that you listed there.

All of the palette errors are probably Arsenal III-corruption related. Especially the ones where units have themselves as their shadow, almost any change to images.dat in Arsenal III will cause that.

All of the other ones in your list except for point 12 ("if unchecked for a unit with a attached turret they wont appear") can be explained because the iscript doesn't run, and so the necessary sigorders don't get run.

I don't remember the iscript for turretted units, but I wasn't aware that it was required that the iscript send some kind of sigorder command to make a turret appear. So perhaps disabling turrets is a secondary effect.



This is really good at describing why the heck they have this command. It's all clear to me now. The floats box exists to assist the iscript in doing its job.

First I'll explain why the Wraith's engine overlays aren't removed. This occurs because the Wraith engine overlays are removed because of their iscript. If you look at the engine overlay iscript, on non-movement animations the iscript will call an "end" command which removes the engine overlay when the unit returns to idle from moving or starts doing anything else. Because the "Floats" box means that only the initial and death animations can be called, this end command never executes, and that is why the engine overlay continues to exist.

I think it's a really good concept how no unit has a main image overlay, all are treated equally and the same animations are called on all of the image overlays. That's one piece of knowledge which I haven't showcased in any of the Doom mods yet so it seems that fact isn't that well known. However, when the same animations get called on all the image overlays, that's where things can get sticky.

For example, the shadow is just meant to be following the main graphic and nothing else, right? So when the unit begins to attack, we don't want to call the attack animation on the shadow, do we? There's no point. That's what the floats checkbox is for. Even though we want the attack animation to be called on one unit graphic image overlay, we don't want it to be called on the shadow. To stop that from happening, we untick "floats".

Thanks TERRAINFIGHTER, it all makes sense now. Perhaps a name for it could be "fully animated" or something? And in the description it could be explained that when ticked, all the animations will be called on the image (overlay), but when unticked, only the initial and death animations will be called. This is necessary because StarCraft tries to call the same animations on all the image (overlays) for a unit. Some of the image (overlays) such as shadows don't need to have anything other than their initial and death animations called, and so this box is left unticked for those image overlays.

I use the word image overlay instead of image because I think it leaves a better hint that all images are actually just overlays and that there's no main image. They're all overlays.


--

Also, something else I noticed. Sprites.dat unknown 1 seems to only be checked for units and not for weapons. Could this have something to do with the fact that weapons cannot have iscript movement control?

actually, its not a side effect...

in the Iscript, the missile turret base orders it to place a missile turret turret overlay above it



therefore, since it disables the iscripts, along with the commands, it doesn't create a image overlay

Oh, I was thinking about the turrets like with the Siege Tank and the Goliath... I know what you meant about the Missile Turret and Science Vessel though.

I finally thought of a name for it, it may not be a good name, but it will have to do untill you think of one

proposed name: "Enable Iscript/Unit Commands"

Description for hint box: "whether or not a animation will accept Iscript.bin orders, along with unit commands

if unchecked, a unit will no longer accept any orders and will only play the first frame
however, the unit will play turning animations (groups of 17 frames in the grp, with frame numbers 2-16 used for mirroring to save space) if 'Gfx Turns' is enabled

on the other hand, there is a way to allow the move commands to function for a unit, a way of doing so would be to have it set to flingy.dat movement control in flingy.dat, and give it working movement values, the effect of doing so allows the unit to appear like its moving by itself, without playing walking frames, and without engines.

if checked, a unit will accept all orders and any command issued by Iscript.bin"

hopefully you can find a shorter label/description

I'm sure you meant the "unknown" checkbox, right BST?

It's a good find, TF, thanks. Fkorz it'll be added to the next DatEd's version, but a better name should be invented for it.

As for other news, I've been hex-checking the pre-BW Iscript.bin (I know, I'm crazy), which is different than the BW one. I heard that it had a certain data section at the beginning, which is in the BW-version filled with 0s (That's where ICE stores it's custom headers' names, btw ), and decided to investigate.

My finds are the following - this section is just the header/offset table that , in the BW-version, is located at the end of the Iscript. It works the very same way, just that it is at the beginning instead of the end of the file. I don't have a clue why Blizzard did move it though...

BTW, are you using the lastest GRPapi version in DatEdit yet, BroodKiller?

SF>Well, yeah, although I haven't time yet to use it to 100% of its abilites (loading GRPs from MPQs etc.), Why?


Maybe, but maybe not. The "logics" behind the way this property works is twisted: you'd have value form -128 to 0 make the circle be put more downwards, and then from 0 to 127, downwards but from the top of the screen. How would a "logical" interpretation look like? I can't think of one...

I just wanted to know if you had downloaded it and were using it instead of the older one, that's all.

Btw, Whaddya say for what I asked you via PM?

I think I'll try to find out what the sfxdata.dat 4 unknowns are all about....

I just thought I might share a little data about the sfxdata.dat unknowns that took me about two minutes to gather.

Unknown 3 {
ID 005 = 1
ID 006 = 2

Others = 0
}

Unknown 4 {
ID 007 = 40
ID 008 = 30
ID 009 = 20
ID 010 = 10
ID 011 = 10
ID 012 = 10
ID 013 = 10
ID 014 = 10
ID 020 = 100
ID 084 = 20
ID 085 = 50
ID 388 = 50

Others = 0
}

------------
Personally, I can't think of anything that would be stored in the sound data file other than length (which would be unneeded), perhaps the instances of the sound that could be played at once, and maybe some sort of pitch or length manipulation, but I doubt that most of all.

in Units.dat's Graphics tab, the hint for Direction needs to explain it better

heres about how it should be explained

No, 32 is a random direction.

Even if that hint is technically correct (which, as toss pointed out, it isn't), it really doesn't help a newbie understand what it is. It is way too confusing.

I suggest you either have a straight-forward EASY explanation, followed by the technical stuff, or simply keep the technical stuff out of it, since those interested can probably find that out in other ways...

I realize some technical talk may be needed to make people understand that value, but do try to keep it on a much easier level.

okay, I'll try to fix it up so its shorter and easier to understand

Sorry about that, turns out it reads 0-32...I was thinking it was 1-32 and there was no random direction (0-31 are regular)

ADDITION: heres my shorter version of the 'Hint'

Another ADDITION: I was just working on my mod, editing the lockdown spell...
and I realised that the calling order for the spell (in orders.dat) is mis-named,
its "Magna Pulse" when it should be "Lockdown" or "Cast Lockdown"

Those names are loaded from rez\stat_txt.tbl, so it's Blizzard's name, not ours.

Look at entry 992 in the file