New Windows 3D Editor

[Ishad Nha]

"You could try GetKeyState() instead of GetAsyncKeyState(); this function works in exactly the same way. I have no idea whether it will get a different result though."

MSDN says:

"The key status returned from this function changes as a thread reads key messages from its message queue. The status does not reflect the interrupt-level state associated with the hardware. Use the GetAsyncKeyState function to retrieve that information." So presumably they both work in the same way.

 

Latest ideas:

Split up Hintbook mode into grid mode and hintbook mode, so they now work independently of each other. Grid mode only handles the gridlines while hintbook mode handles display of monsters, items and fields.

See if async state function will enable the use of keys 1 thru 0, last time I tried this it interfered with the numerical keypad number keys.

Edit:

A quick test showed that(wParam == 0x30)works in enabling the 0 key to be activated without conflict arising with the Numpad 0 key. Ditto 0x31, the 1 key. So we won't need to use GetAsyncKeyState.

This means that we can now use the ten number keys where we could not before.

 

Edit:

The new values for hintbook mode:

0x31, 1 key, Hintbook mode 1: show all

0x32, 2 key, Hintbook mode 2: show nothing

0x33, 3 key, Hintbook mode 3: show monsters only

0x34, 4 key, Hintbook mode 4: show items only

0x35, 5 key, Hintbook mode 5: show fields only

 

[Ishad Nha]

Hintbook Mode has been really rewritten.

Pressing the "1" key activates Hintbook mode 1...

1 key Hintbook mode 1: show all monsters, items, fields, floor and terrain.

2 key Hintbook mode 2: show no monsters, items or fields.

3 key Hintbook mode 3: toggles the display of monsters on and off.

4 key Hintbook mode 4: toggles the display of items on and off.

5 key Hintbook mode 5: toggles the display of fields on and off.

6 key Hintbook mode 6: toggles the display of floor on and off.

7 key Hintbook mode 7: toggles the display of terrain on and off.

 

Items are never displayed in medium view.

Items and fields are never displayed in small view.

Fields are crates, barrels, webs, force barriers and fire barriers.

In case 6, when the usual floor is toggled off it is replaced by floor type 254, enabling customization of what is then displayed.

This also applies to 3D mode.

 

Gridlines now have their own mode.

I will introduce two grids, one for one square grids and for four by four grids.

 

[Ishad Nha]

It seems that the medium view display of monsters, and fields needs to be refreshed every time you move the view, just hit the '1' key. Apart from that the new zoom level seems quite functional.

[Niemand]

Rather than, making the user press a key repeatedly, allow me to submit that you ought to figure out the proper method to ensure a redraw, and use it. If it would help I can take a look and try to figure out where that normally happens so that you can make sure you also call it in your added mode.

 

That being said, I'm a little baffled as to the motivation for a lot of these additions. Why would I ever not want floors drawn? How do your modes 2, 3, 4, and 5 interact, and is this interaction obvious enough not to confuse and annoy users? Keyboard shortcuts are great ways to make a familiar user interface quick to use, but they are terrible for users' ability to discover the interface's capabilities, especially when they exist only hard-coded in the event handling routines, without appearing in places like menus at all. In my opinion the editor has way too much of this going on already on both platforms, such that there were capabilities I didn't discover until I read the code, and that I would guess many users will never find (and remember how to deliberately access) at all.

[Ishad Nha]

Problem with the need to redraw was solved a few hours ago.

As for the floors, mode 6 was done more for completeness sake, someone may find a use for it.

Mode 2 stops all display of monsters, items and fields. It is normally off by default. Modes 3,4,5 work independently of each other, have no interaction with each other at all.

The help file that I enclosed with the Variant Editor should answer the questions concerned, especially after I re-wrote to make it more comprehensible to people who don't read every post in this forum.

[Celtic Minstrel]

There is seriously no reason to not display floors; I would not even add it for the sake of completeness. It's like we have an image in Photoshop with various layers, and are printing it out with various combinations of layers shown/hidden. Mode 6 is like saying "let's have a version without the paper".

[Lilith]

