New Windows 3D Editor

[Ishad Nha]

I made the changes you suggested, but only in Bl A Fileio.cpp. This time, Shadow of the Stranger produced only an exactly 4KB scenario file compared to the exactly 8KB last time. It crashed porting Special Item 14, at this phrase: "<Use> it to get past a particularly difficult situati".

 

On the other hand Valley of the Dying Things ported! Now I will have to figure out what went wrong with Wormwood and what is going right, what scenarios will port.

 

Edit:

Quotation marks will need to be inserted for BoA game scripting purposes, otherwise the scripts won't run. That is no big deal.

Why a Wormwood file of exactly 4,096 bytes?

[Celtic Minstrel]

Did VotDT port correctly though?

[Ishad Nha]

As far as I can tell, yes it did. There were errors, but they were due to various causes that can be rectified. I altered the printf fucntions in ways that were not helpful&.

 

Note that the translation tables for terrain, items and monsters need to be customized if there was any custom terrain in the original scenario.

[Niemand]

It sounds like what's needed is to have a first pass which reads the BoE scenario to find out what terrain, etc. definitions it actually uses and populates the tables with the ported definitions. Then the actual town and outdoor arrays of the scenario would be read and written in BoA form using the filled tables.

[Ishad Nha]

That is a good idea. Currently I load the data into a spreadsheet and compare it with the data for Bladbase.exs. Then I try to decide how to handle the custom objects: terrain, items and monsters. Most items will usually be the same as the standard varieties.

[Niemand]

So, you start with the tables filled with the data from Bladbase, only redefining an entry if the scenario in question explicitly overrides it. The idea is to do exactly what your spreadsheet does, but fully automatically. This is basically what both BoA and BoE do when actually loading scenario anyway, the trick is that we are not merely reading in and storing the definition data, but converting it into a different form; that is, we want to read BoE data but store BoA data for later use.

[Ishad Nha]

Graphics are one thing a program can't evaluate, they may be relevant to a good translation.

 

State of play is that VDT and Redwall ported okay but so far nothing else has, the score is 2:6.

[Celtic Minstrel]

Don't worry about graphics – just assign a temporary graphic to ported items, terrains, and monsters. Preferably the question mark graphic. Is there a question mark item graphic?

 

One thing to consider when porting terrain is, when do you map a BoE terrain to a BoA floor?

[Niemand]

Perhaps when it doesn't obstruct motion, assume it's a floor? This won't always be right, but it should be a reasonable first guess.

[Ishad Nha]

The best guess so far is: when it does not obstruct vision, thus BoE Clear, Clear-Special and Clear-Blocked types.

[Celtic Minstrel]

Yeah, I'd say it has to obstruct neither vision nor movement to be a floor.

 

And how is the porting mechanism supposed to know which terrain types are walls?

 

...Maybe terrain porting should be a little more interactive...

[nikki.]

Originally Posted By: Celtic Minstrel

Yeah, I'd say it has to obstruct neither vision nor movement to be a floor.

And how is the porting mechanism supposed to know which terrain types are walls?

The 2D Editor's porting tool can already do this.

[Ishad Nha]

The trouble here is that it is based upon Bladbase.exs or any other scenario without custom terrain.

 

My idea is to assign each terrain type a classification number, this can be read off an external file, that way radically customized terrain can be handled. Line 2,577 of the Bl A Fileio.cpp shows what other classifications will be needed.

[Niemand]

Quote:

My idea is to assign each terrain type a classification number, this can be read off an external file, that way radically customized terrain can be handled

