Now version 3 with new features!

I am proud to present you the result of my activities: a custom version of Rezilla that will make plug-in editing easier (than with the base version) while replacing the old, can't-run-on-Intel-Macs, still 68k , ResEdit. You can grab it (EDIT: link removed, please use custom 3 now) (direct download link off my webspace) (last minute annoyance: do not try running it off the virtual disk, as Rezilla doesn't like being run off read-only media; copy it first to your hard drive).

I invite you to download it and edit plug-ins with it, this with two purposes. First, to evaluate it to make sure this can indeed be a valid replacement for ResEdit. I fact, you should try to remove ResEdit from your Dock and see if you can survive without it. So far, I have been able to. Second, to test the custom features I added, so that they can be beta-tested and safely added the the main Rezilla app.

These last days, following the release of Rezilla 1.0.8 (that fixes some annoying bugs, guess who found them, debugged them and proposed the fix), I set up to work on compiling it from source, then modifying it (since Rezilla is open source) to add to it some features that I had already (more or less) working on a modified version of Rezilla 1.0.7. Then I modified all the templates I had already converted to be Rezilla-friendly, to take advantage of these custom features, to fix a few things in them, to generally improve descriptions, and to prepare for potential future custom features (hint: RSID may very well not remain being a mere synonymous for DWRD).

