New Windows 3D Editor

[Ishad Nha]

"but one key thing in the Mac editor is that I split apart the object palette drawing space, with its associated scrollbar, from the button drawing space, so that I could get in an extra column on the right side. I haven't been able to make this work in the Windows version, although I can make another attempt today."

Altering "RECT terrain_buttons_rect = {0,0,210,584};" so that it is divided into two pieces is one approach. I just increased the number of columns in the terrain palette from 12 to 15. That was easy enough to do.

"One thing that I did not do is to replace any of the existing button icons."

I can have my own private customized buttons as an optional alternative.

"if we want one manual to be able to tell people how to use it."

We can have one manual for both platforms, with a section to explain any differences between the two versions.

 

Signs copying I can look into.

 

I am rewriting my personal help file for my version.

One thing needed is a list of the shortcut keys, that can be added to the Query menu. My MS Paint text box now seems to be set to a default of: font = Microsoft Sans Serif, size is 8 and it is Bold. This makes it far easier when designing text for dialog screens.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

"if we want one manual to be able to tell people how to use it."
We can have one manual for both platforms, with a section to explain any differences between the two versions.

And have twice as much work maintaining them? No thanks.

Originally Posted By: Ishad Nha

Signs copying I can look into.

Should be really easy; just have a "Copy Sign" tool that lets you select a terrain space with the sign property (based on the terrain, not the actual presence of a sign) and records the location clicked on; then have a "Paste Sign" tool which checks the stored location and makes a copy of the sign on the new location.

Originally Posted By: Ishad Nha

One thing needed is a list of the shortcut keys, that can be added to the Query menu.

If you're talking about a list of keyboard shortcuts for various things, that really belongs in the manual. You could maybe make a "quick reference" dialog, like the help dialogs in the game, but the primary place to find keyboard shortcuts should be the manual.

[Ishad Nha]

"And have twice as much work maintaining them? No thanks."

Manuals take little time to write compared to writing and testing new code. Differences won't be that great anyway.

"but the primary place to find keyboard shortcuts should be the manual"

Online shortcuts mean that you don't have to leave the Editor and go look in the manual.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

"And have twice as much work maintaining them? No thanks."
Manuals take little time to write compared to writing and testing new code. Differences won't be that great anyway.

No. One manual, please.

Originally Posted By: Ishad Nha

"but the primary place to find keyboard shortcuts should be the manual"
Online shortcuts mean that you don't have to leave the Editor and go look in the manual.

Not a complete reference though. Just the ones you think would be most commonly used. They probably have to keep the manual open while using the editor anyway.

[Ishad Nha]

I am now copying the new Mac redraw rectangle features into the Windows code. One problem is that the Windows code sometimes uses "Rect" and sometimes uses "macRect" whereas Mac always just says "Rect". I don't know if there is a meaningful difference, I don't know if Rect in Windows has only four bytes. This I must research.

[Celtic Minstrel]

Is this as a type? If so, then Jeff probably ported the Mac Rect format over to the Windows code for easier porting. If I recall, Mac stores rects as "top left and dimensions", whereas Windows stores them as "top left and bottom right". Alternatively it might be just that the coordinates are reversed. I'm not sure how Windows stores rects, so I can't say for sure, but Mac does do "top left and dimensions".

[Niemand]

The macRECT type is a duplicate of the Quickdraw Rect type:

Code:

struct Rect {   short    top;   short    left;   short    bottom;   short    right;};//We also make the assumption //that short is the same as int16_t

This is because Jeff used the latter in various game data structures which appear in savefiles, so the Windows code also needs to know about it.

 

RECT, on the other hand, seems to be a Windows type:

Code:

typedef struct _RECT {  LONG left;  LONG top;  LONG right;  LONG bottom;} RECT, *PRECT;

So, in general, it appears that in the Windows code, one should use macRECT for any game data, and RECT for drawing purposes.

[Ishad Nha]

Good, I will have to watch the difference then. Windows outdoor and town data structures use MacRect! This is a real potential problem in the Windows code because you have two different types of rectangle. Mac code won't work if it involves town or outdoor rectangles, not unless you make "working_rect" a MacRect. Then alter the functions that handle outdoor/town rectangles.

