New Windows 3D Editor

[Celtic Minstrel]

I suggest adding error dialog boxes everywhere an error could occur, saying exactly what went wrong.

[Ishad Nha]

Program crashes immediately and gives none of the error messages that I wrote. I watered-down oops_error...

[Ishad Nha]

Anything that is eventually intended to be put in an external file has been shifted to a new header file: Bl A Fileio.h. Said external file will be open to editing by users of the program.

Porting is now open-ended, you can port the same scenario as many times as you like, up to 1,000. This is meant to enable the catching of bugs.

A new array has been added to allow individual outdoor zones or towns to be removed from the loop that generates their scripts. This will deal with data corruption or inexplicable crashes.

Translation of BoE nodes has been reviewed up to node 80.

If any creature in a town has a name the town script will now show the name in the Init State.

Outdoor scripts now show the outdoor section number and the zone name.

Debug can be used to catch errors, it will require the padding of the program with debugging information.

[Celtic Minstrel]

That won't work; forcing the users to recompile the program is just stupid, and why would you want to port the scenario 1000 times?

[keira]

If a program won't do something the first time, it likely won't do it the other 999 times.

[Ishad Nha]

The problem is that I can't get the error messages to print, the game crashes immediately and totally. So I have to remove towns from porting one at a time and see if they are at fault. Errors occur in the first town or zone that is not properly written, that can't be opened in the Editor.

I am repeatedly porting to see if I can catch the errors. The write allow/disallow can be hex-edited, it will eventually be entered by an external file. I would be recompiling 10 or 20 times not 1,000.

Errors affect only one or two towns or zones, in a few scenarios. They don't occur in the Spiderweb 2D Editor or in my Zoom Editor. I am trying to see why they occur.

As for debugging, on Bloodshed Dev I will need to inflate the file with a whole lot of debugging material. So I have created a duplicate project where the program is inflated to 1,610KB.

[Celtic Minstrel]

What's the error when it crashes? Is it a segmentation fault or a bus error? If so, make sure you're not accidentally referencing an out-of-bound element in any arrays. Add bounds-checking statements anywhere this might be the case. Your goal should be to get it to the point where it prints a useful error message and then either terminates the entire process or skips to the next section.

[Ishad Nha]

Segmentation fault is the word I recall from the Debug feature of Bloodshed Dev C++. I could not get the debug to work properly for whatever reason.

Out of bounds is possible, sometimes you will get a node where a node type was assigned but then valid values for the variables were not entered, hence it was presumably cancelled. So the port node function will detect a valid type but there will be no valid node as such. I have tried to avoid out of bounds errors.

As it is only the new version of the Editor that crashes, it is presumably my handiwork. I can look at the original exs file in the BoE Editor and see if anything is a possible source of trouble. Then I can check files ported by the official 2D Editor and my Zoom Editor.

It is only a few scenarios that crash, the porting function usually works properly. I check all files with "alint *.txt" and there are usually no genuine errors.

[Celtic Minstrel]

As I said, do bounds checking everywhere you access an array, and you might find that's your problem.

 

When accessing an out-of-bounds array element, if you're lucky you'll just get garbage. More likely you'll get a segmentation fault or a bus error.

[Niemand]

In addition to doing bounds checking, just fall back on the fundamental strategy of debugging: figure out where the program was executing when it crashed. An interactive debugger can help, but even without it your can always temporarily modify the code to print more information on its progress as it goes.

[Ishad Nha]

Generally, the program crashes at a clear point, the last zone or town. Inside the relevant script the situation is not so clear, the script may not be written at all. All attempts to create an error report have been in vain.

Checking the exs file has not shown me any clear errors that would cause a crash.

Edit:

One small problem was solved: node 211 was never printed properly when translated. It turns out that case 211: is missing from the list of cases from 200 through 216.

Edit:

It should be the same story with case 91: // webs.

Another minor mystery, occasionally a script is printed in Dos not Mac format. Of Good and Evil has this occur in dialog scripts for towns 34 and 39. This problem is also shared by the official 2D Editor. The problem is easily fixed in Crimson Editor, correct the format, save and reload.

 

 

[Celtic Minstrel]

Originally Posted By: Ishad Nha

Another minor mystery, occasionally a script is printed in Dos not Mac format. Of Good and Evil has this occur in dialog scripts for towns 34 and 39. This problem is also shared by the official 2D Editor. The problem is easily fixed in Crimson Editor, correct the format, save and reload.

