New Windows 3D Editor

[Ishad Nha]

The problem was "permission denied", possibly I already had the editor open at the time. (I have several editors kicking around the PC). It has compiled properly this morning.

As for who uses the scenario data function, I don't know. My goal is to create a lot of query functions that are available if designers want to use them.

Edit:

Editor now includes a list of all outdoor zone and town names. It also lists all outdoor town entrances.

 

[nikki.]

I use them if I have a lot of custom terrain that uses the same editor graphic (because sometimes, the zoomed out view is better for drawing terrain).

[Ishad Nha]

I have updated the editor to include a new town report function that lists all fields, placed specials and items in the current town.

 

Also there is a new Clear All Preset Fields function that I will split into a pair of Clear All Fields and Clear All Stains functions. (Clear All Preset Fields currently clears out all fields and stains found on the fifth and sixth lines of the editor editing buttons palette.)

 

Edit:

A few problems with dialog boxes were fixed up, stray "OKs"&. The two functions have been separated.

[Ishad Nha]

The numbers displayed when in Height mode can be used to show the numbers for floor types, terrain types, terrain scripts and placed specials.

 

From line 3,139 of Graphics.cpp:

if (current_drawing_mode == 2) {

sprintf(str,"%d",(int)height_to_draw);

// ((editing_town) ? t_d.height[loc_drawn.x][loc_drawn.y] : current_terrain.height[loc_drawn.x][loc_drawn.y]);

to_rect = large_edit_ter_rects[q][r];

OffsetRect(&to_rect,3,14);

to_rect.left = to_rect.right - ((strlen(str) > 1) ? 23 : 14);

win_draw_string_outline(main_dc5,to_rect,str,2,10);

}

[Niemand]

I assume that you mean 2D Height mode. The Mac version has a setting which displays the height numbers in other modes so that it's easier to place terrains and floors to match the heights. I would recommend against using these numbers to display information other than the height, as there isn't a good way to indicate what information they are showing, so it will be confusing to users if they can mean more than one thing.

[Ishad Nha]

There is space at the lower left, you can print "Numerical Display mode = floors" or whatever. I have already implemented it on my version and don't find it in any way confusing, even without the information display you can easily tell whether it is floors, terrain or height.

(Hint: terrain mode has a whole lot of zeros, display of numbers in height mode is usually contoured just like a contour map...)

I hope to extend it to showing terrain script numbers, state numbers of placed specials and so forth.

 

Edit:

I have uploaded a version which has four modes: floor, terrain, height and (blank). The lower left area shows "Numerical Display Mode = #" The function is called Rotate Numerical Mode and is currently found in the Help menu, its shortcut is Ctrl + W.

[Celtic Minstrel]

...Why on earth is it in the Help Menu, and why on earth is the shortcut Ctrl + W? That shortcut implies "close window".

[Niemand]

I am strongly against this 'feature'. At the very least you need to collect the opinions of a significant number of users, that is, Windows BoA designers, as to whether something that they do or don't want.

 

In connection with that, my personal opinion is that, as a user of the program, I do not want this feature and certainly don't want it assigned to such a misleading keyboard shortcut.

[Ishad Nha]

I am running out of shortcut keys after all, currently available are: G,H,I,J,K,M,P,U. Anyway, the usual meaning of Ctrl + W is irrelevant when there is only one window, it is only meaningful when you can have two or more windows (here Bas files) open at once.

 

The Help menu will become an Information menu handling queries and data of all sorts.

 

If this does not appeal to Niemand I won't upload it to the repository. Allow others to test it and see if they want it in the mainstrean editor. It is useful if you have several objects handled by the same editor icon.

[Kelandon]

The Help menu is not normally used for that sort of thing. Maybe you could make another menu or something. Also, an arbitrary keyboard shortcut seems better than a counter-intuitive one.

[Lilith]

Originally Posted By: Ishad Nha

I am running out of shortcut keys after all, currently available are: G,H,I,J,K,M,P,U. Anyway, the usual meaning of Ctrl + W is irrelevant when there is only one window, it is only meaningful when you can have two or more windows (here Bas files) open at once.

Some programs with only one window use Ctrl-W as an alternative shortcut for Quit, so it's still not good practice to use it for something else.

[Ishad Nha]

