Report, edit, etc...Posted by BroodKiller on 2006-09-30 at 10:59:50
Now I realized that I have done both things for the v1.3....I've coded both support for multiple temp directories and for reading files as buffers. I do am a fool.... 
Report, edit, etc...Posted by Ojan on 2006-10-05 at 13:26:23
Still.... A temp-dir can be useful if it's updated in realtime. If you forget to save and windows decide to crash (or DatEdit for some reason or another is closed), then you'd still have your changes intact.
However, if you don't save, you can't really demand a program to be absolutely fool-proof either...
However, if you don't save, you can't really demand a program to be absolutely fool-proof either...
Report, edit, etc...Posted by Kookster on 2006-10-09 at 15:08:11
Ok I came up with a way to incorperate what BSTRhino and I wanted it required some moving and some size changing on the image tab but it looks good. All it adds is a Used by for the Iscript and GRP so you can tell what else is using it thats all we really need.
Tell me what you think.
[attachmentid=21411]
or
[attachmentid=21412]
ADDITION:
I have a suggestion for another feature but I dont know if this is even possible, cause its Iscript based. Basicly what would help if there was a way you can check to see which image files are used by the iscript and what those ID#'s are. So all it would say in the used by is [I...] so you could hunt it down in the iscript. Heres a example the archon beam is used by the archon attack in the iscript. In datedit it doesnt say its used by any dat but its used by a iscript. This would be real useful but no worries if you cant do it.
Tell me what you think.
[attachmentid=21411]
or
[attachmentid=21412]
ADDITION:
I have a suggestion for another feature but I dont know if this is even possible, cause its Iscript based. Basicly what would help if there was a way you can check to see which image files are used by the iscript and what those ID#'s are. So all it would say in the used by is [I...] so you could hunt it down in the iscript. Heres a example the archon beam is used by the archon attack in the iscript. In datedit it doesnt say its used by any dat but its used by a iscript. This would be real useful but no worries if you cant do it.
Report, edit, etc...Posted by BroodKiller on 2006-10-12 at 09:10:37
Now this looks much better, I like the first way you've made it, and rest assured I will at least think about including it 
As for Iscript parsing - that's a negative, mate. By definition, DatEdit is to be work with DAT files, and only them. To be honest, this is another thing that keeps me away from including the TBL-editor into it...
As for Iscript parsing - that's a negative, mate. By definition, DatEdit is to be work with DAT files, and only them. To be honest, this is another thing that keeps me away from including the TBL-editor into it...
Report, edit, etc...Posted by Oo.Insane.oO on 2006-10-12 at 15:32:53
QUOTE(BroodKiller @ Oct 12 2006, 08:10 AM)
Now this looks much better, I like the first way you've made it, and rest assured I will at least think about including it
As for Iscript parsing - that's a negative, mate. By definition, DatEdit is to be work with DAT files, and only them. To be honest, this is another thing that keeps me away from including the TBL-editor into it...
[right][snapback]575543[/snapback][/right]
As for Iscript parsing - that's a negative, mate. By definition, DatEdit is to be work with DAT files, and only them. To be honest, this is another thing that keeps me away from including the TBL-editor into it...
[right][snapback]575543[/snapback][/right]
Y not change the name and put everything into it so it is the ultimate modding tool
you dont need to do everything at once eather just casually add somethingReport, edit, etc...Posted by BroodKiller on 2006-10-12 at 15:50:39
This is an option, and it is a one that I've once considered, and other people have discussed a few times already. The final answer, for the time being, is negative. This is because at my current occupation, by myself, I am not able, and in all probability I will not be able to devote as much time as is necessary for design and maintenance of such an application. I can do small upgrades to an existing tool, like I do now for DatEd, but creating a fully-fledged multi-format specific program is beyond the scope I intend for gaming-related things in my life.
Report, edit, etc...Posted by Oo.Insane.oO on 2006-10-12 at 17:39:57
o
Report, edit, etc...Posted by Ojan on 2006-10-12 at 17:44:53
I don't see why anyone would really want such a program that badly at all. Would it really be that much easier to have a tool capable of modding every aspect in every file rather than having one for *.dat's, one for *.grp's, one for tileset files etc?
By merging all tools, you create a tremendously complex program. This complexity is avoided by separate tools for separate files. If you want to change the graphics of a unit you just use a converter to make your changes, and thus you don't have to worry about how the doodad placement flags work - there are no such things in RetroGRP (or whatever converter you use), because it's not GRP related.
By merging all tools, you create a tremendously complex program. This complexity is avoided by separate tools for separate files. If you want to change the graphics of a unit you just use a converter to make your changes, and thus you don't have to worry about how the doodad placement flags work - there are no such things in RetroGRP (or whatever converter you use), because it's not GRP related.
Report, edit, etc...Posted by wingedcloud on 2006-10-13 at 09:20:20
broodkiller, you know what? YOUR DAT EDITOR ROX!!! IT OWNS!!
Report, edit, etc...Posted by BSTRhino on 2006-10-18 at 13:44:02
I just wanted to post some new interpretations on some fields that I've been having. These aren't definite but I thought you guys might be interested.
For the homing/bouncing/normal thing in weapons.dat, what I've seen it affecting is what happens when a target outruns a missile.
Homing - if the target unit outruns the missile, the missile won't chase the target beyond its maximum range, it'll just explode when it reaches the place where the target was before it left maximum range. If the target unit dies before the missile reaches it, the missile will just disappear (I can't remember whether the death animation is run)
Bouncing - if the target unit outruns the missile, the missile will chase the target, but only a short distance beyond maximum range. The missile will just explode in mid-air if the target unit goes too far. If the target unit dies before the missile reaches it, the missile will just hit the spot where the unit was when it died, but the previous rule still applies - the missile won't travel too far beyond its maximum range.
Normal - if the target unit outruns the missile, the missile will chase the target no matter how far it has to travel, and if the target unit dies before the missile reaches it, the missile will just hit the spot where the unit died.
I tested this out a few times with a really slow weapon and that's what I got. I hope this is right.
For the homing/bouncing/normal thing in weapons.dat, what I've seen it affecting is what happens when a target outruns a missile.
Homing - if the target unit outruns the missile, the missile won't chase the target beyond its maximum range, it'll just explode when it reaches the place where the target was before it left maximum range. If the target unit dies before the missile reaches it, the missile will just disappear (I can't remember whether the death animation is run)
Bouncing - if the target unit outruns the missile, the missile will chase the target, but only a short distance beyond maximum range. The missile will just explode in mid-air if the target unit goes too far. If the target unit dies before the missile reaches it, the missile will just hit the spot where the unit was when it died, but the previous rule still applies - the missile won't travel too far beyond its maximum range.
Normal - if the target unit outruns the missile, the missile will chase the target no matter how far it has to travel, and if the target unit dies before the missile reaches it, the missile will just hit the spot where the unit died.
I tested this out a few times with a really slow weapon and that's what I got. I hope this is right.
Report, edit, etc...Posted by BroodKiller on 2006-10-24 at 14:42:13
Thanks BST, I wanted to ask people for verification of this property, btw
As for a bit of news about v1.2c, its progress has been slowed down by technical difficulties of unknown origin. I keep getting a strange error on runtime, and to pick it out I will need to get back to v1.2b and then slowly proceed with the changes I made for v1.2c, which means I'll have to redo the thing. But stay sharp, I'm pretty confident it won't take long.
-BK
ADDITION:
Okay, I've worked it out. DatEdit progress resumed
ADDITION:
More news: I managed to do almost all that I intended for v1.3 (yeah, I changed the release number again, bear with it:P). It will have the GRP/Iscript reference system implemented (although in a way completely different to anything that was proposed:)) as well as custom names loading (but for the units listing only, for technical reasons), as well as quite many minor improvements.
Right now I am finalizing the support for the custom names for the different sorting styles, and when I'm done with this (very soon) a choice presents itself. A choice I want to hear your opinions about.
As some of you know, since the very beginning DatEdit had the TBL-editing feature planned. Later in the development, I scraped the idea for some reasons, then I resurrected it, and I abandoned it once more. Technically, it was 94% done - I had yet to fix some stat_txt.tbl related issues. The thing is that I do not want to drop my own hard work, and I lean towards adding this feature into the v1.3 release, but I could live without it just fine. I would like to know your opinions about this idea
At the current stage the feature works in the following way: you select a TBL-pointing drop-down box, and press ENTER. Then, a new box appears, with one textbox cotaining the original string and a second one where you input the new one (in a nutshell). You do what you want, click OK, and the changes are applied. Simple as that.
I see two problems with it (in its current shape): First - it does not offer color preview, nor color tags input support (unless you know the hex codes for them:P) and second - the output routine is DAMN slow. It really is, and the earlier entry you want to edit, the slower it gets (which is obvious if you know the TBL file format).
Both can be,of course, solved, but I am not sure if I want to spend even more time doing this - and that's why I need your opinions with encouragement/discouragement, because I am sitting on the fence right now.
As for a bit of news about v1.2c, its progress has been slowed down by technical difficulties of unknown origin. I keep getting a strange error on runtime, and to pick it out I will need to get back to v1.2b and then slowly proceed with the changes I made for v1.2c, which means I'll have to redo the thing. But stay sharp, I'm pretty confident it won't take long.
-BK
ADDITION:
Okay, I've worked it out. DatEdit progress resumed
ADDITION:
More news: I managed to do almost all that I intended for v1.3 (yeah, I changed the release number again, bear with it:P). It will have the GRP/Iscript reference system implemented (although in a way completely different to anything that was proposed:)) as well as custom names loading (but for the units listing only, for technical reasons), as well as quite many minor improvements.
Right now I am finalizing the support for the custom names for the different sorting styles, and when I'm done with this (very soon) a choice presents itself. A choice I want to hear your opinions about
.As some of you know, since the very beginning DatEdit had the TBL-editing feature planned. Later in the development, I scraped the idea for some reasons, then I resurrected it, and I abandoned it once more. Technically, it was 94% done - I had yet to fix some stat_txt.tbl related issues. The thing is that I do not want to drop my own hard work, and I lean towards adding this feature into the v1.3 release, but I could live without it just fine. I would like to know your opinions about this idea
At the current stage the feature works in the following way: you select a TBL-pointing drop-down box, and press ENTER. Then, a new box appears, with one textbox cotaining the original string and a second one where you input the new one (in a nutshell). You do what you want, click OK, and the changes are applied. Simple as that.
I see two problems with it (in its current shape): First - it does not offer color preview, nor color tags input support (unless you know the hex codes for them:P) and second - the output routine is DAMN slow. It really is, and the earlier entry you want to edit, the slower it gets (which is obvious if you know the TBL file format).
Both can be,of course, solved, but I am not sure if I want to spend even more time doing this - and that's why I need your opinions with encouragement/discouragement, because I am sitting on the fence right now.
Report, edit, etc...Posted by DiscipleOfAdun on 2006-10-24 at 15:39:59
My short answer - it'd be nice, but it's seems like just using TBLPad would be easier for modders.
I'll expound more later.
I was in a hurry...late for class.
I'll expound more later.
I was in a hurry...late for class.
Report, edit, etc...Posted by BroodKiller on 2006-10-24 at 15:50:08
I suppose you mean TBLPad...
Report, edit, etc...Posted by Ojan on 2006-10-24 at 15:51:35
It's a minor feature, so I it really wouldn't matter for me. Since you are asking for our opinions, I'll say mine anyway :P
You say it's slow and doesn't have support for colours which is very common in strings. If you are to add it, the minimum requirement as I see it is to have it working good. A "DAMN slow" function isn't going to help anyone really...
Secondly... There isn't much need for this anyway as I see it. When you mess with image.dat, you might want to change the Iscript at the same time, since it's so related, so including such an editor into DatEdit would have a reason. However, there really isn't any situation in the .dat-editing process where you need to change the names of something in order to continue with what you're doing. A .tbl-editor would not make anything smoother or easier really. It would purely be a visual help for the modder, but if it's possible to load custom .tbl's, the gain is close to none. I'm tired, so I don't know if I really expressed myself very good at all, but what I'm saying is that a .tbl-editor inside DatEdit would be out of place, and not make anything smoother. Especially not if the tbl-editor is slow and incomplete :)
BTW, I'm not saying that you should include an iscript-editor. What I said is that there would be a reason to do so since it is connected to .dats, but for quite a few other reasons, I strongly belive that merging tools like that is not a good idea.
[edit=1]BK: You never know... I still have TBLEdit from Camelot Systems laying on my harddrive ;)[/edit]
You say it's slow and doesn't have support for colours which is very common in strings. If you are to add it, the minimum requirement as I see it is to have it working good. A "DAMN slow" function isn't going to help anyone really...
Secondly... There isn't much need for this anyway as I see it. When you mess with image.dat, you might want to change the Iscript at the same time, since it's so related, so including such an editor into DatEdit would have a reason. However, there really isn't any situation in the .dat-editing process where you need to change the names of something in order to continue with what you're doing. A .tbl-editor would not make anything smoother or easier really. It would purely be a visual help for the modder, but if it's possible to load custom .tbl's, the gain is close to none. I'm tired, so I don't know if I really expressed myself very good at all, but what I'm saying is that a .tbl-editor inside DatEdit would be out of place, and not make anything smoother. Especially not if the tbl-editor is slow and incomplete :)
BTW, I'm not saying that you should include an iscript-editor. What I said is that there would be a reason to do so since it is connected to .dats, but for quite a few other reasons, I strongly belive that merging tools like that is not a good idea.
[edit=1]BK: You never know... I still have TBLEdit from Camelot Systems laying on my harddrive ;)[/edit]
Report, edit, etc...Posted by ShadowFlare on 2006-10-24 at 19:04:30
Hmm, if you already have the TBL stuff fully implemented but want it working better, I could rewrite the related parts for you with a faster implementation that would also support some system for inputting color codes, maybe kind of like in TBLPad.
BTW, I would need to write it all from scratch for two reasons: 1) I no longer have the code and 2) It was VB code. It would probably be much faster than the TBLPad implementation anyway (which was already pretty good, considering TBLPad is a VB4 app). I had to do a lot of tweaking to get it reasonably fast at loading .tbl files in it. Of course, the time for saving them was never an issue, though.
As for iscript.bin, maybe DatEdit could include some type of parsing of IceCC scripts, mainly for finding references between images.dat and iscript.bin? That would probably be easier than adding a full-blown iscript.bin editor, and it would make debugging iscripts at least somewhat easier, probably.
BTW, I would need to write it all from scratch for two reasons: 1) I no longer have the code and 2) It was VB code. It would probably be much faster than the TBLPad implementation anyway (which was already pretty good, considering TBLPad is a VB4 app). I had to do a lot of tweaking to get it reasonably fast at loading .tbl files in it. Of course, the time for saving them was never an issue, though.
As for iscript.bin, maybe DatEdit could include some type of parsing of IceCC scripts, mainly for finding references between images.dat and iscript.bin? That would probably be easier than adding a full-blown iscript.bin editor, and it would make debugging iscripts at least somewhat easier, probably.
Report, edit, etc...Posted by DiscipleOfAdun on 2006-10-24 at 19:59:59
Well, Ojan pretty much summed up my reasons. The main thing how needed it is(or actually, isn't). I know that it seems like a good thing to have, but I doubt the usefulness of it.
And either program would count, but BK was right on which one I meant. I fixed it.
And either program would count, but BK was right on which one I meant. I fixed it.
Report, edit, etc...Posted by Kookster on 2006-10-24 at 21:41:02
I agree with Ojan aswell, except I would find loading custom .tbl just for veiwing reasons when editing things would be useful.
Report, edit, etc...Posted by Ojan on 2006-10-26 at 17:40:37
Yes, it is possible to load custom stat_txt.tbl's. And since we have that option, the whole TBL-editing part is rendered almost completely useless in my eyes, for the reasons I stated in my post above. Even if the editing would be fast and support tags, it still isn't needed.
Report, edit, etc...Posted by Kookster on 2006-10-27 at 01:17:18
we do have it??? ::goes and checks datedit::
ADDITION:
O in the options hahaha, feeling dumb right about now.
ADDITION:
O in the options hahaha, feeling dumb right about now.
Report, edit, etc...Posted by BroodKiller on 2006-10-28 at 04:56:57
########DATEDIT 1.3##############
Hello kids, it's me again - didn't you get bored of this regular updates yet?
Fixed/Changed:
-Improved DatEdit internal ID-handling, which means the program should now work much faster
-Running multiple DatEdit applications at the same time should work fine now (every running copy will have its own TEMP directory)
-Redesigned the "Options" window to increase its accessibility - all the options are now on a single page.
-Sound subtab text boxes are now reactivated properly.
-MPQ Importing now works properly (it didn't in v1.2b).
-Added ID-input boxes for the units.dat weapons pointers, the weapons.dat flingy pointer and the weapons.dat cmdicons.grp pointer (in case someone adds new icons and doesn't link the new cmdicons.grp to DatEd first). The Weapons Editor layout had to be modified a bit, but I hope it is still as functional. I used it almost up to 100% now, and I can't really think of any more improvements to it - there probably won't be an ID input box for the "Label" and "Error" TBL-pointing properties, because this would clutter up the already cluttered up Weapons Editor's layout too much.
-Added ID-input boxes for the Tech and Upgrade Editor's "Label" and "Icon" properties for the same purpose as above.
-Inputing icon ID larger than the number of icons available results in an empty preview, and not a frozen last-selected icon image.
-The "Rank/Sublabel" property now uses a fully functional dropdown box instead of the limited textbox it used previously. IMPORTANT:If you plan to add new entries to a TBL and use it with DatEdit, then keep in mind that this property only accepts values within the range 0-255 and that I programmatically restricted that this box accepts not more than 255 entries. This is an issue of the type of variable used to store this property and I cannot do anything about it. This note has also been added to the appropriate hint.
New in DatEdit v1.3:
-Iscript ID and GRP Referencing
Images Editor now features two new buttons, each launching a specific reference check through the currently used images.dat file for either the "Iscript ID" or the "GRP File" pointer property of images.dat. The result is displayed in the standard "Used By" box in the lower right-hand corner of the program's window, OVERWRITING any 'sprites.dat->images.dat' backreference that it may contain. Selecting a new entry brings back the original functionality. Results of these new reference checks can be, as usual, double-clicked to jump straight to a specific entry.
The discussion over the implementation of this functionality was long and hard, as many different options of doing so were considered. Eventually, I decided to go for simplicity and friendliness rather than exaggerated complexity, partially because that's how I like things to be, and partially because DatEdit is regarded as a 'basic' tool for SC modding, and as such it should be kept as accessible to users as possible.
A remark that I have to make is that this feature has sort of a minor 'glitch' in it. The thing is that pressing either of the buttons will launch the reference check for the currently selected item of either of the two featured fields. This means that in order to check which other entries use a particular GRP or an Iscript ID, you need to make some entry use it first, and thus the check will always return at least one result, being the entry you've run the reference check from. This is what I would call here a "false positive" result, since the entry doesn't really need to use a particular GRP or Iscript ID. It is not a serious thing, but still. I left it be, for simplicity and friendliness reasons, and I hope it won't bother you more than it should
-Custom Names loading
This has long been asked for, and it is finally present in this release of DatEdit. If a new "Use custom units names" option is checked in the "Options" box, DatEdit will load the names for the Units Editor entries from the linked "stat_txt.tbl" file or from the imported MPQ archive, if such a file is present in it.
But don't jump off your shoes just yet, as this feature is not -to my mind- as cool as it may seem right off the bat. First, it works only and exclusively in the Units Editor, and this is because its listing is in one place inside "stat_txt.tbl". Other TBL-based listings are separated between original SC and BW listings, which makes it a much more complex task to get it to work properly. And - to be honest - I don't have time to make it work for the rest, even less as 99% of the requests for this feature concerned the units listing only. Second, the names read from "stat_txt.tbl" are much less friendly and informative, so I don't suggest using this feature in the early stage of a mod, but rather a bit later.
The DLDB does allow me to upload the new version, so I'm putting it up elsewhere, and I will try to update the SEN's download as soon as I can.
Program:
http://www.logicalknot.org/Datedit/DatEdit v1.3.zip
Source:
http://www.logicalknot.org/Datedit/DatEdit v1.3 source.zip
No, as you can see, there is no tbl-editing here
As usual, comments, reports and feedback are most welcome. Enjoy
-Broody
Hello kids, it's me again - didn't you get bored of this regular updates yet?
Fixed/Changed:
-Improved DatEdit internal ID-handling, which means the program should now work much faster
-Running multiple DatEdit applications at the same time should work fine now (every running copy will have its own TEMP directory)
-Redesigned the "Options" window to increase its accessibility - all the options are now on a single page.
-Sound subtab text boxes are now reactivated properly.
-MPQ Importing now works properly (it didn't in v1.2b).
-Added ID-input boxes for the units.dat weapons pointers, the weapons.dat flingy pointer and the weapons.dat cmdicons.grp pointer (in case someone adds new icons and doesn't link the new cmdicons.grp to DatEd first). The Weapons Editor layout had to be modified a bit, but I hope it is still as functional. I used it almost up to 100% now, and I can't really think of any more improvements to it - there probably won't be an ID input box for the "Label" and "Error" TBL-pointing properties, because this would clutter up the already cluttered up Weapons Editor's layout too much.
-Added ID-input boxes for the Tech and Upgrade Editor's "Label" and "Icon" properties for the same purpose as above.
-Inputing icon ID larger than the number of icons available results in an empty preview, and not a frozen last-selected icon image.
-The "Rank/Sublabel" property now uses a fully functional dropdown box instead of the limited textbox it used previously. IMPORTANT:If you plan to add new entries to a TBL and use it with DatEdit, then keep in mind that this property only accepts values within the range 0-255 and that I programmatically restricted that this box accepts not more than 255 entries. This is an issue of the type of variable used to store this property and I cannot do anything about it. This note has also been added to the appropriate hint.
New in DatEdit v1.3:
-Iscript ID and GRP Referencing
Images Editor now features two new buttons, each launching a specific reference check through the currently used images.dat file for either the "Iscript ID" or the "GRP File" pointer property of images.dat. The result is displayed in the standard "Used By" box in the lower right-hand corner of the program's window, OVERWRITING any 'sprites.dat->images.dat' backreference that it may contain. Selecting a new entry brings back the original functionality. Results of these new reference checks can be, as usual, double-clicked to jump straight to a specific entry.
The discussion over the implementation of this functionality was long and hard, as many different options of doing so were considered. Eventually, I decided to go for simplicity and friendliness rather than exaggerated complexity, partially because that's how I like things to be, and partially because DatEdit is regarded as a 'basic' tool for SC modding, and as such it should be kept as accessible to users as possible.
A remark that I have to make is that this feature has sort of a minor 'glitch' in it. The thing is that pressing either of the buttons will launch the reference check for the currently selected item of either of the two featured fields. This means that in order to check which other entries use a particular GRP or an Iscript ID, you need to make some entry use it first, and thus the check will always return at least one result, being the entry you've run the reference check from. This is what I would call here a "false positive" result, since the entry doesn't really need to use a particular GRP or Iscript ID. It is not a serious thing, but still. I left it be, for simplicity and friendliness reasons, and I hope it won't bother you more than it should
-Custom Names loading
This has long been asked for, and it is finally present in this release of DatEdit. If a new "Use custom units names" option is checked in the "Options" box, DatEdit will load the names for the Units Editor entries from the linked "stat_txt.tbl" file or from the imported MPQ archive, if such a file is present in it.
But don't jump off your shoes just yet, as this feature is not -to my mind- as cool as it may seem right off the bat. First, it works only and exclusively in the Units Editor, and this is because its listing is in one place inside "stat_txt.tbl". Other TBL-based listings are separated between original SC and BW listings, which makes it a much more complex task to get it to work properly. And - to be honest - I don't have time to make it work for the rest, even less as 99% of the requests for this feature concerned the units listing only. Second, the names read from "stat_txt.tbl" are much less friendly and informative, so I don't suggest using this feature in the early stage of a mod, but rather a bit later.
The DLDB does allow me to upload the new version, so I'm putting it up elsewhere, and I will try to update the SEN's download as soon as I can.
Program:
http://www.logicalknot.org/Datedit/DatEdit v1.3.zip
Source:
http://www.logicalknot.org/Datedit/DatEdit v1.3 source.zip
No, as you can see, there is no tbl-editing here
As usual, comments, reports and feedback are most welcome. Enjoy
-Broody
Report, edit, etc...Posted by Kookster on 2006-10-28 at 14:45:05
OMG I LOVE IT!!!! My Iscripting heart is overwhelmed!!!
The added ID# boxes will definatly help things go faster, and the layout still looks good.
And adding custom names, tiss useful, now I know which units I havent messed with
.
The added ID# boxes will definatly help things go faster, and the layout still looks good.
And adding custom names, tiss useful, now I know which units I havent messed with
.Report, edit, etc...Posted by Voyager7456(MM) on 2006-10-28 at 15:38:00
Custom unit names support? BroodKiller, I love you! 
Thanks so much for continuing to support this awesome program!
Thanks so much for continuing to support this awesome program!
Report, edit, etc...Posted by NightKev on 2006-10-28 at 16:37:39
I found a bug (or something) (and yes it's v1.3):
Tab: Unit
Subtab: StarEdit
Checkbox: Player Settings
Bug: No tooltip for it (like when you click on something the text box at the bottom says "This option does this." only this one is blank).
Tab: Unit
Subtab: StarEdit
Checkbox: Player Settings
Bug: No tooltip for it (like when you click on something the text box at the bottom says "This option does this." only this one is blank).
Report, edit, etc...Posted by Kookster on 2006-10-28 at 18:54:09
atleast its nothing serious that can get fixed and wait for the next release
Report, edit, etc...Posted by TheNomad on 2006-10-29 at 17:39:43
Nice release
Typo in Weapons: Mojo has ANIT instead of ANTI Matter Missiles
As for Floats... I believe the description is way too vague and not helpful enough (which might scare people from using it as it is properly anyway). Try being a bit more descriptive like in some of my posts since there is a difference between "disappearing" and being "cloaked" which some people may confuse (and believe it's the same thing).
Also, forgot to say but I'm glad you removed all Unused StarEdit tags like I suggested some time ago Looks much cleaner. but I will get back at a trivial request I had earlier, Add the movement flag names back for beautification's sake And maybe add the Mine-Safe property in the Advanced Props list, since it's the only one that actually does something, unlike the other "label"-type flags used for reference.
As for Orders, I haven't found any direct links to the code except for Unknown10... Which as I said is responsible for aiming and hitting (shooting even) over obstacles. I'll assume the others are "internal" like Unknown1 (Use Weapon Targeting) and trigger other effects.
Also, I think it's better if you remove the Restricts flags since they might be confusing.
And, last but not least, maybe either leave all "Unused Label" fields called as "Label" or all as "Unused" cos the one in Orders might again, confuse someone into thinking it might be related to the text you see in game or smth (small chances but you never know). Although honestly, I don't mind having the fields called as "Reference" instead of "Unused" or "Label" (since Label is mostly used as the in-game display text).
As for the TBL Editor, as many have said, it's a great feature to add and we'd welcome it, but it isn't something REALLY needed, so do it if you can and if ShadowFlare can help you make it efficient enough (speed wise) then all the better
Good job!
Question: Why are the weapon icons so messed up in DatED ? (Irradiate with EMP icon, Consume with Plague icon etc.)
Edit #1: almost forgot, and maybe add a RELOAD DEFAULT FOR CURRENT TAB option and RELOAD DEFAULTS to be used in all tabs, since it might be easier for some to click that instead of restarting DatED (or opening the defaults)
Edit #2: one other possible theory (which means DoA will hate me). I think "Produces Units" is actually something like "Has ground Exit" or something along these lines, since the only buildings that use them are the ones that need a lot of space to "create" (well training units is more or less like having a location in place of the building and running a Create Unit At Location" trigger with the wait being the queue time so to speak...) and need a lot of ground space. I didn't actually see any changes when selecting and deselecting (unless I was blind), but it seems a good explanation (which might not be used, much like the movement flags). (The bunker has it to unload/load units... I am unsure why transports don't have it but I'll assume that is because they're mobile - lift-off excluded in case of T buildings here). "Morph from other unit" seems more or less accurate as well, and "Pickup Item" as well.
If anyone would like to test more in depth it'd be good (but I doubt anyone else other than me and DoA and BK are in the mood atm)
ADDITION:
Oh and one more thing...
Since there might be some crazy modders out there (ok so I'm talking about me - big deal) that'd want mess around with unit behaviors, I suggest you split the Orders tab in 2, one being the usual Orders and the other being AI Scripts. As for their internal IDs, I think another textbox showing their IDs from the original list (since splitting them in 2 tabs will break their old IDs and make new ones) won't be much of a hassle.
The reason I was asking this is because if you remember I posted that ... let's call it "detailed order" list. It had both scripts/behaviors and orders. If someone would let's say put "Spider Mines" as the order for attacking because they'd think it will place mines (instead of doing it in MG or soon, in FG) the resulting crash will raise confusion and they wouldn't think that "Spider Mines" is actually the behavior script instead of the "place mine here" order.
... Plus I think it'd be easier in the dropdown in the Units AI tab since I hate going through all the orders to get to the script I want ( ... I AM NOT LAZY !!!!!!11111222222).
... just a thought While I am pretty sure not too many dare to mess with unit AIs... you never know (yes yes hint towards me ).
... speaking of AIs, I heard somewhere that the AI headers (well the format more specifically) kinda changed in the later versions and SC AI Edit might not work anymore. Is it true or an unconfirmed rumor ?
Typo in Weapons: Mojo has ANIT instead of ANTI Matter Missiles
As for Floats... I believe the description is way too vague and not helpful enough (which might scare people from using it as it is properly anyway). Try being a bit more descriptive like in some of my posts since there is a difference between "disappearing" and being "cloaked" which some people may confuse (and believe it's the same thing).
Also, forgot to say but I'm glad you removed all Unused StarEdit tags like I suggested some time ago
Looks much cleaner. but I will get back at a trivial request I had earlier, Add the movement flag names back for beautification's sake And maybe add the Mine-Safe property in the Advanced Props list, since it's the only one that actually does something, unlike the other "label"-type flags used for reference.As for Orders, I haven't found any direct links to the code except for Unknown10... Which as I said is responsible for aiming and hitting (shooting even) over obstacles. I'll assume the others are "internal" like Unknown1 (Use Weapon Targeting) and trigger other effects.
Also, I think it's better if you remove the Restricts flags since they might be confusing.
And, last but not least, maybe either leave all "Unused Label" fields called as "Label" or all as "Unused" cos the one in Orders might again, confuse someone into thinking it might be related to the text you see in game or smth (small chances but you never know). Although honestly, I don't mind having the fields called as "Reference" instead of "Unused" or "Label" (since Label is mostly used as the in-game display text).
As for the TBL Editor, as many have said, it's a great feature to add and we'd welcome it, but it isn't something REALLY needed, so do it if you can and if ShadowFlare can help you make it efficient enough (speed wise) then all the better
Good job!
Question: Why are the weapon icons so messed up in DatED ? (Irradiate with EMP icon, Consume with Plague icon etc.)
Edit #1: almost forgot, and maybe add a RELOAD DEFAULT FOR CURRENT TAB option and RELOAD DEFAULTS to be used in all tabs, since it might be easier for some to click that instead of restarting DatED
(or opening the defaults)Edit #2: one other possible theory (which means DoA will hate me). I think "Produces Units" is actually something like "Has ground Exit" or something along these lines, since the only buildings that use them are the ones that need a lot of space to "create" (well training units is more or less like having a location in place of the building and running a Create Unit At Location" trigger with the wait being the queue time so to speak...) and need a lot of ground space. I didn't actually see any changes when selecting and deselecting (unless I was blind), but it seems a good explanation (which might not be used, much like the movement flags). (The bunker has it to unload/load units... I am unsure why transports don't have it but I'll assume that is because they're mobile - lift-off excluded in case of T buildings here). "Morph from other unit" seems more or less accurate as well, and "Pickup Item" as well.
If anyone would like to test more in depth it'd be good (but I doubt anyone else other than me and DoA and BK are in the mood atm
)ADDITION:
Oh and one more thing...
Since there might be some crazy modders out there (ok so I'm talking about me - big deal
) that'd want mess around with unit behaviors, I suggest you split the Orders tab in 2, one being the usual Orders and the other being AI Scripts. As for their internal IDs, I think another textbox showing their IDs from the original list (since splitting them in 2 tabs will break their old IDs and make new ones) won't be much of a hassle.The reason I was asking this is because if you remember I posted that ... let's call it "detailed order" list. It had both scripts/behaviors and orders. If someone would let's say put "Spider Mines" as the order for attacking because they'd think it will place mines (instead of doing it in MG or soon, in FG) the resulting crash will raise confusion and they wouldn't think that "Spider Mines" is actually the behavior script instead of the "place mine here" order.
... Plus I think it'd be easier in the dropdown in the Units AI tab since I hate going through all the orders to get to the script I want ( ... I AM NOT LAZY !!!!!!11111222222).
... just a thought
While I am pretty sure not too many dare to mess with unit AIs... you never know (yes yes hint towards me ).... speaking of AIs, I heard somewhere that the AI headers (well the format more specifically) kinda changed in the later versions and SC AI Edit might not work anymore. Is it true or an unconfirmed rumor ?