Huh? If by Dos vs Mac format you're referring to the newline style, I can't imagine how that would happen...

[Ishad Nha]

Dos not Mac format, I can't figure it out either. It is only a couple of scripts. Thankfully it is easy to fix. It may be a problem on only my computer. Anyone else on Windows can try porting Of Good and Evil, and see if it affects them too. It occurs occasionally elsewhere but I forget where.

I am adding an Edit this Terrain Script dialog, just like the Edit This Creature dialog. That way you don't have to activate only one cell dialog at a time. Game plan is that there will be left and right arrows to go from one screen to another. But the arrows won't actually save the contents of the dialog screen that will be done by a new Save button. Then you choose another screen or exit with the OK button. Cancel exits from the screen without saving while OK both saves and exits.

Then I might add a dialog that shows all placed specials and their locations, enabling editing of them in one go.

[Ishad Nha]

Designing the dialog for terrain scripts was easy enough once I remembered the list of event filters in Bl A Editor.cpp.

I guess Jeff uses a proprietary editor to design his dialog text boxes. Not having the editor, dialog design is best done by approximating the Editor font in an MS Paint text box. Best guess is: font = Microsoft Sans Serif, size is 8 and it is Bold. This seems to work in actual practice.

Edit:

Using these font specifications in a spreadsheet, you can figure out what size text box you will need in Paint.

[Ishad Nha]

Finally, I should be able to print placed special numbers on the screen. It involves being able to create a rectangle from a location. Currently the method works for sign and terrain script numbers.

Here is the code for terrain script numbers:

 

Click to reveal..

if (object_display_mode == 4) {

for (i = 0; i < 100; i++) {

if (town.ter_scripts.exists > 0) {

rectangle_draw_rect.left = 15 + BIG_SPACE_SIZE * (town.ter_scripts.loc.x - cen_x + 4);

rectangle_draw_rect.right = 15 + BIG_SPACE_SIZE * (town.ter_scripts.loc.x - cen_x + 4 + 1) + 1;

rectangle_draw_rect.top = 15 + BIG_SPACE_SIZE * (town.ter_scripts.loc.y - cen_y + 4);

rectangle_draw_rect.bottom = 15 + BIG_SPACE_SIZE * (town.ter_scripts.loc.y - cen_y + 4 + 1) + 1;

sprintf(str,"%d",i);

to_rect = rectangle_draw_rect;

OffsetRect(&to_rect,3,14);

if (strlen(str) == 1)

to_rect.left = to_rect.right - 14;

if (strlen(str) == 2)

to_rect.left = to_rect.right - 21;

if (strlen(str) == 3)

to_rect.left = to_rect.right - 29;

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

}

}

}

[Niemand]

This does not seem like a good idea, it looks like it will lead to having a lot more numbers floating around all over the place. I, for one, keep the editor set to always show every space's height in 2D mode, so there's no room for more numbers.

 

If the user wants to know a terrain script's number, all they have to do is select it, and why would they even care about signs' numbers?

[Celtic Minstrel]

Niemand has a point; some numbers, such as sign numbers, are things the user never needs to know, so there's no reason to show them.

[Ishad Nha]

I am working towards printing out the monster type and placed special numbers, that is the actual point of the exercise. Sign numbers are irrelevant but the ability to print them is more than I was originally able to do.

You might be able to show the first few letters of a terrain script's name.

[Celtic Minstrel]

I don't see why you'd want to show the terrain script's name on the map, either. As for the monster type, can't you just select the monster to see that?

[Niemand]

Originally Posted By: Ishad Nha (SVN log)

New mode: Object Display Mode
Now placed specials show which special has been placed and monsters have their type number shown.,
Fields and signs have their numbers printed, so you can keep track of how many have been placed.

I had missed reading this before; knowing how many signs have been placed could be useful so as not to run out, but I don't think that this is a good solution for two reasons: 1) It clutters up the main terrain view and 2) The user will still have to scroll all around to look for the largest numbered sign yet placed. It might be worthwhile to think about a better way to handle this, but I don't think it's a high priority.

Originally Posted By: Ishad Nha (SVN log)

Hintbook mode 8 now displays colored lines around signs and fields, this is useful in porting to check for errors.