Ctrl+Q is currently used for Quit so there is duplication there.

I will use Ctrl+G for moving forward through the list of options and Ctrl+H for moving backwards. The numbers can be turned off for everything except heights. Options are: 0 = floor, 1 = terrain, 2 = height and 3 = height numbers only. A new version has been uploaded.

 

Now if I can get the code to work in practice for the numbers of the terrain scripts...

[Ishad Nha]

If you zoom out you lose information about what town or outdoor zone you are in. I have added the relevant numbers to the middle line on the right hand side, the Automatic Hills ON/OFF line. Currently this line is only used in Height mode, and when you are zoomed out the height is not so relevant anyway.

 

I have also added a slideshow mode that automatically loads the next town or outdoor zone. So you can view one town or zone after another. I don't know if people want this or not...

[Enraged Slith]

I wouldn't worry about it because at this point, everything is just gravy, incredibly awesome gravy.

[Ishad Nha]

My approach is to stick in a whole lot of features and see if anything stands the test of time and gains acceptance.

[Ishad Nha]

Hintbook mode: turns off the gridlines when the view is zoomed out and also removes the colored rectangles that show where creatures are. This could be expanded into a four way choice of show both, show grids only, show creature squares only or show neither.

 

Gridlines are based upon 0 mod 10 and 5 mod 10, more relevant choices would be 0 mod 8 and 4 mod 8 respectively. The relevant lines are 3,602 and 3,623 of Graphics.cpp.

[Celtic Minstrel]

The gridlines aren't terribly useful when zoomed out; maybe they should be omitted entirely?

 

Or something. I dunno...

[Kelandon]

I like the idea of four-way options. I do like gridlines when zoomed out sometimes.

[Niemand]

On the contrary, I depend on them (the gridlines) to paint towns quickly in the zoomed out mode. I can lay down large areas of floors and see the whole town layout as I do so, then zoom in and put in the terrain. I think that the current distinction between hintbook and non hintbook mode is great, just poorly documented. (I only discovered it when I began working on the source code.) However, switching to grid spacings which are powers of two is a good idea; it would make the grid much more intuitive to use. I will see about making the change on the Mac side.

 

Edit: I agree that that being able to choose all of the combinations of (gridlines | no gridlines) ╳ (markers | no markers) would also be useful. In order to support it, however, I think we will need to consider the user interface for it. (Making the user press keys with no indication of which keys to press, or what they do is far from ideal.)

[Kelandon]

Originally Posted By: Niemand

(Making the user press keys with no indication of which keys to press, or what they do is far from ideal.)

You could, like, write documentation or something.

[Ishad Nha]

I could create a dialog, in the meantime the upload includes a revised readme file that contains the hotkey assignments.

Edit:

One approach is to have an easily memorized scheme of hotkeys. Say A thru H for line 1 of the terrain editing palette, I thru P for the second row and Q thru X for the third row. Now not all of these buttons would strongly need hotkeys, this would leave M,N,O,P free for starters. Along with Y,Z.

 

[Ishad Nha]

As for the editor, I have created a load previous town/outdoor zone function. If editing a town, Ctrl + J loads the previous town while Ctrl + K loads the next town. If currently editing an outdoor zone, Ctrl + J loads the previous zone while Ctrl + K loads the next zone.

Ctrl + I has been added as a hotkey for zoom out/zoom in.

[Celtic Minstrel]

Creating a dialog for the Mac version, though, requires either ResEdit or Resourcerer. I don't think any of the free Mac resource editors support editing dialogs.

[Niemand]

I can't say that I think the previous/next zone key bindings are a good idea. For towns, maybe, although I think I personally wouldn't want it, since when switching towns I'm rarely going to one of the adjacent ones. For outdoor sections this makes no sense at all, since it moves you one dimensionally through the two dimensional grid. Yes, you can reach any section eventually, but it's neither efficient nor intuitive. Some of this problem is also addressed by the new zone picker which shows towns/outdoor sections by name, which I still haven't had time to get put into the Windows version.

 

