Our tools aren't perfect. They never will be. But, chance permitting, we can still consider improvements.

DatEdit 1.5d

Largely, very useful, almost bug free.
Major problems: Open directory interfaces, both new and old, are sorely outdated and unwieldy.
Open directory will sometimes fail when loading flingy.dat or spritr.dat -- I forgot which exactly. Usually stable.
A lot of the reference dropdowns to other techs, orders, animation, etc. could have id fields as well for easier editing but don't.
Lots of customizability for specific projects is great (selecting mpq to load grps, selecting tbl files, etc.) but the program has no "load/save project" feature making switching contexts difficult.
Open source but requires Borland compiler and VCL, which is proprietary and offers no guarantee of easy editing.
http://www.staredit.net/topic/16119/ -> Coerces weapon ranges to multiples of 16.

Solutions

For the project problem, Datedit directory can simply be copied, such that reach modding project has a respective DatEdit with settings customized for three project. Band-aid solution that multiple a few MB per project.
Get BCB6 compiler and fix existing open directory bug.
Rewrite all Borland-specific code, which seems to only be involved in the interface. That is, use Qt or some other open-source or well-supported, accessible, stable interface writing framework.

---

PyDat

Open directory seems to be completely broken.
Setting other tbl files to load appears to be broken.
Not thoroughly tested, and PyMS seems to have bugs scattered throughout in general.
Although easily edited and open source, commenting is sparse.

Solutions

Go through and fix bugs.

---

I'm tempted to fix either one of these programs, but both, even when it comes to editing, would require a lot of effort to read through.

does anyone else have anything to report?

Post has been edited 2 time(s), last time on Mar 4 2015, 9:32 pm by Sand Wraith.

More generally: really need to have all the big programs stored in SEN DLDB, links on sites without activity risk flashing out of existence.

I typod the thread title lol. You raise a good point though. I should take the time to upload some of the things I have. Many sites have died already making knowledge harder and harder to keep, one amongst them being Modcrafter's wiki disappearing.

We just need to contact Hercanic, it's happened before ... I think he's on like TL or some other SC-related site.

I think fixing pyMS issues in general, not only pyDAT would be an good idea. My usage experience with them is full of crashes, file corruptions and scary errors, but pyTBL, pyLO, pyFNT and pyPCX are still best tools there are for those files. They all (or at least most of them?) also have command-line interface which seems to be more stable.

The datedit issue of freezing while loading directory has happened to me only once, and otherwise it is a really solid tool. The fact that it requires borland compiler to build is a shame Otherwise I doubt the freeze would be hard to fix.

Most of the modding tools are really good though, most of the improvements I can think are preview features and better documentation on when stuff crashes and when it does not.

Only tileset editing is really horrible D: Though I don't have ideas how to improve it either...

Out of the ones I have used, pyTBL, pyDAT, pyTile, and pyICE: only pyTBL has been the most stable.

PyTile has a weird bug in which the data of the currently selected mini-tile? Megatile? will paste over the data of the next tile the user selects. I forgot exactly what the bug, but it was something really detrimental to editing that I found while attempting to make all water tiles ground-walkable.

Doesn't help that the interface is very inflexbile.

I would love to fix up PyMS. The problem I had with it was that I spent all my time working on the programs with no time left over to test them in actual usage (I obviously tested them as I built them but its not the same as real usage). The most stable programs in PyMS are the simplest (PyTBL), and the ones that got used the most by other people that reported issues (PyAI). If all the programs had been used as much as PyAI during the prime of PyMS development, things would have been a lot better. So that being said, if people start putting together issues I would love to work on it some more.

Herc is on CampaignCreations, I believe, if you want to try and reach him there.

If you have motivation to work on it, customising mpqs is completely broken on every tool that uses it. Changes won't save and if tools can't find the sc directory for the default mpqs, they can't read them at all. Even better, opening the mpq list on pyDAT, reordering single mpq, and exiting causes the following error:

PyMS could also have safer saving by writing a temp file first, and then moving it to actual destination path. PyTBL has only crashed on me once, but that was during saving, causing my tbl get wiped :l Though it was older version and the crash might have been fixed.

Or maybe I should post this and/or any future issues I have to the BWAI forums?

I'm not going to lie, it's probably better to put this on BWAI forums, although I don't frequent there much these days.

I believe I have fixed this issue.

This was already fixed in my copy.

Makes sense, will do.

That is fine with me, I check both sites fairly regularly, so whatever you want.


If anyone would like to keep up to date with my changes/fixes, I've created a public github repo here:
https://github.com/poiuyqwert/PyMS

Should be fixed now.

Are you sure about this? I think the confusion comes from the "Use custom labels" setting at the bottom of TBL Settings not being enabled. Without enabling that option PyDAT will use unit names from its own data files, which are "prettier" and give a little more context. There was an issue where the "Used by:" lists would not respect the "Use custom labels" option so I have fixed that. If these things don't clear up your issue could you explain the problem a little more?

stat_txt.tbl by default has 1547 entries (or thereabouts). Referencing lines with numbers above 1547 is possible in some tabs in the pyDat but generally impossible and it uses the number of lines from the selected stat_txt.tbl.

Alright I've completed this feature, though every program and every file has not been thoroughly tested, I believe it should be stable.

Ah I see, I wasn't even thinking about the dropdowns. I'll look into it.

Few more issues:

PyGRP:
-PyGRP does not allow importing 256-pixel wide frames. (Even though it can export them correctly)
-Using arrow keys browses through frames really strangely.. Seems only to happen once the frame list has been clicked with mouse.
-Could the window be resizeable? Palette list show only 4 palettes at once and it is really uncomfortable with lots of palettes.

PyDAT:
-PyDAT asks always if I want to save changes when opening something, even if the file was not modified. It gets really annoying with open directory.
-ID jump does not allow hex numbers and it could accept enter for jumping to ID.
-Does using custom images.tbl work at all? Settings use rez\images.tbl by default which does not even exist and overriding it to custom file does not appear to work, at least not if it adds new entries.
-There are import/export scripts buttons... Are they just accidentally copied from other tools or do they have some use? Clicking on export scripts causes an error.

Fixed.

Should be much better now.

Are you really changing palettes that often? I don't really want to change this, but if its that important i'll see what I can do.

Yeah I know what you mean, i'm going to fix this.

Why would it accept hex numbers? I've added the Enter button binding.

There are a lot of issues around custom tbl files and the "Use custom labels" settings. I'm looking into it but its a bigger change than most.

These are for export/importing dat files to/from TXT files. I've fixed the export option.

Thanks for the feedback

Thanks for a quick update

Guess it's not that big annoyance, I just decompiled lots of grps yesterday, most of which were either special palettes or menu grps. But I doubt I'll have to do that ever again now that I have them as .bmps

DatEdit accepts hex as well I've been using it a lot when examining bw's code as there are lots of hardcoded constants, especially when working with orders. It's not a huge deal though, I can just keep using Datedit for that.

Really? I had no idea. How does DatEdit handle it? I'm assuming it needs to be in the form 0x#? Is it just the ID Jump field that accepts hex or any entry?

Yes, prefixing 0x in id jump field parses it as hex. And no, I don't think it can be used elsewhere.

I've done a lot of updates in this area, though its hard for me to do real testing so please keep the reports coming if there are issues or missed fields.

Alright I added this.

Alright I've updated PyDAT to keep an edited state for each dat file, feels much better now.

Post has been edited 2 time(s), last time on Mar 17 2015, 10:07 pm by poiuy_qwert.