However, it doesn't yet surpass NovaTools in ease of use, simply because Rezilla's plug-in architecture isn't ready yet, so I can't make anything like NT yet. It largely surpasses ResEdit with templates thanks to the power of WORV, CASE, and keyed sections; it also surpasses MC and EVONE for resources that do not have dedicaced editors in them, and sometimes surpasses graphical editors of all three for very specific points. Also, not all resources have templates updated to take advantage of the power of Rezilla (the ones that don't simply have the basic ResEdit TMPLs), but this should be corrected in the next few days.

In particular, I want you to make sure that:
- color pickers work perfect
- flag (and similar, such as seeker and asteroid type) popup menus work perfect
- and generally Rezilla works perfect
The first is a custom feature I added. The second, I modified it slightly.

Once we've made sure we can trust Rezilla, we will invest the time and computing skills to add graphical editors to Rezilla (once it will support plug-in editors). But first I need to make sure people are interested in and will use Rezilla, that I'm not sweating blood on code for no one bar me.

As this is a custom version of Rezilla, DO NOT mail the author (Bernard Desgraupes) about problems in this version, he barely knows about it in the first place. Please report everything to me, and I'll handle it. If there's a problem, that's probably a bug I introduced (or at least, we should assume it at first).

One last thing: Rezilla is licensed under the GNU General Public License. As such, I have been given access to the code, and the right to modify it, and this means I needs to give you the same rights. Therefore, you can find the source files for this custom version at (EDIT: link removed, please use custom 3 now), in case you're interested. Be careful. It's a mess.

Have fun!

EDIT: sigh. I don't like having to do so, it feels like little more than slick advertising. But I need feedback on this new version. Added a subtitle.

This post has been edited by Zacha Pedro : 26 June 2006 - 05:56 AM

Just tested it a little, seems to work well, at least during the little testing I performed.
Color pickers and flags seem to work perfectly, and Rezilla too.
Really great work.

This post has been edited by modesty_blaise_us : 25 February 2006 - 07:09 PM

This looks like it is going to be very useful. I still appreciate MCs tricks and niceties and NovaTools' see-all-fields-at-once dialog layouts, but when I don't want to wait for Classic to start up I expect I'll be turning to this gem whenever I want to compare two or more resources head-to-head.

Hmm. Most things look quite functional, but the "type of modification" fields in the outf resource seem to themselves be unmodifiable. The number and name of the modification type (Ammunition, Weapon, etc) are visible, but neither can be changed.

All the same, congrats & kudos to you, ZP!

This is great, ZP, you definitely aren't sweating blood for no reason. Any plans for the plug-in architecture?

Very cool. I'll definitely be using this along with MC.

Dr. Trowel, on Feb 25 2006, 04:26 PM, said:

Hmm. Most things look quite functional, but the "type of modification" fields in the outf resource seem to themselves be unmodifiable. The number and name of the modification type (Ammunition, Weapon, etc) are visible, but neither can be changed.View Post

That's one of the things ZP mentioned in the previous thread- there was a trade-off between having ModType-specific input options, and being able to change the ModTypes in the template, and he chose the former. It is possible to change the ModTypes through the use of a second template, so I've come up with a simple modification to the standard oütf TMPL, adding pop-up ModType menus (add the file to the Library/Application Support/Rezilla/Templates folder; the TMPL type is "oűtf" (o-option-i-u-t-f); use the "open resource as type" menu option to use it).

Anyway, I'll see how this new version works. My opinion of the standard 1.0.8 version isn't very high*, but we'll see.

*My main gripes are as follows: Tab doesn't switch between template fields, enter/return seldom triggers the apparently-selected button, "unused IDs" are just random numbers between 128 and 32767, and selections in the hex editor are best left unmentioned.

Edwards

Attached File(s)

• Alt_outfTMPL.bin.zip (1.13K)
  Number of downloads: 61

Dr. Trowel, on Feb 26 2006, 01:26 AM, said:

Hmm. Most things look quite functional, but the "type of modification" fields in the outf resource seem to themselves be unmodifiable. The number and name of the modification type (Ammunition, Weapon, etc) are visible, but neither can be changed.

All the same, congrats & kudos to you, ZP!
View Post

Yeah, you can only set them up when you create the oütf. Then it's fixed (probably because it would be a bit complicated for Rezilla to dynamically change the depending fields), unless you use an alternate template, as Edwards says. It is my plan to release such an alternate template along with the templates that remain to be Rezilla-optimised.

Guy, on Feb 26 2006, 02:32 AM, said:

This is great, ZP, you definitely aren't sweating blood for no reason. Any plans for the plug-in architecture?
View Post

I've not sweated blood on code yet (more on trying to get the damn thing to compile, debugging weird stuff, and writing the templates), my custom features take up around 50 lines of code, nothing spectacular. It's when I'll work on the editors that will use the plug-in architecture that it'll get complicated. Bernard says, in version 1.1.0. Right now, I don't have other info.

Edwards, on Feb 26 2006, 05:49 AM, said:

Anyway, I'll see how this new version works. My opinion of the standard 1.0.8 version isn't very high*, but we'll see.

*My main gripes are as follows: Tab doesn't switch between template fields, enter/return seldom triggers the apparently-selected button, "unused IDs" are just random numbers between 128 and 32767, and selections in the hex editor are best left unmentioned.

Edwards
View Post

Oh yeah, indeed.
- tab, I'll see what I can do about it. Perhaps I can solve it.
- enter/return (probably in the Get Info for resource dialog), I'll investigate it (in the template editor, then hit enter and not return, yeah I know it's weird, probably because return can be valid input in text fields). Also, I'll make sure the ID field has focus when invoking the Get Info dialog, because right now it is wholly selected but it is useless since the field doesn't have focus, so we have to click in it to get focus and reselect all (except at the first invocation of this dialog where is does have focus, yeah it's weird).
- Unique ID: yeah. I'll see what I can do about it. It's probably simply what the resource manager returns when asked for an unique resource ID.
- selections in the hex editor: it's the worst issue. Especially as I don't think I can do much about it, it probably depends on the WASTE text engine. I tried directly specifying the offsets of the selection bounds in the little field below, and this indeed selects what I want (or at least I think it does), but you cannot do anything with it since this little field keeps having focus so it is the subject of copy/paste/clear/text input! Perhaps I can try supporting this workaround, on the other hand (by having the focus go back to the hex when hitting return in the little field).
Of course, hexadecimal editing is not the thing we're supposed to do most when editing plugs. If you just wish to do massive copy/paste/clear, right now I use Rez/DeRez (command-line tools found in the dev tools) for that purpose.

Other gripes you'd like to share? We should make sure there is none, fixing these annoyances is as important as adding new features.

Zacha Pedro, on Feb 26 2006, 01:26 AM, said:

Other gripes you'd like to share? We should make sure there is none, fixing these annoyances is as important as adding new features.View Post

You've mentioned the only other major one I have so far- the default selection in the Resource Info window. A nice feature for that window would be either automatic confirmation of changes, or a confirmation dialog, when you close it, but that's minor if you get the selection and enter key working.

Hex editing was just a very annoying bit when I was setting up my modified oütf TMPL. If I ever need to do anything more serious, I'll find a better program.

----------
Now, on a completely different note, in following up on an implication in the Rezilla documentation, I decided to download and test a set of Resorcerer templates from the add-ons page. Most of them don't quite work (error of type 2016: "Not expected size" when you try to close the editor window), but they do give an interesting view of an extreme end of "annotated TMPL". They also show demonstrate checkbox-based flags, if you like that style (for a few flags, it's nice, but it can get unpleasant in large resources).

Edwards

Edwards, on Feb 26 2006, 10:20 PM, said:

You've mentioned the only other major one I have so far- the default selection in the Resource Info window. A nice feature for that window would be either automatic confirmation of changes, or a confirmation dialog, when you close it, but that's minor if you get the selection and enter key working.

Hex editing was just a very annoying bit when I was setting up my modified oütf TMPL. If I ever need to do anything more serious, I'll find a better program.

----------
Now, on a completely different note, in following up on an implication in the Rezilla documentation, I decided to download and test a set of Resorcerer templates from the add-ons page. Most of them don't quite work (error of type 2016: "Not expected size" when you try to close the editor window), but they do give an interesting view of an extreme end of "annotated TMPL". They also show demonstrate checkbox-based flags, if you like that style (for a few flags, it's nice, but it can get unpleasant in large resources).

Edwards
View Post

Yep, the first time I did oütf, to copy the work I had done so far four times, I actually used ResEdit's hex editor. I'm ashamed, yes. Now I use DeRez/Rez. Same thing for generating the oűtf from MY oütf: I used DeRez/Rez.

----------
What do you mean? These Resorcerer templates work fine for me, except the oütf one which is buggy (to begin with, we have two 43 in the CASE tags). And this is the kind of thing I don't like: templates should be just that: templates. They can (and should) have little reminders and lists of values, but they are not here to teach you how to do plug-ins. The same way, checkbox-based flags are possible (and have been since ResEdit, though ResEdit used a pair of radio buttons yes/no for each bit), but take up too much vertical space. Notice this style of templates suits more Resorcerer itself, whose template editor is MUCH more compact, especially on vertical space.

Oh yeah, I see what you mean now. That's on resource creation, isn't it? I was editing existing resources and changing them. The problem is, these templates use H010 (16 bytes of hex data) for the end, unused part of the resources, and when a resource is created (and hence starts at 0 size), no data is filled in the hex subpane at the end, and when you try to save it (rightly) complains there is not enough data in the hex subpane. That can be considered a Rezilla bug, though it is much better if F010 is used (as in my templates), makes much more sense.

In the govt voice type it says "Aurorean". Shouldn't it just be "Auroran"? In fact, I'm wondering if it would be better to not have any Nova-specific references at all.

Oops, you're right. And you're asking a very good question: should the templates contain references to the Nova scenario? I thought about it, and came with this rule: yes if people are unlikely to replace the part of the scenario referred to. For instance with voices, very few people will ever record and replace the Nova voices by their own. Even if some people will make TCs that will not use voices, it doesn't harm them if the voices menu lists the ones in Nova, since they will ignore the menu anyway. Same for asteroids in the s˙st resource.

Personally I'd like to have some customizability there. I had to hack my NovaTools to get around a lot of Nova-isms, such as how I'm using 16 different roid types instead of four with variations.

I just can't put customisability in templates, however they are easy to change if you're feeling like it (you can even put your modified version in the Templates folder and it will override my internal one). But I'll think about it when doing the custom NovaTools-like editors.

Some news...

Work is going along, I've fixed three annoyances:
- the algorithm for UniqueID is better, now it looks for the highest ID used for the type in the resource, then adds +1.
- the bug with Resorcerer templates that Edwards has been fixed (Hxxx not getting filled on resource creation), I still need to investigate the particular case of oütf, to see if this template is indeed buggy or Rezilla is.
- The hex editor (and hex panes in the template editor) didn't accept hex data pasted from HexEdit because it contains spaces and carriage returns, I've fixed that.

However, I said the last templates would be done by now. This is not the case. This is because one of the new tags used by my templates ('3COL') is being discussed, and way very well be dumped in favor of LCOL, but this has not been settled. So I can't release templates that would make use of 3COL since they would stop working with the next custom release but still float around and annoy everyone, and I can't release templates using LCOL instead since they wouldn't work with the current custom release, I need to make a new custom release that supports them first, and I need to fix a few more bugs before doing so, and other stuff I need to discuss with Bernard Desgraupes, since my custom features/bugfixes are to be integrated into Rezilla in the long run.

Well, I haven't used Rezilla much over the past few days, but I have found one fairly major bug:
The bitmap editor never changes its height, so when you are editing a 64x64 pixel ppat, you can neither see nor edit* the bottom ten rows of pixels.

*That's not quite true- if you click in the editing box and drag down, you can set these pixels, but I don't count that as "editable".

This is even more unfortunate because my ResEdit ppat editor has pretty much died- it can't work with pre-existing ppat resources (trying to save after editing them crashes the program, and trying to change their RIDs gives a "resource not found" error). Fortunately, copying and pasting a ppat gives me a chance to edit it (once), but that is a royal pain in the body-part-of-choice.