This sort of defeats the basic purpose of hintbook mode, namely to make screenshots which will basically match what the player will see on the automap in the game. If I recall correctly you'v now given hintbook mode a whole set of submodes, so that the original purpose can still be fulfilled, but i think this is rapidly getting more complicated than any user will want to try to remember how to use, particularly given that there is nothing to make this portion of the user interface discoverable to people who don't already know about it (which is admittedly a problem with much of the editor, but one that we should seek to combat rather than exacerbate).

Ishad Nha, which part of your changes is it that you're referring to as 'Object Display Mode'? I can't quite tell from the log message.

[Ishad Nha]

Numbers printed in the squares, you can read up to 81 of them all at once, without any need to select the instances concerned one at a time.

Hintbook mode grew pretty big, it is no longer really that at all, I really should rename it at some point.

Giving numbers to signs and fields enables you to keep track of how many you have left, as you are placing them.

My help file is pretty good at explaining "Hintbook mode", I have yet to update it for the current changes. It is found at the Variant Editor download.

 

Changes in Bl A Fileio.cpp are all due to me reshuffling the order of the query reports. I will have to hunt through my copy of the changes and see what relate to object display mode.

[Niemand]

Quote:

Numbers printed in the squares, you can read up to 81 of them all at once, without any need to select the instances concerned one at a time.

Yes, but you can't tell what they correspond to if they aren't just height values as they have traditionally been. And what is there's a creature standing on a terrain script, or on a sign? It'll just be a mess, no matter what you try to do with it, I think.

Quote:

Giving numbers to signs and fields enables you to keep track of how many you have left, as you are placing them.

Granted it does technically let the user do that, but it's very clumsy. Unless all of them are placed in one go, the user will have to search all over to find the highest numbered existing one, or place and delete an extra, to find out the count. It isn't very elegant at all, and not, I think, worth the confusion of having all kinds of extra numbers floating around in 2D mode.

Quote:

My help file is pretty good at explaining "Hintbook mode", I have yet to update it for the current changes. It is found at the Variant Editor download.

If the changes are for your personal version, please don't merge them into the main line of the editor that we expect to release to everyone. If you want a branch in the repository to mess around in, either make one, or ask, please.

[Ishad Nha]

Object display mode is found only in Bl A Editor.cpp and Graphics.cpp. In the former file it is found as cases 1520 and 1521. In the latter it is found only in "void draw_ter_large()", where it does occur you will find a block starting with " if (object_display_mode == #) {"

 

"Yes, but you can't tell what they correspond to if they aren't just height values as they have traditionally been. And what is there's a creature standing on a terrain script, or on a sign? It'll just be a mess, no matter what you try to do with it, I think."

Only one sort of number is displayed at once. There is also a string displayed (in the "void place_left_text()" area) which tells you what sort of object is currently being displayed. The modes are:

Town mode: "(Null Display)","Placed Specials","Sign Locations","Town Creatures","Terrain Script Numbers","Placed Fields"

Outdoor mode: "(Null Display)","Placed Specials","Sign Locations","Preset Encounters","Town Entrances","(Null Display)"

You can cycle forwards and backwards through the mode using the shortcuts Ctrl + 9 and Ctrl + 0.

Obviously it is not a good idea to use object display mode and drawing mode 2 (display height) at the same time. Only one of object display mode and numerical display mode can be used at a time. Cycling through one mode shuts the other one down.

 

"Granted it does technically let the user do that, but it's very clumsy. Unless all of them are placed in one go, the user will have to search all over to find the highest numbered existing one, or place and delete an extra, to find out the count. It isn't very elegant at all, and not, I think, worth the confusion of having all kinds of extra numbers floating around in 2D mode."

As you place something, its number is immediately displayed if you are in the correct display mode.

 

"If the changes are for your personal version, please don't merge them into the main line of the editor that we expect to release to everyone. If you want a branch in the repository to mess around in, either make one, or ask, please."

The help file is for the changes I commit to SVN.

 

Edit:

Here is a collection of screen captures to show what object display mode looks like in practice. They are from Selathni, town 1 in A Small Rebellion.

http://ishadnha.webs.com/ObjectDisplayMode.png

 

Edit:

It is possible to have two sets of numbers at the bottom of the screen. Each number is 6 pixels wide and there is 1 pixel between numbers, the large square is 48*48 pixels. Height would remain where it is. Numerical display mode and object display mode could go on the left. As height is only two-digit, the sharing of space between left and right should not be a problem