[Ishad Nha]

To show exactly which rectangle has been selected, I have added a sub-routine at the end of void draw_ter_large(). It puts a red, green and blue set of rectangles inside the existing identifying rectangles for specials, area descriptions and town entrances. I will extend this to 3D view and medium view. (I could just make it a solid red rectangle.)

Arrow keys move the selected item but don't move the viewpoint, unlike number pad keys 0:4 and 6:9. It would be a good idea to alter the arrow keys to change the view if it goes off screen.

[Niemand]

Quote:

To show exactly which rectangle has been selected, I have added a sub-routine at the end of void draw_ter_large(). It puts a red, green and blue set of rectangles inside the existing identifying rectangles for specials, area descriptions and town entrances. I will extend this to 3D view and medium view. (I could just make it a solid red rectangle.)

What I did in the Mac code to indicate selection is to draw a pink outline around the selected object. See for example place_creature_icon_into_ter_3D_large() (line 739 specifically) and draw_ter_3D_large() (line 2430 specifically) in Graphics.cpp in the Mac code. It isn't wonderful looking, but it can be applied consistently to every selectable object type, which I think is very important. It's also important that this look the same on both platforms, so we need to agree on how this will be done. I already have a pretty complete implementation, but I won't be averse to making some changes if they will improve it.

Quote:

It would be a good idea to alter the arrow keys to change the view if it goes off screen.

Yes, it would. You can find my implementation of this around line 2340 in EdFcns.cpp in the current Mac code. In particular, the use of out_of_view_3D() is important (in my opinion) to make this look nice in 3D mode.

[Celtic Minstrel]

Huh, I guess I was wrong. Not in the basic idea, but in the details.

[Ishad Nha]

You could have concentric white rectangles around the square. That might look nicer. I currently have them inside the square.

[Niemand]

White isn't a viable option: it's already used as the outline color for hidden, neutral creatures. Magenta isn't very aesthetic, but it wasn't used for any other purpose and it stands out on pretty much every common background.

 

EDIT: I also picked to put outlines outside since that way they look consistent across rectangles and things like creatures and items.

[Ishad Nha]

Three white concentric rectangles stand out alright. It is hard to find distinctive colors that are not already used.

We need drag and drop for selected items. I am working on that now. Ctrl + RMB toggles selection mode. Then there is a move selected object mode, clicking on a space then shifts the selected instance.

[Niemand]

Quote:

We need drag and drop for selected items. I am working on that now.

That might be nice, but it is a big undertaking. I think we need to get other things cleaned up and synchronized first.

Quote:

Ctrl + RMB toggles selection mode.

What does 'toggling the selection mode' mean? Also, Ctrl + RMB is a terrible choice since it can't be used on Mac OS: Control click is a secondary (right) click.

Quote:

Then there is a move selected object mode, clicking on a space then shifts the selected instance.

I don't follow what the first part of this means. (Are you saying that you want to add an extra drag-and-drop mode which has to be switched into explicitly?) From the second part it sounds this isn't drag-and-drop at all, but allowing the user to click to relocate an object.

Given what I understand, this does sound similar to the redraw mode I added for selected rectangles. In that case an important purpose is served since there is no other way to change a rectangle's shape. For objects which just have a position, like items and creatures this seems less worthwhile, since it doesn't accomplish anything that couldn't be done already with the arrow keys. It can, I'll grant, be a bit more efficient, and also give more flexibility of using the mouse rather than the keyboard, but it comes at the cost of complexity in terms of another mode. (Having to switch into a special mode also negates a good portion of the efficiency gain, I'd argue.)

Actual drag-and-drop would likely be significantly better, in that it wouldn't require a special mode (from the user's point of view, anyway), and is a standard operation in many programs, but would involve (perhaps much) more complex programming. I think it could be done, but I'm not keen to jump into it just at present, given the hideous nature of the editor's event handling system (at least on Mac OS).

Oh, and about selection indicators:

Quote:

Three white concentric rectangles stand out alright. It is hard to find distinctive colors that are not already used.

Well, magenta is one. If you can think of another, I'm all ears.

A list of already assigned outline or rectangle colors that I can think of:

Click to reveal..