Anyway, I'm glad to see that the Unique ID has been fixed. "Highest-used-ID+1" isn't perfect, but it's a lot better than the current system.

----------
As for the templates, I must first say that I really dislike the "long column of fields" method of data entry. Specifically, I hate having things like shďp RIDs and probabilities several screens apart. Aqua's big, bubbly screen-eating interface style doesn't help matters either.

Would it be feasible to create a varient of the "RECT" TMPL tag, without the "top", "left", etc. labels? Simply put four 2-byte fields in a row across the template window? Using RECTs is more vertically efficient for sets of 8 or 16 identical fields than what you're using now, and it doesn't seem to have any unpleasant side-effects other than pointless labels (and that bit about the "top/left/width/height" preference).

-----
Now, for errors in the editors. Both of these are contradictions to the Bible, but I've tested them several times:
Your note on weapon armor damage is wrong- for some reason, all of my tests have shown that asteroids take shield damage, not armor damage. :huh:

Also, in the shďp resource, the "Ignore Gravity" and "Ignore Deadly Stellars" flags do not work at all as advertised. Flags3 0x0010 does absolutely nothing, while Flags3 0x0020 makes a ship immune to both gravity AND deadly stellars.

Edwards

Edwards, on Mar 6 2006, 07:27 PM, said:

"Highest-used-ID+1" isn't perfect, but it's a lot better than the current system.
View Post

Yeah, specifically when you have a Bounty Hunter or Escape Pod.

Edwards, on Mar 7 2006, 06:27 AM, said:

Well, I haven't used Rezilla much over the past few days, but I have found one fairly major bug:
The bitmap editor never changes its height, so when you are editing a 64x64 pixel ppat, you can neither see nor edit* the bottom ten rows of pixels.

*That's not quite true- if you click in the editing box and drag down, you can set these pixels, but I don't count that as "editable".

This is even more unfortunate because my ResEdit ppat editor has pretty much died- it can't work with pre-existing ppat resources (trying to save after editing them crashes the program, and trying to change their RIDs gives a "resource not found" error). Fortunately, copying and pasting a ppat gives me a chance to edit it (once), but that is a royal pain in the body-part-of-choice.
View Post

I'll report that to Bernard, this is completely outside of my competence. But you're right to report it (and report it to me - it might have been a bug I introduced), since this is one of the (essential for us) features of a general-purpose resource editor, which will be missing once ResEdit goes away.

Edwards, on Mar 7 2006, 06:27 AM, said:

Anyway, I'm glad to see that the Unique ID has been fixed. "Highest-used-ID+1" isn't perfect, but it's a lot better than the current system.
View Post

(to answer Guy as well): yeah, I thought about more complicated algorithms, but I wasn't convinced of the necessity or that they had any real benefit (not to mention the added complexity could have introduced bugs, though I check that the ID I find isn't actually used, Just In Case™). Especially, I thought about the special case of shďp, where the last allowed ID is reserved to the escape pod, and thought that if the user has a data file with an escape pod, then he knows what he is doing (for instance he can easily realise it and put the escape pod shďp in a separate file). I also dismissed any algorithm that would have relied on information other than that of the current file.

Edwards, on Mar 7 2006, 06:27 AM, said:

As for the templates, I must first say that I really dislike the "long column of fields" method of data entry. Specifically, I hate having things like shďp RIDs and probabilities several screens apart. Aqua's big, bubbly screen-eating interface style doesn't help matters either.

Would it be feasible to create a varient of the "RECT" TMPL tag, without the "top", "left", etc. labels? Simply put four 2-byte fields in a row across the template window? Using RECTs is more vertically efficient for sets of 8 or 16 identical fields than what you're using now, and it doesn't seem to have any unpleasant side-effects other than pointless labels (and that bit about the "top/left/width/height" preference).
View Post

Don't worry, I hate that as well. s˙st (but also düde) is particularly nasty in that regard, and especially you end up having trouble telling which probability goes with which ID. The thing is, it's one of the inherent limitations of template-based editing: you're bound to what the order of the data is in the resource. Personally, I don't like the use of RECT for that, it feels little more than a clever hack, what if tomorrow Rezilla decides that it refuses to save resources with invalid rectangles? RECT's semantics can change, as you've noticed (so far, I have kept RECTs, but not added any, I will probably disband some to be made RSIDs when this tag will have more features, and consequently disband the depending count and ammo count RECTs to have them have the same disposition as the RSIDs). As for adding a new template tag, I stay away from it as much as possible. Adding a new template tag isn't something to do on a whim. It binds the software into supporting these tags, not to mention the name issues and such. I added 3 LCOL and WCOL because there was no other way, but here there is another way using existing tags.