A key for zoom in/zoom out is important, and though I could have sworn we already had one, looking at the code indicates that we didn't. I think that it's important that this key should also toggle realistic mode on and off in 3D mode. As to the choice of key to bind this function to, I'd like to recommend that we us '`' instead. This function is important and frequently used so it should be both easy to use and placed close to the related function, switch between 2D and 3D mode, which is already bound to tab.

 

@Kelandon: Yes, I know that I/we ought to write documentation, but do you want to guess how high that is on my to-do list, what with the 3 scenarios and 5 programming projects related to BoA that I've already given myself to work on?

 

EDIT: Indeed, Celtic minstrel is right, adding dialogues is one of the biggest stumbling blocks in working with the Macintosh code. I have ResEdit, but can't run it because it was compiled for both the wrong OS and wrong processor architecture an so requires one more level of emulation than I currently have available. Rezilla can help, but it doesn't do a very good job, unfortunately. If you're curious, see here for a description of what I've had to do to add new menus. Dialogs aren't quite as bad (they can be handled somewhat by Rezilla), but they're still a serious undertaking.

[Celtic Minstrel]

Originally Posted By: Niemand

For outdoor sections this makes no sense at all, since it moves you one dimensionally through the two dimensional grid.

Isn't this already possible simply by scrolling off the edge of an outdoor section?

Originally Posted By: Niemand

Rezilla can help, but it doesn't do a very good job, unfortunately. If you're curious, see here for a description of what I've had to do to add new menus. Dialogs aren't quite as bad (they can be handled somewhat by Rezilla), but they're still a serious undertaking.

I'm pretty sure I've used Rezilla to edit MENU resources. And I'm pretty sure there's a way to insert a menuitem.

Even if there isn't, I think the MENU resource is quite possible to intuitively edit with the template editor. The DITL resources aren't, since they deal with a 2-dimensional space. It would be doable – I think Rezilla does have a template for DITL – but it would be hard to see what the finished result looks like without actually compiling and running the associated program.

[Niemand]

Rezilla can edit MENU resources, but as stated, I can't find the way to get it to append a new menu item. Maybe I'm just blind, as there is evidience to the effect; see the next point:

 

My gut feling was right; the editor already has a key to toggle zoom in 2D mode and realistic rendering in 3D mode, namely ⌥Tab in the Mac version and Control Tab in the windows version. Lack of documentation: 1, Niemand: 0.

 

EDIT: That mess in the Mac keyboard shortcut mentioned above is an Option symbol. UBB apparently has issues with displaying Unicode.

[Celtic Minstrel]

Well, there are + and - buttons on the bottom of the right half of the editing window. It seems they don't work properly, but provided a valid menuitem is selected it seems to work fine.

 

Alternatively, you could edit using the Template Editor instead – they seem to be functionally almost identical. The only advantages I can see of the dedicated Menu editor are that it a) displays the menu and it automatically creates associated 'xmnu' resources if necessary.

[Ishad Nha]

Windows key assignments are mostly covered in edfcns.cpp. Reading the source tells you what is really going on, errors in documentation won't cause you any problems.

Tab is 2D/3D accelerator key. In 2D mode Ctrl + Tab is zoom out/zoom in, while in 3D mode it toggles realistic mode. We can add '`' here it is easy enough as there is currently no use made of any of the brackets, commas and whatever.

Unlike the current crossover into the next zone, the Prev/Next options work even when you are zoomed out. Ctrl + key bindings, have I,J,K handling similar sorts of things. Thus you can keep the left hand on the Control key while using the I,J,K keys with your right hand.

I will be sticking to a purely Windows project, if the dialog set up is anything to go by, cross-platform is not much good. In BoE the purely Windows project is making good progress while the cross-platform variety, oboe, is going nowhere fast.

 

[Niemand]