• blue (friendly creature)
• black (neutral creature)
• red (hostile A creature)
• brown (hostile B creature)
• cyan (friendly, hidden creature)
• white (neutral, hidden creature)
• bright green (hostile A, hidden creature)
• yellow (hostile B, hidden creature)
• light blue (special encounter rectangle)

[Ishad Nha]

“What does 'toggling the selection mode' mean? “

Toggles overall mode 40, the select object mode.

“Also, Ctrl + RMB is a terrible choice since it can't be used on Mac OS: Control click is a secondary (right) click. “

I am not on a Mac so I am not aware of good choices.

“Then there is a move selected object mode, clicking on a space then shifts the selected instance.”

Yes, it is click and relocate, shift selected instance. Ctrl + Right click shifts the selected object immediately to the square you click on. You don’t even need to hold the Ctrl button down while scrolling around. It is drag and drop without the drag.

“ It can, I'll grant, be a bit more efficient, and also give more flexibility of using the mouse rather than the keyboard,”

You don’t need to scroll one square at a time with the arrow keys. It is meant to provide a mouse alternative to the keyboard.

Three white concentric rectangles stand out alright. It is hard to find distinctive colors that are not already used.

There is a one line gap between each rectangle, so it is distinctive. Red is another color that stands out. As the gaps exist, it looks different to a solid rectangle used to show a creature's attitude.

 

I altered the interface so the lower left text is now displayed in all three viewing modes: small, medium and big. This makes it easier to select and move around objects.

 

My internet is down at home so I have had to trek to an internet café. My ISP may eventually brave the uncharted wilderness where I live and fix the connection but in the meantime…

 

[Ishad Nha]

Rectangles can be moved around too. I use the upper left corner of the rectangles to calculate the displacement. I could use any of the four corners to do this.

I have the Shift + RMB combination rigged to remember the last selected item, you can do something else like place floor/terrain then return to the selected item.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

“Also, Ctrl + RMB is a terrible choice since it can't be used on Mac OS: Control click is a secondary (right) click. “
I am not on a Mac so I am not aware of good choices.

But now that you know, you'll change it, right?

[Ishad Nha]

“But now that you know, you'll change it, right?”

I will have to hunt around for a new key. That may not be so easy, most of the possible keys are already used. I could try reassigning F3 and F4...

 

I have found a solution for the sign moving but not the relevant terrain problem, when the sign is selected, the sign terrain type is recorded. When the sign moves, the terrain on old square is set to zero. Like all selected objects, a selected sign has colored squares surrounding it.

If there is no terrain on the new square, the sign terrain reappears. If there is terrain, the sign terrain type remains hidden. Otherwise you wipe out chunks of the map. There will be a problem if the new square has the same terrain type as the sign.

[Ishad Nha]

I am now experimenting with the ability to select a square and move all its contents in one go. This is a first step to a comprehensive drag and drop that would move everything in one go.

I turned on the Enable Class Browser in Bloodshed Dev-Cpp, it could take ten seconds to type a single character! I disabled it, it was way too slow and the new features did not compensate for a loss of time and patience.

A Storage.cpp would be a good idea, it would store all the commented out and unused functions that presently clutter up the source code.

[Niemand]

Quote:

I am now experimenting with the ability to select a square and move all its contents in one go. This is a first step to a comprehensive drag and drop that would move everything in one go.

A still think that there are a number of other things that we should do first. . . not, I admit, that I've been getting any work done on them.

Quote:

A Storage.cpp would be a good idea, it would store all the commented out and unused functions that presently clutter up the source code.

No, unused code should be deleted, unless it is of particular interest (like the partial script interpreter source) or it is highly likely to be wanted later. We have version control for a reason: if we delete something we later realize we want, we just go back and copy it from an old revision where it still existed. By all means feel free to store for your own use any code that you've been thinking about or working on, but that doesn't yet or currently have a use, we just don't want the editor proper to be cluttered up with stuff that doesn't contribute to making it work. (I personally keep a directory for little test programs and prototypes on my desktop.)

[keira]

i'm having serious issues with building the editor from source. Every time i try to compile it throws a very cryptic 'Error 1'. i've tried everything i can think of to make it work but no dice. Any ideas?

 

Build Log.

[Niemand]

