Niemand

Some of the icons still don't show up right for me either. Also, the open dialogs are still starting out in the Blades of Avernum (Universal) v1.2.app/Contents/MacOS folder. Does anyone else have this problem?

 

I am very happy, though, because the problem I had hated most is now gone: no more cpu time wastage. Thanks Jeff!

I'm afraid that this is probably not possible. There's no way to make BoA itself do much of anything, I could have the editor launch it, but nothing more; there's no conceivable way to make it load a party or a scenario.

Dahak: I really didn't change much. I made it so that when you scroll it doesn't waste time drawing the terrain buttons on the right side. That, and a couple of really minor tweaks that I've already forgotten the details of.

 

Ephesos: Right below the lines you found there should be a pair of stack traces. One should be labelled "Thread (0 or 1) Crashed" can you get me the numbered lines directly below that one?

Ok, so I've sent the three of you the newest version.

 

Kelandon: My computer is a 1.33 GHz G4 powerbook with 2 GB of RAM, but I also test everything on another computer, which is a 600 MHz G3 iMac with 384 MB of RAM. Both run 10.3.9.

 

Ephesos: I can't imagine why it's crashing on you. The problem it has cannot be the same as you were having with Graphic Adjuster since both Kelandon and Dahak have gotten it to run. Maybe to new version will fix things. I sure hope. Are you still using OS 10.2 or something? That shouldn't be a problem, but who knows. Also, could you check you crash logs to see if there's any information there? Try using Console to see if there's anything in "3D Blades of Avernum Editor.crash.log" under CrashReporter under ~/Library/Logs, and let me know what you find.

 

EDIT: Gah, why an I so slow to write posts? Somebody always gets in and post before I finish. . . Anyway, yes, i think it would be possible to make the height labels display in all modes.

I keep telling you, I didn't change that code! It's the same as it has been. In fact, I can hardly tell a difference between the two. However, I'll see what I can do to speed it up.

 

EDIT: So i've optimized the redrawing done when scrolling to a reasonable degree. Scrolling from one side of the Breeding Pit in Exodus now takes 3.40 seconds, while the original 3D editor takes 3.56 seconds. The difference isn't really significant, of course, but now the new editor is faster than the old. I can send you the newest version if you like, or we could wait until more changes have been accumulated.

Oops, that's not what I meant. I mean that that mode does more drawing and graphics manipulation than the other modes. For instance, calculating the locations of and then drawing all of the grid and rectangle lines in 3D. I may be able to improve things a bit, though, because it appears that when scrolling the editor unnecessarily redraws the entire window instead of just that section.

I agree, and I'll fix this.

Yeah, the slow view scrolling in 3D mode is annoying. I'll see if I can make any improvements, but I doubt it, there's a lot of stuff that has to be drawn on the screen and drawing is pretty much always slow. The fact that the editor depends on ancient Quickdraw doesn't help. I've found that the editor is a lot snappier when Blades of Avernum itself isn't running. It might have something to do with both of them using the same resource files or something, or it might just be the way the game hogs cpu time.

 

Dahak: Broken how? By my figuring, the button you're referring to is the auto hills toggle button, which works perfectly for me. It only shows that it's done something if you're in height editing mode though. I didn't alter any of this functionality from the way it was when I started.

 

Kelandon: Yes, I remember this issue. A quick check shows the game's view area to be ~500 by ~415 pixels, and the editor's to be ~460 by 460. Kernel Knowledge's dismissal of the possibility that this could be changed aside, I think it could be fixed. At one point I actually had a bug where the code that drew the tool buttons was having an overflow that made the editing view only a hundred pixels wide. So, I'm sure it can be done. I'll just have to dig into the code for the scroll buttons and main drawing to see if I can make it work right. Also, if possible I would like to make the view user resizable or at least have two different sizes. When checking what the player will see it's good to have a window the same size as the game uses, but when doing many editing tasks you want as large a view as possible.

Those of you who were interested: I've sent you an email with the latest version. And Kelandon, your wish is my command. (I think) I've made the reload function reload the graphics library as well as the data script, so hopefully it'll do what you were looking for.

Happily, the existing Reload Scenario Script command already does this.

 

As a reminder, are there any Mac users who would test this new version out for me? I really need to know if the undo system is robust enough to stand up to significant amounts of normal editing, and I don't have enough time test it under realistic conditions (doing serious work on a scenario) myself.

i can only conclude that the newest availible source code is newer than the newest availible build, because it works in every version I have on my computer, all of which are derived from the code at Sourceforge. Point is, in the version I've got, it works. I will happily send you a copy so that you can try it for yourself.

Like I said before, it does already! However, a quick search of my BoA folder locates only 16 terrains and 1 floor which were defined using ed_icon_adjust (in the basic game files and 25 scenarios). So, it's convenient to be able to view terrains and floors with their simplistic adjusts instead of having to rewrite all of their definitions.

