Staredit Network

OK, just to speed things up, here's a modified grpapi.dll with the modification I mentioned, so that it will use SFmpq.dll instead of Storm.dll. That way you don't need to use Storm.dll or manually read the files if you want to use ones from an mpq. Just open the archive and load the file with LoadGrp. Instead of passing a whole file path to it, just pass the file path used in the mpq archive, like this: LoadGrp("unit\\zerg\\devour.grp")

I just tested it also, and I got similar results (or same, I did'nt understand him very well)

You don't have to do anything, zergs bugged
(example, select ultralisk, then select zergling, and zergling will have 4 required supply)

ADDITION: I just tested it some more, and any unit with it checked has its supply bugged so its the same as the last unit

Another ADDITION: seems adding the +0.5 feature bugged up the whole zergs supply, I just had drones using 4 without me editing it, and the ultralisk got the +0.5 checked without me telling it to, now it uses 0.5 supply instead of 4

Btw, why u typed that the Lockdown is used by "Magna pulse" ?

cool... i wish BK will accept ur suggestion
if could show unit's Grp like this



then DatEdit would be " Main Tools of SC modding " in actual fact
and it would be used with iceCC both in same work times
like this....if then it would be cool

I think I found the problem with the +0.5 checkbox...

If you check it the thing disables the regular supply overriding it to make it ½ a supply instead of its original ammount (example: if added to ultralisk, it uses 0.5 instead of 4.5)

It also bugs the normal supply making it a null value, and it changes to whatever the last selected unit had

#####DATEDIT v1.0#####

We're finally there folks. I'm proud to present to you DatEdit v1.0, the first official release of the program. It has everything that you expect from it, plus one or two little improvements over v0.95b. Mind you, it is not any great'o'thing in terms of new abilities, in fact, it's the first version that does not actually add any new features to the program.
Just treat it as another update, but from now on - an official one.

As to my knowledge, the program is finally stable, and it is your task to proove me wrong here, but I hope you won't .


Fixed:
-Now using the new splash screen by Ermac.
-The search box is now a drop-down box, which remembers your previous input.
-The search algorithm is now case-insensitive! (so 'zealot' will go just fine now)
-Moved the Subunit Range property to the Basic subtab, as it does not have to do with graphics.
-Changed the basic tab layout a bit.
-Fixed the supply bug.
If you're curious, I had to tweak the entire data management for this particular property, because it worked in a completely different way than the rest of the program. I can't explain precisely what was the bug all about, but mainly it was based on the fact that DatEdit has 2 UI-data management routines: the data-displaying routine and the data-changing routine. The displaying routine happens to activate the data-changing routine every here and there, BUT the data-changing routine for the supply properties was relying on things that had yet to be defined further on in the data-displaying routine, so it was messing up the data.
In other words - the data-changing routine was using data other than it should, because the proper data was not yet properly defined by the data-displaying routine.....Ok, nevermind this mess... (If you really wanna know what error was because of - look into the code)

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

ADDITION:

I guess you would load your mod's MPQ then? (into DatEdit, maybe one day I'll work this out...

It's good to hear this. As for the layout, VCL (basically, the library that takes care of the DatEdit's GUI) is not very well portable, so I guess that's why.



Hmm....I could've predicated that it's something extra simple. I'll look into this ASAP.


That's interesting, I didn't know that you made the lib SO self-sufficient. Great work on it btw. Just ouf of curiosity, how complex is the code for it? I happen to have some more or less detailed specs for the GRP format, and it virtually sucks my mind away. Did you take care of all the lines'n'frames algorithmics?


Because this is the label of the order that points to the Lockdown's weapons.dat entry, that's why. It is not my design - it's exactly what hex is saying and the orders listing I got from Arse3.

Yay! The 1.0 is here!

Just scanning through it quick, the code doesn't seem really complicated, and it is only 8955 bytes total. As for the other thing you mentioned, I have no clue what you are talking about, since I haven't even looked at most of that code or the format spec in quite a while. All I know is that I haven't yet seen a grp graphic that it couldn't display properly.

