Staredit Network

Ok here's a splash screen i almost finished some time ago, i just had to renew the version, (now i putted 0.95, but i guess i should make it 0.96 for the upcoming release?)

It's not a miracle, but it would be better than the placeholder, i guess :

[attachmentid=17897]

that's better than holder

Nice, even more as I love that in-game movie..."Drop your socks and cut your throttle!"...hehehe

Worry not about the version number, it is not thought as a part of the splash screen itself (it's just a text label put ontop of it for version compatilibity), so I say you remove it, as well as my true name and surname because it is BroodKiller (that you know) who makes the program, not Jacek Kominek (whom you don't know). Other than this, I like it

Ok I'll remove the version number, but u did said to write your name before

*Edit Ok, here u go:

[attachmentid=17898]

hay how about a reset to defaults for a single unit button?
I bugged a entry in my mod and now i have to copy all the stuff manualy,number by number

I'm going to just throw out random things that I've seen so far.

In the weapons.dat under 'Icon', the labels Cargo Ship and Valkyrie are incorrect. The Cargo Ship should be Lurker(Unused?) and Valkyrie should be Scantid(Desert Critter). Same can be said for the upgrades.dat and techdata.dat as they use the same icons.txt.

The hint for the Splash Radii states "Works ONLY if the 'Explosion' is set to 'Radial Splash', 'Air Splash' or 'Line Splash'." Line Splash does not exist in the "Explosion" dropdown menu. I'm going assume it used to be Line Splash, but was changed to Splash(Enemy).

Under 'Movement/Sounds' of the units.dat, the numbers listed are inconsistent to ID# of the sfxdata.dat. A hint that the number typed in is sfxdata.dat ID# + 1 would help and that 0 = No Sound would help those starting to mod.

I don't know much about the Subunit Range, but something you might add to the hint is that it controls how far the Carrier will launch the Interceptors. (Same can be applied to the Reaver and Scarabs?)

Unknown507(sprites.dat) is the overlay that appears over the Corsair graphic when it attacks.
Unknown945(images.dat) Same as above. Suggested name - Corsair (Attack) Overlay

Also I have to say the DatEdit is a very excellent program. It is very easy to use and it allows the user to edit the both the lists and dropdown menus which A3 did not allow.

btw u could add in the TIPs window the stuff found about Neutral flag

I have just tried the "unknown 164" for a lockdown projectile, and it showed the "unit\bullet\pdriphit.grp" near the ghost, it didnt flew like the projectile, but it did played all his farmes near the ghost, after that the game crashed.

So maybe u could rename the "unknown 164" to "green smoke (crash)" or sth, yet i don't know maybe it crashed because i was trying to use it for a lockdown, and not a basic attack...


*Edit

Just tried "uknown 147" too, and here's what i've got:

[attachmentid=17936]

It spawns a white sprite, which doesnt move, and just leaves stuck there.

If I remember correctly, unknown 147 is used partly in the nuke graphic, and only dissappears when the nuke uses it...

That or it was the unused Extra LockDown firing graphic for the ghost...not sure which one of those though...

ADDITION: I think its the Extra Lock Down Firing graphic (Iscript was removed, so it was placed as a unused iscript)

It looks like a white wraith/battlecruiser laser

#####DATEDIT v0.95b#####

Just small update to cope with the v0.95 issues/comments/ideas. In 99% this is what you'll see released as v1.0

Fixed:
-Icon listing (unused things are marked as unused)
-Splash screen now works properly
-Ranks display is now correct (I found out that there are in fact 2 rank listings in stat_txt.tbl, one for the original SC, and one for BW. I was wrongly using the first one. Now it works well - thanks, TERRAINFIGHTER)
-DatEdit now remembers whether you keep the program window maximized or not. (Darius, we happy? )
-Unit's race affiliation was moved to the Basic tab, next to the supply values.
-The two supply properties are back to normal in-game values, with an additional "+0.5" box next to each of them. (Thanks Taeradun)

New in DatEdit v0.95b:
-Jump Forest, Jump!
Added Jump buttons for the AI/Order tab in units editor. You never know...


Download:
http://www.staredit.net/index.php?download=4668
Source Code:
http://www.staredit.net/index.php?download=4978


Hokay, we're almost there. I'll look into your notes for the next release, ok? For now, I want you ppl to check out and see if you'd be satisfied to see such a product as the (finally final...) v1.0 of DatEdit. I count on you!

So will u be using my splash screen? And see my post on the 18th page, i tested two unklnowns.

Yup, your splash is great, and DatEd will use it.

Page 18.....but why do I have only 10 pages....? (Changed the post-per-page settings )

Lists will be updated, accordingly.

Now get your sorry ass and testz00rz0xz!!!!!11111

*smiles*

Heh heh...Although it considerably more amusing than the actual one, BroodKiller, I feel this little urge that I must tell you this: the name of the Ultralisk hero is not "Torrarsque". You put in an extra "r".

how dare you give me credit for something I didnt do

I'm not the one that solved that, (searches...)I cant even find who posted that


maybe your getting the staredit tab change mixed up with that?

I just came across an interesting occurance while using the latest release of DatEdit. It's a peculiar little thing that amuses and frustrates all at once...

It started with a Zergling. He wanted to be worth half supply. Unfortunately, a Hydralisk wanted to be worth 2 supply. Somewhere down the line? A compromise was made. Both would have the same supply, no matter what the other was changed to. However, if one was given that extra .5? The other turned a blind eye to it.