Actually, I can think of one reason not to display floors: if your scenario had item or creature graphics that intentionally blended in with some floor types so they were hard to see, it might be useful to turn off the floors to make sure you'd actually placed the items where you wanted them.

[Celtic Minstrel]

Hm. You actually have a good point there.

 

However, maybe we could just have the background pattern show through when floors are hidden?

[Ephesos]

Originally Posted By: Lilith

Actually, I can think of one reason not to display floors: if your scenario had item or creature graphics that intentionally blended in with some floor types so they were hard to see, it might be useful to turn off the floors to make sure you'd actually placed the items where you wanted them.

Yes, but then you can re-paint the floors for a moment. Hard-coding this kind of functionality into the editor seems superfluous.

[Slawbug]

I thought the reason not to display floors, was in case unusual juxtapositions of terrain height would lead to a few tiles of high floor blocking your view entirely of a lower floor tile.

[Ephesos]

Yes, but that doesn't actually help because you still can't click on the hidden tile.

[Slawbug]

D'oh!

[Celtic Minstrel]

That's what the non-3D view is for.

[Ephesos]

And in the 2D view, seeing items isn't a problem.

[Ishad Nha]

While I am at it, I can include the display of special encounter numbers. To avoid possible overlap from more than one encounter being in a given area, I can look at the upper left corner of the rectangle only.

This will be helpful in porting BoE scenarios, where all placed encounters occupy only one square anyway.

It can be done by printing the number of each state or by displaying a graphic with the number already written on it.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

While I am at it, I can include the display of special encounter numbers. To avoid possible overlap from more than one encounter being in a given area, I can look at the upper left corner of the rectangle only.

I can't see this being hugely useful, but it might sometimes be helpful.

Originally Posted By: Ishad Nha

It can be done by printing the number of each state or by displaying a graphic with the number already written on it.

The first, obviously. You only do the second if you want either a really fancy font or are working on a system that doesn't have a way to handle fonts.

[Kelandon]

Originally Posted By: Celtic Minstrel

Originally Posted By: Ishad Nha

While I am at it, I can include the display of special encounter numbers. To avoid possible overlap from more than one encounter being in a given area, I can look at the upper left corner of the rectangle only.

I can't see this being hugely useful, but it might sometimes be helpful.

If I understand this correctly, I like it.

[Ishad Nha]

Two approaches are possible here:

print the number of the special encounter in the square that has the upper left corner of the rectangle, if the encounter covers more than one square.

make the border line of the encounter color-coded, this is within my current programming ability and will be visually less intrusive. (Resistors have a color coding scheme that I can borrow.)

[Celtic Minstrel]

I fail to see how the colour-coding would be effective, so I'd say go with the number. If there are multiple numbers needed, because multiple encounters have the same top left, you could do something similar to what is done when a single space has multiple small icons. (By small icons I mean the ones that show that a terrain script is on the space, and other stuff.)

[Ishad Nha]

So far I am having no luck with the numbers. I get the one number appearing all over the screen. Generally graphics are not a success story in my programming.

Resistor codes do have a mnemonic, "Bad boys ruin our young girls but virgins go willingly" or something. I learnt it in Electric Shop.

[Celtic Minstrel]

If you can't do it right, then don't do it.

 

The trouble with the colour-coding is that there's a very limited set of colours you could choose from, and it's simply not enough to represent the number of states available.

[Niemand]

Quote:

The trouble with the color-coding is that there's a very limited set of colors you could choose from, and it's simply not enough to represent the number of states available.

More to the point, there are a rather limited number of colors that the user will be able to distinguish by eye. Yes, you could then use a positional notation like the resistor coding system, but please don't. I hate having to read the values of resistors (a problem made worse by the manufacturers using poor quality paint with muddy colors), and I don't want to have to learn a color scheme just to tell which state a special rectangle connects to. I would argue that the way to do the job right would be with some kind of mouse-over or selection information, but the current editor architecture just isn't suited to either, as it doesn't handle (and I for one am leery of bolting on) a mouse movement tracking, and it has no concept of selecting a special rectangle.