BTW, did you notice the modified version of grpapi I posted that uses SFmpq.dll instead of Storm.dll?

Woot! 1.0! YES!

As for the graphics thing:

Woot! Feature creep! YES!

Congratulations BK! It's a RELEASE!!!!

Bk, thought you would like to know this, Subunit range for non-hangar maker units changes the range it picks up targets. If its farther than the weapon range, it walks to it.

I meant if you took all this into account:
http://sourceforge.net/docman/display_doc....&group_id=29488

Hmm...I didn't use Storm at all with DatEd, but I guess it'll speed up the frames loading?

Frontier report from the probe! Sorry for being inactive lately, but school's been consuming me for about 4 weeks straight.



That I think is unnecessary. WinMPQ is very easy to use, and there's no problem in having it open alongside DatEdit. I don't think DatEdit should turn into modding more than the .dat-files (possibly the .tbl's as well, but I don't really like that idea either). The functionality isn't improved by cluttering it up with more options, and it should be kept as easy as possible, but still give complete access to the .dat-file editing

As for the new version: Totally awesome! A tremendously great work! Oh, and nice splash, Ermac

Things I've noted though:
*Two days ago the unit dimension preview stopped working (using 0.95b), but I don't know what I did and I can't reproduce it. Most likely it was just my computer falling apart, something it's quite found of doing.
*A little error in the readme file: "You can move both the executable (DatEdit.exe), the libraries (DLL files) and the data folders "Data" and "default" wherever you want - there is no problem unless these elements are together.DO NOT try to separate them, as this will result in DatEdit refusing to work" Shouldn't be 'unless', it should be 'as long as', right?
*Ignoring the format codes in the .tbls and only displaying the text would probably look better instead of adding the _'s instead of <0> and the little boxes instead of <3>.
*Several labels are too long and several drop-down boxes are too small to display the text in a correct way (the "Unit Dimensions (pixels" in the Movement/Sound tab in the units editor for example). I've made some improvements here. I felt that the drop-down boxes that I made bigger needed that extra width in order to display all the text (we don't want to do like Arsenal III and hide half of the drop-down boxes content, do we? )

If you want to, I can tell you exactly what I changed... By comparing the file I sent with the original, it should be quite obvious though. All changes were made to make it look better and not hide drop-down boxes content, without expanding any group boxes and thus compromising the layout (apart from the Sprite Properties group box in the Graphics tab in the units editor, but it's not a significant change )...

As I said, I relabeled the "Unit Dimensions (pixels):" into only "Unit Dimensions:" and instead I suggest that you change the hints for the four boxes. Just add "Measured in pixels." after the hint of those items Also: Some drop-down boxes (those who display the entries in stat_txt.tbl and especially a few in the weapons editor) still won't display the whole item. This is, as you know, due to the lack of space. As a matter of fact, I find the lack of full string displaying in the stat_txt.tbl boxes to be quite a bit of a bother, but they can't really be made bigger either. Something that shows what string number you've selected would be good, but that's hard to fit into the layout too.... Perhaps have it display the string number you've selected as a tooltip when you hover the mouse over it?

This is, obviously enough, your project, and you are the one who'll have to decide whether or not these are good improvements. See it only as my suggestions.

Data-files notes:
*Not sure if it matters at all, but just thought I'd mention it in case you're not aware... In many of the .txt-files there is a blank line in the end, and that's usually not a good thing. Probably doesn't matter, but still....
*In Images.txt, I found two mistakes: On line 417 there are two ))'s, and on line 581 there is one too little. In Sprites.txt there should be a space before the ( on line 223.
*Some lines have /'s to note more than one sprite and other lines in the same file use \'s For example, in Sprites.txt: "Longbolt\Gemini Missiles Trail" has a \, and "Lockdown/LongBolt/Hellfire Missile" from the same file use /. Yes, I'm insane, and no, I don't mind that at all, but I thought I'd mention everything about the program I could possibly think of, so bear with me