Can you elaborate on this? What do you mean by a 'terrain type': The actual terrain definition, or the number which refers to the definition? (The line number you reference doesn't seem to explain much in particular.)

[Celtic Minstrel]

Originally Posted By: The Doctor

Originally Posted By: Celtic Minstrel

Yeah, I'd say it has to obstruct neither vision nor movement to be a floor.

And how is the porting mechanism supposed to know which terrain types are walls?

The 2D Editor's porting tool can already do this.

Only if you haven't edited the default walls.

Niemand: I'd assume he means assigning each terrain type definition a classification number, and I'd suggest probably one for floors, one for terrains, one for unadorned walls, one for closed doors, one for open doors, one for cracked walls, one for windows, and one for adorned walls. Or something like that.

But is it necessary to put them in an external file? Why not have the program ask the user during the porting process to specify what each terrain is (floor/wall/door/etc/other)?

[Ishad Nha]

The line number was taken from the unaltered Windows 3D source code of course.

 

Edit:

The idea here is to use the unaltered source code as a fixed reference system. Especially as Niemand and I have altered/are altering our own versions all the time.

Asking just before porting, as long as you have default entries for all 256 terrain types. In theory the first 91 were fixed but some scenario authors may have hex-edited them from time to time.

Progress in porting, two scenarios can be ported that could not be ported before.

 

Edit:

Spoke too soon, after recent alterations the situation is worse than ever, nothing ports properly. The source code still compiles, it is just that the compiled editor crashes every time that I attempt to port anything.

 

Edit:

I removed all references to scripts from the source code and then compiled it. Now I can apparently port everything, hence the problem must be in the scripts.

 

Now there are plenty of error clauses in the import boe scenario function, including the script generating functions. What triggers them?

 

Edit:

I have traced the error back to the special script states. I "commented out" lines 2,075 thru 2,079 (turned them into comments), this made sure that the port town dialog scripts function was not called. Then I commented out the port special nodes part in all the other scripts and they were all ported. Now any scenario can be ported, except for the scripts, which can be handled by the 2D editor.

 

Edit:

Town dialog scripts seem to be mostly okay. Only definite problem areas are the ports of the scenario / outdoor / town scripts that port the special nodes, the numbered states. These will cause a crash of the porting process.

[Ishad Nha]

Finally I can port any scenario without problems. Still need to fix the terrain customization. It is found at:

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

 

It is currently twice its proper size because it still generates debugging information even though I turned off that feature.

[Niemand]

I would suggest that we ask interested persons to help us out by checking to make sure that this version actually ports things correctly, treating it as sort of an alpha version. Once we're fairly convinced that it doesn't corrupt data we can handle details for neatening it up again towards a final release, like getting the debugging info properly turned off.

[Celtic Minstrel]

Is the advanced porting in the Mac version yet?

[Niemand]

None of Ishad Nha's changes have been incorporated into the Mac version yet. I first need to verify what problems the Mac version has with porting, understand the changes he made, and then merge them in. Unfortunately, I have a 6 hour exam tomorrow, so I'm a little short on free time to work on this at the moment.

[Ishad Nha]

Anyone with a Mac can do it. Does the thing port at all? Before the latest changes the Windows 3D Editor always crashed when I attempted to port anything.

 

If the Mac editor does not crash, port the same scenario using both the official Spiderweb 2D Mac editor and the latest 3D Mac editor. If you were not familiar with porting you might think that the 3D results were affected by data corruption.

 

Ditto, have people port the same scenarios using the official Windows Spiderweb 2D editor and my latest version. There will be differences, the 2D editor wrongly rotated the special rectangles in towns&

 

This bloated, blown-up-like-a-balloon editor is a just an annoyance rather than a serious problem.

[Niemand]

I took a break from studying and ran a few tests. Using a modified version of the Mac editor (1.0.7 + bleeding edge changes):

• Valley of the Dying Things: Ported without error.
• A Small Rebellion: Ported without error.
• The Zakhazi Run: Ported without error.
• Of Good and Evil: Ported without error.
• Falling Stars: Ported with many non-fatal errors; items beyond town boundaries, too many terrain scripts in individual towns
• At the Gallows: Ported without error.

I'll need to check which of these were in which platform's format; that may explain the trouble with Falling Stars and point to bugs. However, in all cases the resulting scenarios came out looking sensible, with the exception that custom terrains and so on are all messed up.

[Ishad Nha]

<p>Any monster, item or door beyond the BoE town boundaries will cause an error message during porting, I suspect the Adventurer's Club scenarios are the worst here.

 

Too many scripts error has two causes:

(1) customized terrain, some terrain number # is not a sign or a door in the Bladbase.exs but is in the given scenario

(2) the author used a few hundred doors in the one town.

Neither is an error per se.

 

Edit:

The porting function is based upon Bladbase.exs (or any scenario not having custom terrain, items or monsters) it is prone to the first error above if the terrain was customized. Hitherto I have just hex-edited the translation tables in the 2D editor, which are found at line 6,734 column 47 through line 6,768 column 2, when line width is 70 characters.

 

Edit:

I got rid of the bloating by moving all the files to another dev project. The undo/redo is inferior to the Latest 3D editor, probably due to muddled files and problems with me using Tortoise. I also corrected a problem with handle messages.

[Ishad Nha]

Item, terrain and monster translation is easy to hanlde in the scripts:

case 50: // give item

aa = old_item_to_new_item[node->ex1a];

add_short_string_to_file(file_id,"\tif (reward_give(",aa,") > 0) {");

Terrain is a bit tougher, because BoE terrain translates as either BoA floor or terrain, so I give duplicate translations:

 

case 135: // ter is type, town

add_string(file_id,"\tif (is_town() == 1) {");

aa = old_ter_to_floor[node->ex2a];

bb = old_ter_to_ter[node->ex2a];

add_short_string_to_file(file_id,"\t// original value of the BoE terrain: ",node->ex2a,".");

add_big_string_to_file(file_id,"\t// if (get_floor(",node->ex1a,",",node->ex1b,") == ",aa,")");

add_big_string_to_file(file_id,"\t// if (get_terrain(",node->ex1a,",",node->ex1b,") == ",bb,")");

 

Idea here is to look at the original BoE terrain and see if a BoA floor or a terrain translation would be more appropriate, then discard the other translation. Comment marks are then removed.

 

 

 

[Niemand]

Glad to hear that you've got this figured out; your solution looks sensible to me. However, for the love of all that's good, please use descriptive variable names! How about 'new_floor' instead of 'aa', and so forth?

[Ishad Nha]

I economize on the number of variable names, "aa" is used for translation of everything: monsters, items and terrain.

 

The problem at the moment is getting the program to accept the new scheme of terrain varieties. Scheme is currently:

1 secret door

2 door

3 locked door

4 m locked door

5 impass door

6 open door

7 window

8 closed gate

9 open gate

10 cracked

11 Sign and wall

12 wall

13 road

14 bridge

15 floor

16 terrain

 

(Distinction between road and bridge is necessary to correct some problems in porting roads.)

The terrain variety variable is not a part of the terrain or floor classes in global.h, hence the program does not readily accept it. I can't get the roads to appear during porting.

 

Also something like "aa" is not going to be a pre-existing variable name.

 

Done, this is working in practice:

Boolean is_old_road(short i,short j)

{

ee = (short)old_ter_variety[boe_outdoor.terrain[j]];

if (ee == 13)

return TRUE;

else

return FALSE;

}

 

[Niemand]

The problem is that using bad names like that will make life hard for everyone; anyone (like me) who tries to read the code right now will find it confusing when a variable has a meaningless name or if it is used for more than one purpose. In six months, you yourself may find it confusing too.

 

Keep in mind that this is not Avernumscript; you can have as many variables as you need, and clarity of the code is an important goal along with correct functioning. If you are worried about shadowing an existing variable with the same name, just use your editor's search function to look for uses of that name. If the name's already taken, it's not too hard to think of another. Also, when you declare a variable you can always include a comment that explains in greater depth what the variable is intended to be used for.

 

With regard to your terrain classification system: Would you elaborate on how this is used? Suppose I have a BoE scenario which defines a terrain which blocks movement and sight, and happens to have a wall graphic. How will the porting system treat it?

 

Another stylistic suggestion: Your code fragment could be written more compactly as

Code:

Boolean is_old_road(short i,short j){  return(old_ter_variety[boe_outdoor.terrain[i][j]] == 13);}

I like to do it this way as it makes very clear what we are doing: returning whether a particular variable is 13. No need for a temporary variable or ifs and elses to muddle things.

[Ishad Nha]

Using the unaltered 3D source code as a reference:

it is concerned with "switch (boe_big_town.terrain[j]) {" as found on line 2,577. Likewise it is concerned with "is_old_road" and "is_old_wall". The idea is to create a table that can replace actual terrain numbers with categories. Once the category numbers are assigned in a table at the top of Bl A Fileio.cpp, there is no need for further alteration of the program. Ditto if you wish to port another, very different scenario, you could alter the table, if necessary by hex editing. (It currently starts at address 361,920) A better idea is reading an external plain text file.

 

Anything that blocks movement and sight would be treated as just wall for these purposes.

 

As for the translation tables

short old_monst_to_new[256] = {

short old_ter_to_floor[256] = {

short old_ter_to_ter[256] = {

short old_item_to_new_item[400] = {

my new scheme is not concerned with them per se. Translation would be handled by the current methods, spreadsheets and examination of graphics.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

Anything that blocks movement and sight would be treated as just wall for these purposes.

Be careful – surface trees also fit these requirements, at least in the default BoE base.

[Nicholas]

I downloaded, but cant find the thing that opens the editor! ):

[Ishad Nha]

If you can't open a zip file try right clicking on it when in Windows Explorer.

If you have the zip file opened, the Editor will only work in one folder: the BoA/Data folder. It runs independently of the BoA game itself but it needs the same graphics.

[Nicholas]

Ok. i downloaded the editor but i missing image 2000 and warriors grove?!?!?!?!

[Ishad Nha]

G2000.bmp is a graphic containing mostly buttons. Warriors grove is a bas file that should be found in the Data folder, the town script for this town should be found in the Starter Town directory. This should not be a problem affecting the 3D editor itself. Try the official 2D editor and see if you have the same problem.

 

Install the BoA game to another directory and see if the missing files turn up there. Official 2D Spiderweb editor can be found at:

http://www.avernum.com/blades/scen_workshop.html

[Kelandon]

I'm assuming this is Designer FAQ Q2.

[Nicholas]

Ishad i think im using using that editor already.

 

 

Edit: i should not even bother if i cant test a scenario.

[Ishad Nha]

Are both your editors, Spiderweb and 3D, hitting problems? If so it is a general problem, not just an editor problem.

[Ishad Nha]

New idea for the editor, use a BoE style eyedropper to enable selection of terrain by clicking the eyedropper on a given terrain type. There is a blank button in the fifth line, but it is of course a town-only button. Maybe the place terrain script button could be moved to the fifth line and eyedropper would be available for use in the third line.

[Niemand]

This is part of a major alteration I already made to the Mac editor. See OutdoorButtons and TownButtons to see how the function buttons are laid out in the current Mac version. (The extra graphic on the bottom row is not itself a button, of course, but the alternate version of the second in the second row.)

 

I definitely think that we need to make the same alterations to the Windows version. I have already put in the underlying code for most of the added tools (copy, paste, and flood-fill; the eyedropper's code is trivial), but currently there is no way for the user to access it. The necessary steps are:

- Split up the function buttons pane from the palette pane above it, rewriting all related drawing logic

- Replace the button graphics

- Rewriting the function button event dispatching logic to match the new tools and button icons.

The first step is where I got stuck when I tried this a while back, as I had no idea how to work with the Windows graphics library that the Windows editor uses, and had no documentation for it.

[Ishad Nha]

Fixing the graphics was a breeze, the BoE and BoA varieties are exactly the same size.

I just pasted in the BoE Scenario Editor code and there was no problem. I created a new overall mode of 73 to make sure that everything went smoothly. Currently it is only written for terrain but could be extended to floors and height.

case 73:

if (editing_town == TRUE)

set_new_terrain(t_d.terrain[spot_hit.x][spot_hit.y]);

else set_new_terrain(current_terrain.terrain[spot_hit.x][spot_hit.y]);

set_cursor(1);

overall_mode = 0;

break;

[Niemand]

Yes, the eyedropper is trivial, but we need to put in the larger changes I described to accommodate the other tools and eventually other other palettes (creatures and items). I think we should try to keep the two versions of the source code as similar as possible, also, with an eye toward merging them in the future. See http://svn.hallsofchaos.net/3D_BoA_Editor_Mac/trunk/3D%20Editor/Bl%20A%20Editor.cpp around line 100 for the Mac version's current list of drawing modes, and http://svn.hallsofchaos.net/3D_BoA_Editor_Mac/trunk/3D%20Editor/EdFcns.cpp for the implementation of the various added tools. (Aside: I implemented the eyedropper to pick up terrain and floor, but not height as that wouldn't be meaningful with the current implementations of the height related tools.)

[Nicholas]

Fix the problem.

[Niemand]

I assume that you mean the problem is now fixed?

[Ishad Nha]

Yes, if your last comment was addressed to me not Nicholas. Eyedropper works for both terrain and floors.

[Niemand]

No, the reverse actually, although that's good news also.

[Nicholas]

I hate the 2d editor i dont even know what is the wall!

[Niemand]

The 2D Editor (and 2D mode of the 3D Editor) denote walls with black or brown rectangles on the sides of the grid squares.

[Ishad Nha]

I didn't like the color scheme, it was too drab, so I changed the black walls in G690 bitmap to blue.

[Ishad Nha]

Porting BoE special nodes

Inconsistencies between the BoE Editor Help file and the game editing screens, I will probably go with the latter. Game authors presumably read the screen when placing the special nodes.

One case is type 209,

from the help file:

"Type 209: Cleanse Rectangle Removes all fields, walls, clouds, etc. in the rectangle.

Stuff Done 1: If 0, leave Fire and Force barriers, barrels, crates, and webs alone. If non-zero, erase them too."

from the game editing screen:

Case 209:

"Stuff Done A: Chance of placing (0 - 100)"

 

Now that I have the source code to the actual game I may be able to see what the game intended.

 

Edit:

Source code says that help file is right, strings.rc file needs to be altered. See official source code: specials.cpp line 2,800 and party.cpp line 2,388.

 

 

 

[Ishad Nha]

I have amended the Write Scenario Data to Text File function to include a list of the names of outdoor zones and towns. I was able to incorporate this into the BoE Zoom Editor but not into the 3D Editor, strange as both are based upon the same code.

This is meant to be the start of an ambitious attempt to create new tools for analyzing scenario data.

Edit:

3D Editor can be found at:

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

[Niemand]

I'm not sure why you were able to do this in one version but not the other (What stopped you?), but this will be easy to incorporate once I get the zone names list put in. On the other hand, I don't know if many people even use the text dump feature anyway.