The moral of this story? The zergling/hyrdalisk, maybe even scourge, supply controls seemed to be interlinked. I give my Hydra's 2 supply, the Zerglings automatically get 2 supply as well. If I check the box for .5 a supply, that one gets it, the other does not.

You all might want to play around with the values yourself. Like I said, it's amuses in a frustrating way, as it seems the two units are linked to the same line of supply code.



By the way, how'd you like my story? Be honest.

ADDITION:
Things actually appear to be a bit more involved than I had originally tested. Change the supply value of any zerg unit, or at least a great deal of them, and then select another one. That unit's supply becomes that of the last one selected. I'm not sure if it's just a GUI issue or if it actually gets changed when loaded into a game, but it's more than a little unnerving.

Oh...it was TheEvilBeaver. Sorry guys....

Darius>I'll investigate this right away.

You have it saying the path to images, why not give an image preview? If you need help with the details of implementing that (especially doing it without having to keep an extracted copy of each), just ask me. I could help with getting it to read them directly from an mpq, and without having to check every single mpq for it.

Maybe previews of some of the other files you have paths to also? Of course, that would get a bit more complicated, though, since no one has made a dll for playing wav or smk files directly from mpq archives, as far as I know. (well, except Blizzard of course; I think Storm.dll has functions for this) Playing the smk files would probably be complicated, but wav wouldn't be as complicated.

One thing I've been thinking about; what if DatEdit could load in additional files to the mpq, such as scripts\ and unit\ folders and associated files? Would make testing a lot easier as well...

Oh, and that problem I mentioned earlier? If you just edit one thing at a time and don't go back to previous entries, the values remain the same. It affects Zerg only as far as I tested. Hopefully it's a fairly easy fix.

Sugguestion: common crash tester

example: once its run, it will check for some of the common values that crash stuff (example, 12 sight range)

ADDITION: I think I know a better explenation for the direction option in the graphics tab (units.dat)

But before I can check into it a lil more I need to know what the highest value is (either 17, 34, 32, or 33, not sure which)

Thanks for the offer, ShadowFlare, I would greatly appreciate such functionality being implemented into DatEd, but there do is a problem I see. If you look into the DatEd's source code, you will notice that a basic MPQ Import (import-to-DatEdit of course) function does exist there, just that it is not used. Reason? It keeps crashing, no matter what MPQ-handling library do I use: SFMPQAPI, lmpqapi, stormlib - whatever. I already mentioned this in some other thread, IIRC. The crash happens when calling the SFileReadFile function. I asked Quantam about it some time ago, and he suggested that it has to do with the pointers used in this function call, but the said pointers have been declared just a few code lines before, so there can be nothing wrong with them, as to my knowledge. If you do manage to solve this problem somehow, I'd greatly appreciate this.
I would have tried doing what you're saying long ago, if only that problem wouldn't appear.

You know what, I think that this is related to the order in which the display and data change functions run, but can't test it from here. Strange it seems for me that it happens only for the Zerg. Are you sure about this?

One problem with this, what if you want your special mod's gfx to display instead of the default?

Just a note, DatEdit runs perfectly in Linux (Ubuntu 5.10) using WINE. The only troubles it has is that the interface is a little messy.

Well, you wouldn't necessarily have to read the file in your own code when using GRPAPI, since it can read directly from MPQ archives. To do this, you must open the archive using Storm.dll, or you can change all references to storm.dll in grpapi.dll to sfmpq.dll (with a hex editor) so that you only have to use one dll for mpq's. After doing this, while you have the archive open you can just call LoadGrp to load the graphics straight from the mpq, like this for example: HANDLE hGrp = LoadGrp("unit\\zerg\\devour.grp"); Then it will attempt to load it from any open archives. BTW, for this you could also make use of the priority parameter of SFileOpenArchive so that it can search through the open archives in a certain order.

I'll look through your code and see if I can find where your mpq problems are (if that code is in there).

-EDIT-

Ah, I found your problem. It's a very simple one; you forgot to allocate space for reading the file into memory and assign the pointer to your buffer variable.


This can actually be done without actually even needing an extra function call, because of how grpapi handles opening files with the LoadGrp function. The archive simply needs to be open first, or the file needs to be in the same path relative to the program as it is in the mpq, so for example if DatEdit was in C:\DatEdit\ and it called LoadGrp("unit\\zerg\\devour.grp"), grpapi would first look for C:\DatEdit\unit\zerg\devour.grp then if it didn't find it, it would search in order all open archives.

Absolutely positive. I started by looking at the supply for zergling in the .95b version and it shows a 0 and the .5 clicked. I look directly after that to the hydralisk. It says 0 supply but the .5 is not clicked. I click the .5 for hydralisk and then check the zergling. The Zergling's .5 was not checked.

I played around with the numbers a bit and I found that if you check the hydra as a 2 or any other number for that matter and then check the zergling, the zergling will have a 2, regardless of what was originally placed within. This all affects the majority of non hero or building type units as well, but some don't appear affected.

Subsequent testing showed nothing wrong with Terran or Protoss.

I'm adding the program in it's entirety. Perhaps it's just mine? I dunno. I tried to take screens, but if they were made they didn't go where I intended them to and digging them out would take considerable time I don't currently possess...