No, I don't think that '`' is needed, that was merely my suggestion based on the fact that I thought we were adding a totally new key. Since we're not, it's a moot point; let's just stick to what we already have.

 

The point about difficulty (although not impossibility) of adding dialogs in the Mac version is that it means it's a lot of work for me to keep up if you decide to make significant changes to the Windows version in that regard, since I think it's for the best to keep both platforms reasonably identical.

[Ishad Nha]

As for an easier to memorize assignment of hotkeys, I am using A thru H for the top line of the terrain editing palette, I thru L for the first four buttons on the next line and Q thru X for the third line. Y goes to the first button on the fourth line. M will remain for the Hintbook mode, Z will be used for the Place Terrain Script.

N,O,P will be kept for Cut, Copy and Paste of selected objects. [ will be another zoom out/zoom in for the time when Caps Lock is not on, ditto ] will be for 2D/3D mode.

[Celtic Minstrel]

That doesn't sound easy to remember at all.

[Kelandon]

Could you just make customizable hotkeys?

[Dintiradan]

Mod parent up.

[Niemand]

@Kelandon: That should actually be doable. The significant real work would be in providing a user interface to set key bindings and choosing where to store the resulting data. On the Mac the answer to the latter is obvious: use CFPreferences to store them and let the OS take care of the details. I don't know what equivalent, if any, exists on Windows, but I could easily write a reader and writer for a simple key bindings file format of our own if it comes down to that.

 

With regard to a user interface: The basic idea I have in mind is a dialog with a list of tool and function names, each followed by the current keybinding, displayed as a non-editable string (see footnote), and a button labeled 'Choose'. When the user clicks the button, we catch the next keystroke and store that as the binding, with any additional logic we want (delete should clear a binding, and we should reject attempts to set a binding to include the Command modifier on Macs and Control on Windows, since those are used for menu bindings, which we cannot as easily alter at run-time.). The only major issue that I can envision with this is that the list of tools is fairly long, so the list in the dialog window really ought to be scrollable, which Jeff's dialog engine does not currently support. I think I could add support for scrollbars on the Mac side, but it would be painful and I might not succeed. The Windows side would then be a step harder since I'm far less familiar with the widget library and event handling in use there, but we could hopefully still do it.

 

@Dinti: I have no notion what you are on about.

 

Footnote: The reason not to use an editable text field is primarily that one of our most important bindings uses the Tab kay. Not only can a user not enter a tab into most un-customized single line text fields, but it also can't be displayed in a non-confusing way. Space is a lesser example, and possibly Return is another, although it is currently unused.

[Celtic Minstrel]

Originally Posted By: Niemand

I don't know what equivalent, if any, exists on Windows, but I could easily write a reader and writer for a simple key bindings file format of our own if it comes down to that.

Does the registry qualify? Or just write them to the existing preferences file, whatever that is.

Originally Posted By: Niemand

The only major issue that I can envision with this is that the list of tools is fairly long, so the list in the dialog window really ought to be scrollable, which Jeff's dialog engine does not currently support. I think I could add support for scrollbars on the Mac side, but it would be painful and I might not succeed. The Windows side would then be a step harder since I'm far less familiar with the widget library and event handling in use there, but we could hopefully still do it.

Doesn't he have a page-based scrolling mechanism available? I'm thinking of all those dialogs where you have a list of checkboxes in two columns, such as the Select Monster dialog. It might be a bit complicated to set up, though...

[Niemand]

The pages of check boxes/radio buttons (LEDs as Jeff calls them) that you refer is not at all a suitable mechanism. It takes as input a list of strings, displays a dialog of that style, and allows the user to choose a single item, whose index within the list is them returned. We couldn't make use of it without building an entire new version, which still wouldn't be as nice as if we just introduced scroll bars as a supported widget type.

[Ishad Nha]

The key assignment is not too hard to remember:

A B C D E F G H

I J K L - - - -

Q R S T U V W X

Y

 

I would prefer something totally customizable, but I am not a real programmer.

Edit:

As for dialog boxes, if you don't want to re-write the entire dialog code, you will have to do it Jeff's way: split it up into individual pages. One example of this is the menus for items and monsters, another is the Choose Creature type in the Edit This Creature function.

[nikki.]

...I must be the only person to have designed for Blades without using a keyboard shortcut in the scenario editor.

[Niemand]

Ishad Nha: As I described, the multipage chooser system Jeff included is not usable for this purpose. It can only display lists of strings, which it requests from get_str().

 

Also, I frankly think that that alphabetic key assignment is insane. If I wanted to use a tool, I would have to count out its position, then count through the letters of the alphabet to figure out what key to press. Eventually, if I used a key enough I would just end up memorizing it, so there's no reason for the contrived system behind the assignments anyway.

[Ishad Nha]

See if I can't alter the chooser system, I have been looking at it. After all, I created new functions for the porting function like "add_ish_string_to_file".

 

Keyboard arrangement is something you would use regularly, you would soon get the hang of it. Personally, I would prefer customization. Users can customize if they compile, all they need is the Dev-Cpp, the source and the simple instructions.

[Niemand]

My advice: Don't bother altering that chooser system, it's not worth it. by all means, see how it works, but I think that once you do you'll agree. it doesn't support the flexibility we need.

 

Asking people to recompile is not a practical means of customization; designers want to hack on their scenario, not their scenario editor. Besides, what would they do when a new version with other useful improvements is released? At best they'd be using a subversion working copy, and would be able to merge the changes into their private branch fairly painlessly, but that assumes that they either have or want to acquire the additional knowledge and software to do that. In the worst case, they would not be using version control, and would have to keep merging changes by hand.

 

With regard to add_ish_string_to_file: Is there some reason to use all these weird add_something_string_to_file instead of just calling fprintf? It would be easier and more flexible.

[Ishad Nha]

Jeff was using add_short_string_to_file and add_big_string_to_file, I am not sure why.

[Celtic Minstrel]

Maybe he was trying to abstract from the OS-specific file routines? Of course, using fprintf would've accomplished that goal...

[Niemand]

I've been doing some thinking, ad have realized that implementing scrolling in Jeff's dialog engine could be much harder than I claimed above, since what we really need is not just a scroll bar but a scroll view to actually contain a collection of other controls. Furthermore, Jeff's peculiar custom DITL pseudo-format has nothing even close to a way to express a view hierarchy. The desired effect could be accomplished with the HIToolbox, but since at that point it would pretty much involve rewriting the dialog engine, I'm actually beginning to look seriously at just rebuilding the thing using Cocoa views and nibs, as it would make future work so much nicer and easier.

 

Also, while poking around, I came across a very nice font embedded inside the editor resources file. It's name is Dungeon Bold, and it does not appear to be used anywhere, in the editor at least. The only place it is mentioned is some commented-out code in the function that seems to do the font loading. Although a google search finds many websites offering a font by the name of Dungeon or Dungeon Bold, this one is entirely different looking.

[Celtic Minstrel]

Actually, I found Dungeon Bold in BoE, if I recall correctly, and assumed it was the font used in the talking screen. I don't remember verifying that though.

[Niemand]

Although this is perhaps a topic for another thread, since it relates to the discussion already here, I'll continue:

 

I was able to very easily write a Cocoa window class which has the same look and feel as Jeff's custom dialog windows, which made me quite happy. I'm dreading having to deal with the multitude of types of buttons, so I thought I would work up to them by determining the right settings for text labels.

 

Unfortunately, after much consternation, I've been lead to conclude that it isn't feasible to mimic the exact look of Jeff's labels. He uses Geneva for the font, which I heartily approve of, but he sets it to bold, which I can't do. Apparently, the old drawing libraries had some algorithm for rendering a font as bold even when no bold version of the font exists, which the newer libraries refuse to do. Furthermore, Jeff seems to have written he own miniature text layout engine, and part of the point of what I'm trying to do is avoid writing code like that and let the OS lay out text. The best fit I've been able to find is to use the Silom font instead, as it has simple letter shapes similar to Geneva, and a fairly heavy weight, even though it isn't bold either, so that it shows up well on on the textured background.

[Celtic Minstrel]

Originally Posted By: Niemand

He uses Geneva for the font, which I heartily approve of, but he sets it to bold, which I can't do. Apparently, the old drawing libraries had some algorithm for rendering a font as bold even when no bold version of the font exists, which the newer libraries refuse to do.

Would it let you draw the exact same string of text twice or thrice, offset by a single pixel?

(ie, bolding it manually)

[Niemand]

While that's technically possible, I'd really rather not. People will surely survive is the dialogs aren't pixel identical to the one's they're used to. Anyway, this is still just an experiment at this stage.

[Slawbug]

I have to say I'm surprised that you can't apply manual bold. Being able to apply font styles without a specific typeface for the style has been a staple of, um, personal computing, since forever.

 

On macs, at least, I'm fairly sure there was an OS routine for doing so at least through system 7 (and presumably therefore through system 9).

[Celtic Minstrel]

I know the Carbon libraries can do it, because my version of Word supports it.

 

I have no idea if the newer version of Word supports it. I wouldn't be surprised if it does.

 

TextEdit (and Pages, I assume) does not support it. I'm not quite sure why that is.

 

Does Silom come with the OS?