All for now. I think I'm going to have a little freetime the comming weeks, so I hope to test a few more unknowns

It implements even the stuff that is unknown on there, which isn't unknown by me, though.


I didn't mean that you should use Storm.dll. I posted up a modified version that would use SFmpq.dll instead. It isn't needed now, though. I've posted up a new version of GRPapi on my site. Go download it and then you can specifically tell it to use SFmpq.dll without having to hack the .dll file.

Using Storm.dll would actually increase the program's startup and shutdown time, since it is more than just for mpq's, whereas SFmpq.dll loads and closes fairly quick.

SF>Hokay, I get it. Speaking about the MPQs, thanks for that remark about the MPQ-importing error - I managed to get it to work, finally. This means, that -hopefully- DatEdit would be able to operate on MPQs, and MPQs alone one day 8) (no need of bare DATs anymore). However, I don't have much time to work on DatEd these days, so I can't really say how probable this is...Thanks a lot anyways

OH NOEZ, NOT THE END OF BK!!! :C

Actually, I did'nt test either of those...My brood war cd is missing so I cant test that ability...so I guessed based on units,
and my regular starcraft cd is messed up so I cannot get on battle.net

TF>Just let it go, man


Chill out, man - uni is more important for me, that's all

Uni?

...and I am continuing to bug ya about the portrait bug...

in datedit when i click on mineral field the portrait field is blank

ADDITION:
Flying target isn't just used for shoot with air weapons flag
units placed in water without that flag are counted as unplaceable

Yeah, I have the same problem. Mineral Field Type 1 -> Cave-in (Unused) (Id's 176 to 180) don't have a portrait.

uni == University

Hokay, as for the portrait bug, it turned out that in order to remove the portrait for a unit the value needs to be set to 0xFFFF. It works just fine, and has been implemented into DatEd, so you'll see it working properly in the next update.

Well, well, well! Will you look at that? I finally found myself with a bit of freetime! I was messing with some unknowns, and cracked one in Orders.dat (one of the flags):

If Unknown 6 is disabled, the unit that is carrying out the order won't do anything afterwards. In other words, if you disable Unknown 6 on the stop order and ask a group of marines to stop, they will, and afterwards won't do anything. They can't move, can't auto-attack, can't patrol, can't do nothing. I call it "Allow Later Commands" in lack of a better name, though it might not be the best one.

Something that would make DatEdit much better (and that IIRC has already been brought up) is to allow Exporting of the Current File into an MPQ. What the Export To MPQ in DatEdit does right now is to save the currently saved file into an MPQ of your choice, but NOT a version of the one you've been editing. So if you do like I tried, and de-check a couple of flags on the default orders.dat and save it into an MPQ, it will save the DEFAULT file into an MPQ, not a version of orders.dat with the flags de-checked. It took me a while to figure out, and it's annoying

The orders.dat unknown looks sorta bizarre. What's the point of making a unit to stop accepting any further commands?

As for the other thing - I may consider 'fixing' this. True is that it is not 100% obvious that you need to save a file prior to exporting into an MPQ archive. Having designed the exporting routine the way it works now, I didn't think of any other option at all. We shall see...

Well, I don't know really... Allowing a unit to accept other commands after it has issued out the Die command isn't really a great thing, I suppose, but I see a ton of other ways that Blizz could have used instead.... The Tank- and Siege-Modes both have this flag unchecked, so I assume that Blizz didn't want anything to start moving them around or having them attacking nearby enemies as they were Sieging (after done sieging, they turn into another unit which is capable of carrying out other orders) or something... I don't know... All I did was to test and observe the result. I suppose it could do something more than just Allowing Later Commands, but you'd have to bug DoA to dig in the .exe for that

Consider to have two functions then - one "Export Saved File To MPQ" and one "Export Current File To MPQ" The latter could just put the current file with unsaved changes to a temp dir, export to the MPQ and then remove the file and the temp dir... Easy as pie, and it would work pretty well