There is an error there, it's just buried under the swarms of warnings about const correctness issues:

Quote:

Bl A Fileio.cpp:1257:32: error: too many arguments to function 'void load_outdoor()'

Bl A Fileio.cpp:1190:7: note: declared here

Bl A Fileio.cpp:1276:31: error: too many arguments to function 'void load_outdoor()'

Bl A Fileio.cpp:1190:7: note: declared here

Bl A Fileio.cpp:1507:32: error: too many arguments to function 'void load_outdoor()'

Bl A Fileio.cpp:1483:7: note: declared here

I'll have to take a look at the code to find out more.

 

EDIT: I am not seeing that problem. Are you sure your working copy is up to date?

[keira]

Originally Posted By: Niemand

There is an error there, it's just buried under the swarms of warnings about const correctness issues:

Quote:

Bl A Fileio.cpp:1257:32: error: too many arguments to function 'void load_outdoor()'
Bl A Fileio.cpp:1190:7: note: declared here
Bl A Fileio.cpp:1276:31: error: too many arguments to function 'void load_outdoor()'
Bl A Fileio.cpp:1190:7: note: declared here
Bl A Fileio.cpp:1507:32: error: too many arguments to function 'void load_outdoor()'
Bl A Fileio.cpp:1483:7: note: declared here

I'll have to take a look at the code to find out more.

EDIT: I am not seeing that problem. Are you sure your working copy is up to date?

I checked out another copy, it's still giving me the same error...So i'm guessing it's something with my compiler/linker? I've tried it with Dev-Cpp as well as with MinGW by it's lonesome.

[Niemand]

I think I may have found the problem: In a couple of places, inside functions in that file, there are line like:

Code:

void load_outdoor();

That is, forward declarations for a function named load_outdoor which takes no parameters. If your compiler were to decide somehow that this is the version of load_outdoor being called at points later in those functions, it would complain that there are too many arguments being passed. (What isn't clear to me is why it would make this choice; I don't have a very thorough understanding of the overload resolution rules, but I would have assumed that both declarations would be considered in scope and that the one with formal argument types matching the actual argument types would be selected. Possibly the rules for local function declarations are stranger than I thought, which seems more likely given that the existence of local declarations when local definitions are forbidden is weird to begin with.)

 

At any rate, try locating the lines like the one above and deleting them. They look like they were at best useless, and at worst a fatal error, and I can't figure out why they were ever there in the first place.

[keira]

Awesomesauce! I commented out the offending lines (1190 and 1483) and it now compiles. Thanks!

[Celtic Minstrel]

Yay!

[Ishad Nha]

Brilliant, exactly what we need, someone else who can hopefully program.

 

I have added a function to my own private version of the Editor that will display any dialog screen whose number you enter. This makes it easier to inspect and correct the layout of any of the eighty-odd screens.

[Ishad Nha]

I have modified the object number mode and made it a sub-routine of group display mode. It has various formats, so that it now shows various things as you cycle through the modes: names, type numbers&. Thus it can cause all area descriptions to show on the screen at once, if they are in the 9x9 big mode display. Ditto terrain script names, sign texts, towns entered.

[Ishad Nha]

New idea: allow customization of selection squares for medium view. The selection square is a graphic in the Editor icon sheet G4918. This approach will work for single square things like creatures, terrain scripts, items, signs and preset fields. It would work for rectangles if every square lying on the rectangle was covered by one of these squares. There is one selection square graphic for each of the 11 types of selection. This approach could be extended to type 0 (large view) and type 10 (non-realistic 3D view). Latter would require additional graphics of the 46 x 56 pixels size.

Town and outdoor selection groups are shown below:

Click to reveal..

Town Selection Groups:

0 (no display)

1 creatures

2 terrain scripts

3 items

4 placed specials

5 area descriptions

6 town boundary

7 signs

8 wandering locations

9 preset fields

10 waypoints

11 horses and boats

 

Outdoor Selection Groups:

0 (no display)

1 (nothing to select)

2 (nothing to select)

3 (nothing to select)

4 placed specials

5 area descriptions

6 town entrances

7 signs

8 wandering locations

9 wandering encounters

10 special encounters

11 preset encounters