[Celtic Minstrel]

Originally Posted By: Ishad Nha

Here is a collection of screen captures to show what object display mode looks like in practice. They are from Selathni, town 1 in A Small Rebellion.
http://ishadnha.webs.com/ObjectDisplayMode.png

I can't say I like it.

Originally Posted By: Ishad Nha

It is possible to have two sets of numbers at the bottom of the screen. Each number is 6 pixels wide and there is 1 pixel between numbers, the large square is 48*48 pixels. Height would remain where it is. Numerical display mode and object display mode could go on the left. As height is only two-digit, the sharing of space between left and right should not be a problem

If you must do this (and I'm not saying it's a good idea; it really isn't), the smart way would be to use top-left and bottom-right.

[Ishad Nha]

If you don't like the look of it, don't use it, it is off by default.

I have already created a display for both sets of numbers at the bottom of the screen. Upper left and lower right display will take some fiddling with OffsetRect.

[Kelandon]

I imagine there's no problem adding features that can be turned off.

[Celtic Minstrel]

Bloating is bad. Adding features isn't bad, but you shouldn't just add them willy-nilly — give them some thought, and take the time and care to do them right. Niemand was on the right track when he suggested making rectangles selectable.

[Ishad Nha]

Selectable rectangles, I will have to find the time for that.

On another note.

Currently if the scenario has an undefined floor type an off-white square is printed, RGB = (230,230,230). (If it is undefined, it is not defined in either the core scenario data script or in the custom scenario data script). There is no such provision for undefined terrain types. Such squares could be filled with blue or whatever. You could change the floor default 230,230,230 to green or whatever to make it stand out more.

Edit:

Blue looked too much like the water graphics, so I settled on red for undefined floors and green for undefined terrain. The shade of green was the same as used to show some of the monsters in zoom out mode.

[Celtic Minstrel]

I'd say use a special graphic for an undefined terrain type, like the question mark graphic for an undefined monster. You could probably even use the same graphic, actually. Aren't the elements of monster sheets the same size as those of terrain sheets?

[Niemand]

Quote:

Aren't the elements of monster sheets the same size as those of terrain sheets?

Yes, they are, and your suggestion sounds like a good one. A sensible extension would then be to include similar icons for undefined items and floors (technically floor graphics are the same size as creatures and terrains, but it would look a lot better and be a lot clearer to use something sized and shaped like a floor tile).

It might actually be nice not to use the games question mark shaped undefined creature graphic in any of the cases, but instead to use graphics indicating the nature of the problem a bit more directly and specifically, sort of like the Last Resort font.

[Ishad Nha]

The undefined items already use a question mark graphic, it is the very first graphic in the Item Graphics folder.

Special graphics for undefined floors and terrain might be a good idea. They will need to be distinct, so they are not confused with each other or with the Creature placeholder graphic. They are only temporary graphics, they will be replaced when the designer does something about the undefined floor/terrain, so they don't need to be too elaborate.

[Ishad Nha]

In the source code you have items and creatures being drawn twice, once as items/creatures and then as selected instances. I commented out the selected instance version of draw creature, it seemed to make no difference.

Click to reveal..

// 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);

}

// 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 >= 7000) && (selected_item_number < 7000 + NUM_TOWN_PLACED_CREATURES)) {

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

}

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);

}

SelectObject(main_dc5,DibBitmapHandle(ter_draw_gworld));

}

For some reason, small view stopped working. So I will compare my current files with what I last committed to Tortoise. This may reveal the error. Large and medium views were working fine as far as I could tell. This is where SVN really comes in handy.