In a ground up rewrite of the editor, I would definitely push for a more object-oriented treatment of special rectangles. Let them be selected, and let the user manipulate their position and boundaries rather than having to delete and recreate them, more like the way vector-based drawing programs handle shapes. Some of this might be possible in the current editor; I'll have to look at how much monkeying around with its selection and mode model would be required. Specifically, I think it might be possible to allow selecting a rectangle, much like selecting a creature or item, so that properties like its connected state would be easy to view and change. Letting the user redefine the bounds directly with the mouse would be hard, but at letting them at least view and set the boundary coordinates would be a reasonable compromise.

[Ishad Nha]

Color coding would serve at least one purpose, enabling you to tell at a glance if two special rectangles call the same special state or not. Very useful in porting BoE scenarios.

Coding is off by default.

Edit:

I have added the usual rectangles for special encounters, info rectangles and town entrances to medium view. I will add them to small view too. They can be toggled off.

 

I have found that there is no barrier to putting placed specials with numbers like 131 or whatever. Is this meant to be the case?

[Celtic Minstrel]

What's wrong with a placed special with numbers like 131?

[Ishad Nha]

The Editor displays a dialog telling you that the placed specials must lie within the range 10 thru 99 inclusive. The documentation says the same thing.

Here the deciding factor should be what the game itself considers legal. I will have to research what numbers the game will accept for the called states of placed encounters.

Edit:

A placed state of 150 is okay but not 200. I will need to pin this down further.

Not only that, there reserved states around 100 and 110: 100 thru 102 and 110 thru 114.

 

Using Word and Excel I was able to quickly produce a town script with states 90 through 255. I will now need to place specials in a town and see which are activated.

As I recall, someone checked this once but the result was never written into the Editor dialogs.

[Celtic Minstrel]

Okay, what exactly is it that these numbers represent? Is it, as I thought, the number of script states? (ie the number in "beginstate 42;"-type statements) Or is it something else?

 

Originally Posted By: Ishad Nha

Edit:

A placed state of 150 is okay but not 200. I will need to pin this down further.

Not only that, there reserved states around 100 and 110: 100 thru 102 and 110 thru 114.

That seems like an odd set of limits. And what do you mean by reserved states?

[Ishad Nha]

Yes, the number in beginstate ###.

Reserved states are the special purpose states like Sanctification State, Search State&

State 190 worked okay, so Jeff may have set 200 as the limit.

[Celtic Minstrel]

It's quite possible, though it's odd he would choose 200 rather than 256. Then again, he has done similar odd things in the past (for example, maxing out gold at 30000 instead of 32767).

 

Also, most of the reserved states have special meaning only in certain types of scripts. Not sure if that's relevant in any way though.

[Ishad Nha]

I figure the reserved states from 100 thru 114 would not occur in town and outdoor scripts.

But before I alter the Editor dialog to encourage the use of town/outdoor states with the same number, I might want to confirm that that won't lead to conflict between reserved states and town/outdoor states having the same number.

Jeff did have a limit of 200 towns rather than 255, so the limit for placed specials may be 200.

[Celtic Minstrel]

It shouldn't lead to conflicts.

 