Version.h, do we need it? I just add the define kversion thing to the top of Bl A Editor.cpp file, I deleted the include version.h line.

 

[Celtic Minstrel]

I'm sorry, but I don't understand what you're suggesting here.

[Ishad Nha]

When you select something like a creature, item, script, rectangle or whatever, it is surrounded by a colored square or rectangle. The choice of color is currently hard-coded. I was suggesting allowing people to choose the coloring by making the selection squares graphics, which people could edit.

[Celtic Minstrel]

That seems like a bad idea. Customizing the colouring might not be a bad idea, but probably not in that way.

[Ishad Nha]

All you need to do when editing is to open the graphics file in a graphics program and edit away. That also gives the user total control over the shape of the selection square. He can make it a solid square or separate lines and so forth.

[Ishad Nha]

New version uploaded to the Freewebs site. It has customizable graphics for medium creatures, individual selected objects and group displays. (Latter are a feature of the Windows Editor, they are explained in the help file.)

[Celtic Minstrel]

No, making the user edit an image in order to customize something as simple as selection colour is not really an acceptable choice.

[Ishad Nha]

By use of graphics you can also customize the shape of the selection shape, you can have crosses or whatever. You can choose exactly where the lines or dots go...

[Niemand]

I agree with Celtic Minstrel; this is at least not something which should be advertised as a feature. Users should not have to mess with the internals of the program, and in this case there isn't any strong reason for it anyway.

[Ishad Nha]

They do get a choice, they don't have to mess with it if they don't want to.

[Slawbug]

*facepalm*

[Ishad Nha]

It is supplied with a fully functional set of graphics that will show everything. You don't have to alter if you don't want to.

I am introducing this for the Big 2D view, type 0. I have just altered the signs, now I will proceed to anything else that is one square.

 

In large 2D view, type 0, there are two separate commands for drawing creatures. The first draws all creatures while the second only draws a selected object. The second command seems unnecessary, removing it seems to have no effect on anything. Same story with items, there are two separate commands.

Click to reveal..

Relevant code from around line 3,080 of Graphics.cpp:

if ((hintbook_mode2 == 0) && (hintbook_mode3 == 0)) {

// draw creatures

for (i = 0; i < NUM_TOWN_PLACED_CREATURES; i++)

if (town.creatures.exists()) {

draw_creature(main_dc5,store_bmp,i,loc_drawn,q,r);

}

if ((selected_item_number >= 7000) && (selected_item_number < 7000 + NUM_TOWN_PLACED_CREATURES)) {

draw_creature(main_dc5,store_bmp,selected_item_number % 1000,loc_drawn,q,r);

}

}

 

if ((hintbook_mode2 == 0) && (hintbook_mode4 == 0)) {

// draw items

for (i = 0; i < NUM_TOWN_PLACED_ITEMS; i++)

if (town.preset_items.exists()) {

draw_item(main_dc5,store_bmp,i,loc_drawn,q,r);

}

// draw selected instance

if ((selected_item_number >= 11000) && (selected_item_number < 11000 + NUM_TOWN_PLACED_ITEMS)) {

draw_item(main_dc5,store_bmp,selected_item_number % 1000,loc_drawn,q,r);

}

}

 

[Celtic Minstrel]

...sigh. This is a misfeature that we do not want, Ishad. By all means keep a private copy that includes it, but the rest of us would prefer sticking to the simpler method already in place.

[Ishad Nha]

You don't need to use this feature if you don't want to.

[Celtic Minstrel]

That's not the point.

[Slawbug]

Speaking as an end user who doesn't use BoA because it already seems too clunky, I agree with Celtic Minstrel and Niemand.

[Ishad Nha]

BoE Editor can be resized easily enough. This may occasionally be useful. Resizable 3D Editor, I can make this happen easily enough, but the result is messy when you press the Maximize button. However the resizing aspect works properly.

In the function BOOL InitInstance( HINSTANCE hInstance, int nCmdShow ) I replaced the existing window style commands with:

WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN,

If you do press the Maximize button, press it again to undo the damage.

Edit:

This is an alpha version, it is basically functional but it lacks some finishing touches.

http://www.freewebs.com/ishadnha/AlphaResizeBoA3DEditor.zip