(No, I don't think there is any connection to the commenting out in large view, the two views are wholly separate functions.)

 

[Niemand]

Quote:

I commented out the selected instance version of draw creature, it seemed to make no difference.

Don't do that, that was done that way for a reason: it allows the selected instance to show as the top of a stack of things, which is quite important for dealing with piles of items.

[Ishad Nha]

Creature attitude Hostile Type B seems never to occur in actual practice. It needs an image makeover, starting with its own color scheme, this is the best I can think of so far:

Usual color, a shade of orange:

R = 255, G = 128, B = 0.

Normally, the usual color has G = 0, while the hidden class color has G = 255, that is the only difference between them. Here that scheme won't work so I will need to manually assign my own choice:

Hidden class color

R = 215, G = 215, B = 215.

Edit:

Currently the scheme is based upon the three fundamental colors: Red, Green and Blue. Each color has only two possible values: 0 and 255. Now 2^3 = 8, thus there are 8 possible color combinations, and only 6 values are currently used. The two unused values are R = 255, G = 0, B = 255 and R = 255, G = 255 and B =255. The first is the pinky color of the town entrances in outdoor mode while the second is simply pure white. I don't find the pinky color to be quite the ticket for hostile type B monsters, but anyway...

The white color would not give a distinctive band around the creature graphic in large view. But there will be a clear absence of such a band when you look around the facing rectangle, the rectangle that indicates the direction the creature is facing.

[Niemand]

Quote:

Creature attitude Hostile Type B seems never to occur in actual practice.

This is not true.

Quote:

It needs an image makeover, starting with its own color scheme

What? It already had a perfectly color scheme which was distinct from, but analogous to, the one for Hostile Type A.

I do now notice that in 2D mode, the Mac editor has a bug such that it uses Type A colors for Type B creatures, so that they appear indistinguishable. In 3D mode, however, it is handled correctly. The obvious way to fix the this is to apply the same colors used in 3D mode to 2D mode. If the Windows editor merely has the same bug/oversight, it should be fixed the same way.

[Ishad Nha]

In Windows there is a difference between the types of Hostile when in 3D mode. I did not spot that before. Neutral hidden creatures have a white not a green aura. This color scheme could be harmonized with that for 2D mode.

In Windows large 2D mode there is no difference at all, the code reads:

"if (town.creatures[creature_num].start_attitude >= 4)

r = 255;"

Ditto in small 2D mode:

"else if (town.creatures.start_attitude > 3)

put_rect_in_gworld(main_dc5,to_rect,255,0,0);"

[Ephesos]

Hey, I'm with Niemand on this one. Hostile type 2 does get use, and it already does look suitably different.

[Ishad Nha]

We will need some way to distinguish them in 2D mode, currently there is no such way.

While I am at it, I will allow zooming out from 3D mode. In the existing editor you can only zoom in and out while in 2D. Idea is that you can zoom out while in 3D mode then zoom back into it.

Edit:

This seems to be the 3D color scheme for creatures, it is based upon their Attitude.

A,A, R, G, B, Color

2, F, 0, 0, 255, Blue

3, N, 0, 0, 0, Black

4, A, 189, 0, 0, Red

5, B, 189, 99, 0, Orange brown

If Hidden:

2, F, 0, 255, 255, Aqua

3, N, 239, 239, 239, White

4, A, 189, 255, 33, Yellow

5, B, 255, 239, 0, Golden Yellow

To harmonize this with the 2D scheme, best bet is to keep the present scheme and add values for attitude 5 = Hostile type B.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

Currently the scheme is based upon the three fundamental colors: Red, Green and Blue. Each color has only two possible values: 0 and 255.

Um. What? Each colour has 256 possible values, not two!

Originally Posted By: Ishad Nha

While I am at it, I will allow zooming out from 3D mode. In the existing editor you can only zoom in and out while in 2D. Idea is that you can zoom out while in 3D mode then zoom back into it.

This really isn't something important. It's not too much work to click twice instead of once to zoom out and return to 3D mode.

[Ishad Nha]

Each color has only two possible values in Jeff's color scheme. Outside of that it does have the full 256 possible values.

Revised Case 5, Hostile Type B values, these will be used for all viewing modes except realistic mode:

5 B: R = 190, G = 100, B = 0, Orange brown

If hidden:

5 B: R = 255, G = 0, B = 128, Rosy pink

[keira]

you could just have it read hex color values from a ini file

[Ishad Nha]

Yes, that would allow people to choose their own schemes. I will have to learn how to program this at some point.

[Ishad Nha]

The 3D Editor is using the wrong graphic for the Dried Blood stain, it should be using icon 2 of G707.bmp. I am not too sure what it is using.

Mirrors could apparently be placed by the Editor just like the other objects, fields and stains.

This is the list of field numbers used by the bas file:

1 Blocked

2 Mirror (oblique)

3 Force Barrier

4 Fire Barrier

5 Web

6 Crate

7 Barrel

8 Mirror (face-on)

14 Small Blood Stain

15 Medium Blood Stain

16 Large Blood Stain

17 Small Slime Pool

18 Large Slime Pool

19 Dried Blood

20 Bones

21 Rocks

I will have to try this at some point.

[Niemand]

Some of these are obvious in the code, but others aren't, at least anywhere I can think of. For example, how do you know the indices of the mirrors? Secondly, does the game actually honor all of these? The reason I'm suspicious is that I had pieced together most of this list in another thread around here somewhere, but have been discouraged by noting that while the stains are stored with numbers in the order expected from the values recognized by the game's is_stain_on_space() and put_stain_on_space(), the objects and fields are not, instead being mixed together haphazardly. Note also that the 8 types of stain, 7 objects, 7 fields, and blocking total up to 23 items. Jeff may have just decided to put them in a really strange order, or he may have left some of them out. We'll just have to test to find out.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

I will have to try this at some point.

Yes, please do. If mirrors and quickfire could be placed in the editor and show up in game that'd be wonderful.

[Ishad Nha]

How do I know the indices? Reverse engineering, hex edit the bas file and see what happens. From what I can see the game will accept the inserted mirrors. My party was pushing mirrors around a town okay. I will have to check that the inserted mirrors reflect beams like those created by a town script.

Mirrors can now be inserted like other fields, just use the last two buttons on the second row. These are currently only used for outdoor zones and town entrances, hence in town they are not used. First one places the side-on mirror while the second one places the mirror that faces you.

"Note also that the 8 types of stain, 7 objects, 7 fields, and blocking total up to 23 items." Niemand's math is compatible with my insertion of mirrors because my number scheme has no fields in it, there are only objects and stains.

Quickfire may be tougher, like any field I don't know its index, it may not work like the objects and stains.

New version is available at:

http://ishadnha.webs.com/VariantBoA3DEditor.zip

 

Here is a list of the fields, objects and stains for reference:

short is_field_on_space(short x,short y,short field_type)

Returns 1 if a field of type field_type is on space {x,y}, 0 otherwise. The field types are:

0 - sleep cloud

1 - fire wall

2 - antimagic

3 - stinking cloud

4 - ice wall

5 - blade wall

6 – quickfire

 

short is_object_on_space(short x,short y,short object_type)

Returns 1 if an item of type object_type is sitting on space {x,y}, 0 otherwise. The object types are:

0 - web

1 - barrel

2 - crate

3 - fire barrier

4 - force barrier

5 - ne/sw mirror

6 - nw/se mirror

 

short is_stain_on_space(short x,short y,short stain_type)

Returns 1 if a stain of type stain_type is on space {x,y}, 0 otherwise. Stain types are as follows:

0 - small blood

1 - medium blood

2 - large blood

3 - small slime

4 - large slime

5 - dried blood

6 - bones

7 - rocks

[Niemand]

Quote:

From what I can see the game will accept the inserted mirrors. My party was pushing mirrors around a town okay.

Excellent!

Quote:

my number scheme has no fields in it, there are only objects and stains.

Right, I was mis-categorizing the two barrier types as fields. This does, as you point out, make quickfire look like a longer shot, but mirrors are a nice addition. Happily, there's a nice little space where I can fit in buttons for them, too, in the Mac version's button palette. (I really need to make another attempt at rearranging the Windows version's layout to match, but it was such a dismal failure the two times I tried it before. So many changes desperately need porting.)

[Ishad Nha]

As for Quickfire, you may find inspiration in a save game file. Go into a town where there is quickfire and save the game.

Another approach is to try out values for field type, 60 at a time. So far this is not working.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

Another approach is to try out values for field type, 60 at a time. So far this is not working.

This sounds like the most reliable approach, if you can get it to work.

[Ishad Nha]

It will take about 1,000 separate iterations to test this, assuming that quickfire can be recorded in a bas file at all.

While we are at it we could have the boats and horses shown in the town display too.

BoA has space in the bas file for horse and boat records, a legacy from BoE. So the information could be recorded there. The data could be printed out in a form suitable for pasting into a scenario file, as create_boat or create_horse functions.

Simplest solution is to have the Editor read the scenario file the way it reads the scenario data file. It can look for create_horse and create_boat calls. Moving or deleting boats/horses will require a Reload Scenario Script function like the Reload Scenario Data Script function.

This won't handle boats and horses that only appear under certain conditions, like those in Exodus.

 

In Windows we could do with something that moves or resizes the rectangles used by special encounters, area names and town entrances. Apparently Niemand is having success with that in the Mac version.