I did. (I called it Kelandon's Strict 2D Icon Adjusts, to be precise). And if anyone asks, you made me do it!

Ok, compromise: I'll give you a toggle-able option to turn off the additional adjusting behavior. You can turn it off and leave it off, and I will turn it on and leave it on, because I can't stand not being able to tell what I'm seeing in 2D mode. I'm assuming that, though it was included in the quote, adjusting the graphics of creatures and items in 2D mode is not being called a bad idea.

And it will take some will power not to name the new menu item "Kelandon's 2D Icon Adjust Toggle".

Apologies for this being a double post, but I wanted to make it clear that there's something new here:

 

I believe that the time has come to beta test the new Mac version of the editor, so i could use a few volunteers. Names and email addresses would be logical, and knowing which OS version you plan to test it under would be nice.

 

Lastly, the final feature I've worked on is fixing icon adjusts in 2D mode. It turns out that the editor already did use te/fl_ed_icon_adjust, just hardly anyone was bothering to use these properties. So, what the editor now does is if a floor or terrain has no ed_icon_adjust but does have an ordinary icon_adjust, the ordinary adjust is shown in 2D mode. This fixed the appearance of blue carpet, for instance. Also, items and creatures are now adjusted when displayed in 2D mode.

Fear not! I'm aiming to begin a Mac beta test later this week.

As features go, I realized just how much I could do with a list of zone names. As a result, I've torn apart and rebuilt the import system so that now the user can see a list of the names of zones in the source scenario to alleviate having to guess numbers blindly. Also, importing a town now prompts for a file, then a town number, rather than the other way around. I think that I've been able to relax the restriction on importing a town only over one of the same size, but I will need the help of testers to determine if I really got it right.

Way ahead of you *i. I've got a menu item that toggles the sounds on and off, and stores the setting in the preferences. I've also fixed it so that the cursor starts out at the end of the text field in dialogs, and the script a placed creature will use is shown, even if it's the default script for that creature type.

Right now I'm trying to make the 'load different town' and 'load different outdoor section' dialogs allow the user to select the zone from a list showing the towns' or sections' names. After that I want to try to get graphic adjusts working in all viewing modes, and try to make the scroll bar on the right side respond to scroll wheel input.

(Bump)

So I now have the copy and paste functions working, including the choices to paste any combination of the copied rectangle's floors, terrains, and heights. (That is, you can paste just the floor, or just the terrains and heights, etc.) i've also fixed the bug where the editor would try to treat some floors as signs.

 

I'm also making good progress on a feature that I had hoped to add, but hadn't wanted to get people's hopes up about in case I couldn't do it. It appears I can do it, and that feature is: unlimited undo and redo for drawing operations! So far it works with the pencil, paintbrush, paint-bucket, spray-can and rectangle drawing tools, and before long it should work with all of the others and heights as well. No more having to reopen the .bas file to get rid of a change you didn't want to make!

 

Also, once I'm back at school in another week or so I can begin work on updating the windows version as well.

Oh, you mean this is a bug that should be removed, not a feature you want added! My apologies. I think I can fix it.

So I have the eyedropper and paint-bucket tools working now. Next I need to put into action my plan to fit in more buttons. One question: what kind of icon for the copy and paste buttons would make sense?

 

Lastly, I agree with *i and others who have said similar things that an IDE type program would be a big improvement over the system we have now. I've been thinking a bit about this, and I think I might be able to make a good attempt at such a thing, but not right now. One problem is that The 3D Editor is Carbon-C++, Dialogue Editor is pure Java, Alint is Cocoa-C++ (if I remember right), Graphic Adjuster is Carbon-C, and so on. They would basically all have to be recreated in a single application, particularly since Carbon is. . . not so good. Maybe next summer when I have some more time I'll give it a try. For now, I just want to patch up the existing 3D editor to max-out its potential.

So here are the revamped button arrangements as I've though of them so far.

 

There is a limit to how many blocked spaces can be placed using that tool. If you need a lot of blocked spaces, you really should use a blocked floor.

To the best of my knowledge there re no fl_ed_icon_adjust and te_ed_icon_adjust attributes. I am however, trying to figure out how to make the editor correctly display icon adjusts in 2D mode.

This isn't something the editor handles. Leaving a creature set to use its default script means that when you play the game it will use whatever default script is set for it in [scenario]data.txt. The editor just doesn't bother to check and display which script this is.

A floor cannot be a sign. Besides, there isn't a one-to-one correspondence between floors and terrains; there can be 512 terrains but only 256 floors.

 

I have had something a bit like this in mind; my idea was to make a system a bit like Javadoc or similar where the writer of a script places specially formatted comments at the beginning of the file, and the editor would read these so that in the 'Edit This Creature' dialog it could display a snippet about what the script does and what each memory cell is for. This would be a lot of work to make though, so I won't be attempting it just yet.

 

Lastly, I want to point out that I can only recompile and readily alter the Mac Editor. I will keep track of what I do though so that the same can be done with the Windows Editor.

In that case, I think that I may need to undertake the slightly more ambitious project of reshuffling the existing buttons and finding room for some new ones. As it is some of the arrangement has gotten a bit mixed up anyway (the zoom/realistic view button and the 2D-3D button really ought to be togetherand so on), and I think I may have thought of a way to fit in space for six more buttons now that I look at it. That would give us a bit of room to grow into.

*i's eyedropper tool should be quite easy to implement, and that would then leave ~4 free button spaces. Any other ideas for things we could really use?

I've been tinkering a bit with the code to the 3D Editor, and I was wondering, does anyone else ever really make much use of the fill rectangle and fill hollow rectangle functions? I realized that I don't, so in my own copy of the editor I've overwritten them with rectangle copy and paste functions, which I know are something that a lot of people have wanted.

This isn't such a big problem (at least in the case of BoA; I know nothing about BoE), although it might help. If one wants to one can use the existing editor code to find out how the scenario file should be assembled. On the other hand, it might be good to have an actual specificatio, rather than a piece of existing code that must be reverse engineered. All of the other files, aside from the mac .cmg file are plain ASCII.

I know. I just don't know what to do about it. . . perhaps I shall place stern admonishments in the readme file that the .jar file is to be double clicked.

The version of Dialogue Editor for Windows is finally ready. Also, in light of refinements I thought of while making it, there is also an updated mac version. You can find them both at my web site. many thanks to the windows users who tested the new program for me!

Graphic Adjuster

Utility