As for the limits thing, the number of towns limit is quite a different sort of limit than the state number limit. The former is his arbitrary choice for the size of an array (so, you couldn't store more even if you wanted to), while the latter requires him to actively force the state numbers not to exceed the limit (the relevant variable would be able to hold at least as much as 255).

[Ishad Nha]

The new medium view mode has been finished, it is now available from the Variant BoA Editor link. Usually you can't move past the edge of the map while in medium view. But this can be overridden by the 0 key, thus outdoors you can travel over zone boundaries while in zoomed-out view.

I also changed the display of outdoor zones to show the zone numbers, which are used in the call "current_out_section()".

Now I will have a look at the placed specials and see what the score is with them, what numbers will the game accept. In BoE you could only place specials with numbers 0 thru 99 because there were only 100 specials in the towns. Maybe the comment in the BoA help file about only placing specials with numbers 0 thru 99 is a holdover from BoE.

 

Edit:

Using a specially written town I found that: the specials can be placed up to number 199. If you place a special with a number greater than that you get the message "Error: Accessed a town special state out of range.".

This will need to be reflected in a rewrite of relevant parts of the Editor.

[Celtic Minstrel]

And is that limit the same for the outdoors? (No reason for it not to be, but we might as well check.)

[Ishad Nha]

Yes, the outdoors, I will whip something up and have a look. Outdoor specials are short while town specials are char, don't know why.

Edit:

Good thing you thought of that, in the outdoors the specials cut out, cease to work, at 100 or higher. The square becomes impassable at numbers around 200.

[Ishad Nha]

Now I have inserted blocks to stop out of range special numbers. Error messages are given as strings, this leaves the dialog box open for a correct answer.

I have been able to get the Cancel button to work. Function short edit_special_num(short what_start) was returning what_start for Cancel not -1. Variable what_start is the default value, always valid too.

 

Edit:

Save checks have been placed into the Ctrl + Arrow key functions.

Placed specials can now be cancelled, the Cancel button in the dialog for placing special encounters will now actually work.

Added note to the relevant dialog about Cancel removing an existing placed special, dialog 825. (Also added a note that you may be able to use numbers as high as 199 in towns.)

Added note about Cancel removing an existing town, dialog 856. Also suppressed the Choose option in loading a new town, it currently does nothing.

First step in allowing the customization of town names and script names during porting. Token names have been added, they can be hex edited into something more suitable.

 

[Niemand]

Quote:

Also suppressed the Choose option in loading a new town, it currently does nothing.

It shouldn't. It should be put back and and correctly connected to the mechanism to choose a town by name. It may be that that wasn't working yet because the loading function(s) need to be extended to collect the town and outdoor section names, if I remember correctly.

Quote:

First step in allowing the customization of town names and script names during porting. Token names have been added, they can be hex edited into something more suitable.

This is not a good solution. What exactly is even the problem you're trying to solve here?

[Ishad Nha]

If you port any BoE scenario you will some problems with the names, BoE had unlimited length for names, 255 characters, while BoA has a smaller limit: 19. Port any scenario and you will see what I mean.

Ported script names are frequently a bit of a mess, they are truncated if they exceed the mandated length. If I was porting I would want to go through them and tidy them up. Make them look better, clear up any repeated names&. If this were done in a spreadsheet you could translate them into hex digits.

Script names are likely to contain spaces, which will have to be removed before you can use Alint.

 

Town names, I will see what I can do. In dialogs 855 and 856 I just commented them out. There is no set dialog in Windows, they are called as a clause of get_a_number(), here is the code:

if ((which_dlog == 855) || (which_dlog == 856) ){

cd_get_item_text(which_dlog,6,(char *) temp_str);

sprintf((char *) str2,"%s (0 - %d)",(char *) temp_str, (int)(scenario.num_towns - 1));

csit(which_dlog,6,(char *) str2);

}

Clearly there is no connection to item 7 which is the Choose function. Reading the load names function, my programming is pretty basic, it looks like they are printed to a file.

They are already printed in at least one query file, so it is not a pressing concern.

[Niemand]

Quote:

If you port any BoE scenario you will some problems with the names, BoE had unlimited length for names, 255 characters, while BoA has a smaller limit: 19. Port any scenario and you will see what I mean.

Okay, but compiling a list of names into the executable is utterly the wrong way to solve this. We already have too many horrible hard-coded arrays of poorly documented data in the program. The obvious way to do this is to let the user write a plain text file with the desired name data, read the text file and apply the parsed names during conversion.

Quote:

Script names are likely to contain spaces, which will have to be removed before you can use Alint.

Alint shouldn't care about a script's name.

Quote:

Town names, I will see what I can do. In dialogs 855 and 856 I just commented them out. There is no set dialog in Windows, they are called as a clause of get_a_number(), here is the code:
if ((which_dlog == 855) || (which_dlog == 856) ){
cd_get_item_text(which_dlog,6,(char *) temp_str);
sprintf((char *) str2,"%s (0 - %d)",(char *) temp_str, (int)(scenario.num_towns - 1));
csit(which_dlog,6,(char *) str2);
}
Clearly there is no connection to item 7 which is the Choose function. Reading the load names function, my programming is pretty basic, it looks like they are printed to a file.

I don't quite follow what you mean here. The infrastructure that we have is that load_all_town_names() is used to put town name data into the global zone_names variable, which is then accessed by (the poorly named) get_str(), which is in turn used by put_text_res() and choose_text_res(). However, I'm not sure whether the data collecting functions, like load_all_town_names(), are called at all at the moment, as they are intimately related to the file loading functions, which need, I think, some minor reorganization.

[Ishad Nha]

Reading files is an area of programming that I have yet to deal with, I have not done it before. Most of the work is in sorting out the lengths of names and script names. Hex editing only takes about a minute. I may find time to look at reading the files.

"Alint shouldn't care about a script's name."

Alint will not read file names with spaces in them.

C:\Program Files\Blades of Avernum\Data\babayaga.bas>alint -w t99 Fungus Ga.txt

File 't99' does not exist

File 'Fungus' does not exist

File 'Ga.txt' does not exist

(But apparently the file will be read if you use the read all text files option: "alint -w *.txt".)

"I don't quite follow what you mean here."

What I mean with the dialog is that item 7 in both 855 and 856 is the Choose function, it is not supported in the code I showed above. There is no direct way of calling the town names. The indirect method you mentioned I will have to chase up.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

Reading files is an area of programming that I have yet to deal with, I have not done it before.

Oh, come on. If you haven't done file reading before and you embark on a project that requires file reading, the correct course of action is not to hard-code all the data. The correct code of action is to learn how to read files.

Go on, then.

Originally Posted By: Ishad Nha

"Alint shouldn't care about a script's name."
Alint will not read file names with spaces in them.
C:\Program Files\Blades of Avernum\Data\babayaga.bas>alint -w t99 Fungus Ga.txt
File 't99' does not exist
File 'Fungus' does not exist
File 'Ga.txt' does not exist
(But apparently the file will be read if you use the read all text files option: "alint -w *.txt".)

That's because you don't seem to understand how the Windows "shell" works. If a file has spaces in it, you need to quote the filename, like so:

Code:

C:\...> alint -w t99 "Fungus Ga.txt"

Incidentally, the same applies if the program name has spaces (you need to quote the program name).

At least, I think that should work; I'm not 100% sure.

[Ishad Nha]

Quotes do work, though the name looks a bit ugly. Anyway, the provision to use the original method is still there. Now I have to chase up a ton of errors in the ported files.

Edit:

Most of the systematic errors have been fixed. Problems with my faulty alteration to message dialog were one cause. Three remain as key causes of errors in scanning by Alint:

A frequent problem is that "action = Inn ..." should occur on a line of its own and it does not, for whatever reason. This will give an error when the file is scanned by Alint.

Quotes must be converted to _underscores_ if they occur inside a string.

An "error" is that BoE scenarios frequently had scenario states numbered above 100, Alint will treat this as an error.

[Ishad Nha]

First problem is coming from me using "add_string_to_file" instead of "add_string".

Second problem could be cured by using get_bl_str.

Third problem can't be solved without recompiling Alint itself.

 

Not all problems can be neatly solved.

Dialog case 24: // buy town location is one example. There is no immediate way to ensure that the information has not been already bought. The BoA code uses a non-existent function, get_town_visibility, so the "solution" won't work in actual practice:

add_big_string_to_file(file_id,"\t\tif (get_town_visibility(",boe_talk_data.talk_nodes[which_node].extras[1],"",-999,"",-999,") > 0)");

The only real solution is to use a SDF, this can't be neatly written into a program.

 

Worst hassles come when BoE expects that the entire party will occupy only one square indoors or when move to new town is called from anywhere except a placed special.

 

Edit:

I had to devise a custom version of get_bl_str, just to handle the special item strings. This is the original function used:

Click to reveal..

//str_type: 0 - scenario, 1 - town, 2 - outdoor 3 - dialogue

void get_bl_str(char *str,short str_type,short str_num)

{

if (str_num < 0) {

str[0] = 0;

return;

}

switch (str_type) {

case 0: strcpy(str,boe_scen_text.scen_strs[str_num + 160]); break;

case 1: strcpy(str,boe_scen_text.town_strs[str_num + 20]); break;

case 2: strcpy(str,boe_scen_text.out_strs[str_num + 10]); break;

case 3: strcpy(str,boe_scen_text.talk_strs[str_num]); break;

}

for (short i = 0; i < (short)strlen(str); i++)

if (str == 34)

str = '_';

}

Special Item strings are the scenario strings 60 thru 159. So to produce the correct number output, you have to take 160 away from the number you input. Which will leave it less than zero, hence blocked by the "if (str_num < 0) {… return" clause.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

Dialog case 24: // buy town location is one example. There is no immediate way to ensure that the information has not been already bought. The BoA code uses a non-existent function, get_town_visibility, so the "solution" won't work in actual practice:

Are you sure the function doesn't exist? Does it produce an error when you try to open it in the game?

[Ishad Nha]

Yes, the game won't accept get_town_visibility, it crashes the dialog script totally.

 

Now most scenarios are porting correctly but there are two crashing: Quest of the Spheres (halfway through the outdoors) and Wormwood (around town 26). I will put a default case in the port nodes function and see if that helps.

If all else fails, I can run the affected parts through a spreadsheet. This is where a spreadsheet is wonderful for data recovery, the original bas file just crashes when you try to examine the affected parts. Hopefully a spreadsheet will enable me to examine all the data and see if anything is wrong.

 

We will need a default case in the port a node function if the number of BoE nodes increases from the original 149. Which I think it already has.

[Ishad Nha]

The crashes in the porting of Wormwood.exs seem to come only from writing the town scripts. Once the writing of one town script crashes, the rest of the scenario is toast. There is no ability to go onto the next town.

One solution is to separate the script writing from the town writing. After the bas file has been fully written, towns are now opened a second time to write the scripts. This way at least the bas file gets written. I will try to write it so that if a script can't be written the program then tries to write the next script. Hence it will be immediately clear which scripts could not be written.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

Yes, the game won't accept get_town_visibility, it crashes the dialog script totally.

I think you should just leave it for now, but put a note somewhere (in the documentation, maybe?) explaining what's wrong. Or, if you do change it, keep the old code around so that you can revert to it in the event of the game being released as open source.

Originally Posted By: Ishad Nha

We will need a default case in the port a node function if the number of BoE nodes increases from the original 149. Which I think it already has.

I don't think it has yet, but it probably will; however, I don't recommend trying to make the porting code understand scenarios from the updated BoE. It would probably be easier to write a separate set of porting code for new scenarios. (Note though that new scenarios aren't yet implemented.)

[Ishad Nha]

Open BoE has a node type 28, "Display Picture" and a type 156, "Has enough of species?". The way porting currently works, one error crashes the entire process. For whatever reason, the town script for town 26 in Shadow Stranger can't be written. That means that the porting process stops dead there and then: no more towns are ported and no more scripts are written. In the 48 towns there is only one problem, town 26.

[Celtic Minstrel]

Don't bother with handling Open BoE scenarios at this point. Wait until the project has reached a stable state. Otherwise you'll just have to redo all your work anyway.

[Ishad Nha]

It will be a simple quick fix, a few lines of code to provide a default case to a switch. Here and now the editors have the two new node types in them.

[Celtic Minstrel]

Adding a default case is fine, of course (you should always have one to detect when things don't go as you expect), but don't even consider adding code to support the new node types. It will never be run, because by the time OBoE is stable, the new scenario format will be so different that you'll need an entirely separate set of conversion code.

[Ishad Nha]

Yes, I expect all sorts of massive changes. A new import function won't be too hard. I expect it can be handled with a new set of data structures and a new function.

 

I am still having trouble porting a few scenarios. I will add information to the return clauses to say exactly where the error occurred. Then I will add a dialog to stop the printing of scripts that crash, that way the error points can be quarantined.