Indeed, I will try to improve the use of space, probably by having lists (at least fixed-count lists, for which there is no issue of adding/removing fields at runtime) with only one simple field inside the list have the label put once and then have four fields per row or something like that (perhaps numbered so that it is known whether they are set up left-to-right, then top-to-bottom, or the other way round).

This can have other benefits, such as allowing to have ScanMask and Contribute/Require as a matrix of checkboxes, simply by having a fixed list count of W/LBITs (however, it doesn't apply to flags who all need their own little description and hence would need more vertical space, and therefore are better packed in a W/LORV).

Edwards, on Mar 7 2006, 06:27 AM, said:

Now, for errors in the editors. Both of these are contradictions to the Bible, but I've tested them several times:
Your note on weapon armor damage is wrong- for some reason, all of my tests have shown that asteroids take shield damage, not armor damage. :huh:

Also, in the shďp resource, the "Ignore Gravity" and "Ignore Deadly Stellars" flags do not work at all as advertised. Flags3 0x0010 does absolutely nothing, while Flags3 0x0020 makes a ship immune to both gravity AND deadly stellars.

Edwards
View Post

You sure? In this case, these are (weird) bugs of the Bible (or the engine, depends on your viewpoint) that I've repeated. I'll correct the texts according to my own tests (no offense meant, but I'm paranoid).

A replacement for Resedit? Zacha, you rule :wub: :wub:

There goes 1 of my only 4 excuses to stay with PPC...

I should ask andrew to open me a progress log...

More annoyances have been corrected:
- Edwards, you will be pleased to know that I fixed all your gripes about the Resource Info window: the ID field has focus when it's opened, return does trigger the "Apply" button, and anyway the changes are applied automatically when you close it. Now you can massively modify IDs without having to lift your fingers off the keyboard! (something I have to do to transfer the templates from the base file, where they have ID 128+, to the internal Rezilla Templates file where I give them IDs 2000 and up).
- Also, Bernard confirmed and fixed the bug with the pattern editor (I'm waiting for his modified ppob resource for a taller window).
- I also fixed the bug with the Resorcerer oütf template (was actually a bug in Rezilla that only manifested itself under very specific circumstances)
- I made that the + key adds an item in the list, just as delete erases one, so that one does not have to go up and down the resource to get the + button. This is not of direct interest in editing Nova resources since none has a variable-length list, but for my (and possibly other's) own use when editing TMPLs.
- I also prevented deletion with the delete key of items of a fixed count list...

Also, after discussion with Bernard I definitely switched to LCOL. 3COL, if ever you knew about it, is to be dumped to the lowest level of computing hell and should be erased from your memories. I modified the templates to use LCOL, and in the process Rezilla-optimised the remaining templates, it ended up being done fast as these last ones are less complicated and especially have less flags, ironically the most time I spent while doing the templates was finding descriptive yet short enough names (so that it doesn't make a really large flag menu) for each and every individual flag; of course there is no such name in the ResEdit templates and the Bible doesn't really help.

However, it seems the limitation of selection of the hex editor is a quite hard one. Even if I modify the code so that the hex part of the hex editor has focus when entering a range in the bottom field, what's actually selected (and hence goes away with delete or is copied with copy) is only what is shown, what you see is indeed what you get. Also, the issue of tabbing in the template editor is not a simple one as fields get added/removed as list items are added/deleted, so they would need to be removed/inserted from the tabbing order, plus we have to stay in PP's model and be careful of what we're doing with the commander chain, etc... ; but I'll have a try at it for custom 3. The same way, the possibility of stuffing multiple fields in the same line will only be tried for that version. I'll also try doing something for that version that will put oűtf to the dumpster.... So these three actual new features (come on, so far I merely fixed bugs and annoyances, not made anything really new...) are not in the short term.

Anyway, I'll try to add the modifications for RSID and I'll call that a custom 2. Provided that I get Bernard's modified ppob resource for the pattern window, that I am able to package everything (no trivial thing), that I can get the documentation for WCOL and LCOL written, and that I make patches for my code modifications, in time, this may be ready for sunday evening. And don't think that different time zones will make that it will end up being sunday afternoon for you Americans, I may end up having to code so late in the night that it will effectively be the evening for you! (and as for you poor Australia/New Zealand/Japan people, it will in fact be Monday around noon...)