Notus

The fixed version is uploaded on here, ---- deleded ----- As usual, this file only includes the application itself and modified sources (v1.0.2b1-b3). To run this version, "3D Editor Graphics" included in Isaac's original version is needed. I'll delete this link when Isaac releases the fixed version. ------ note ------- 3DBoAEditor_v1.0.2b3 Fixed "Import Town bug" Sometimes the imported town has different size from the original, map data (terrain, floor, height and light) are messed up. Modified Bl A Fileio.cpp import_boa_town() Fixed "Town: Corner Wall display in realistic mode" problem L-shape walls, NW, SW and NE (terrain number, 6, 7, 9, 42, 43, 45), weren't drawn correctly in the realistic mode. Their height of both wall were always 1 when one of a wall was cut away. Fixed this problem. Modified Graphics.cpp draw_terrain_3D() EdParser.cpp load_core_scenario_data() Added EdParser.cpp patch_corescendata2() Actually, the patch to EdParser.cpp is to correct the bug on corescendata2.txt ( see below ). This bug affects not only terrain 6, but terrain 7, 42 and 43. And because of this bug, NW corner wall display in realistic mode becomes odd. It's better to fix this bug on corescendata2.txt itself, but it may cause unpredictable errors on the BoA Game. For this reason, correct them on EdParser.cpp. corescendata2.txt begindefineterrain 6; // nw wall te_which_icon = 5; te_ed_which_icon = 4; te_cutaway_which_sheet = -1; te_full_move_block = 0; te_full_look_block = 0; te_blocks_view_e = 0; // this line is needed te_move_block_n = 1; te_look_block_n = 1; te_blocks_view_n = 1; te_move_block_w = 1; te_look_block_w = 1; te_blocks_view_w = 1; 3DBoAEditor_v1.0.2b2 Withdrawn because of a bug. 3DBoAEditor_v1.0.2b1 "Dialog Button fix" changed mouse click behavior on dialog buttons to prevent accidental click on the editor screen when the dialog is dismissed. Modified dlogtool.cpp: cd_process_click(), cd_process_keystroke(), cd_press_button() global.h: prototype of cd_press_button() Added dlogtool.cpp: cd_process_mousetrack() -------------------

It reproduced on the Resistance Cave (#4) on APF. Once it is reproduced on the debugger, it can be traced [EDIT} OK, I catch it. On import_boa_town() (Bl A Editor.cpp) switch (scenario.town_size[which_town]) { should be switch (temp_scenario.town_size[which_town]) { Dahak, you are very close to the cause, the culprit is the first line you've quoted!! After checking no other cause, I'll post both fix.

Quote: Case for the large towns seems incomplete. It's OK. On the case for the large towns, the imported data is loaded directly to t_d. In other cases, the data is loaded to ave_t or tiny_t once and transfered to t_d. This handling is needed because the array sizes are different in two dimensional arrays, terrain, floor, height and lightning. Quote: but all others released have trouble I see, I'll check it.

"Import Town bug": Dahak, Can you specify exactly which town of which scenario causes this error? I found one potential cause on import_boa_town() (Bl A Editor.cpp). This routine lacks kludge_correct_old_bad_data(), on the other hand the original, load_town(), has this routine. This explains imported terrain map may have illegal data, but the town size, height, floor and lighting map are irrelevant to this routine. Another cause should exist, but I cannot reproduce it. "Town: Corner Wall display in realistic mode" Finished fix and checking now. I'll post it afterward.

Aaah... Sorry, check was not enough. I was too much in hurry to release the version, as I wanted to finish this problem in the last weekend. The bug I newly introduced doesn't hurt the data loaded, only messes up display. Withdraw v1.0.2b2 and repost v1.0.2b1 until this newly introduced problem will be fixed, maybe in this weekend. -- deleted -- The bug fix on "corescendata2.txt" is still effective for the NW corner wall display on v1.0.2b1.

Dahak, Please check "Town: Corner Wall display in realistic mode" fix. The fixed version is uploaded on --deleted because of another bug. As usual, this file only includes the application itself and modified sources (both in v1.0.2b1 and b2). To run this version, "3D Editor Graphics" included in Isaac's original version is needed. I'll delete this link when Isaac releases the fixed version. This problem was twofold. a) A routine that handles cutaway (Graphics.cpp: draw_terrain_3D) sets height to 1 on both walls of L-angle shape. A bug was found in Terrain #6 (NW angle wall) definition, on corescendata2.txt But why BoA can display NW and SW wall correctly? Maybe it is fixed in the application. ------ note ------- 3DBoAEditor_v1.0.2b2 Fixed "Town: Corner Wall display in realistic mode" problem L-shape walls, NW, SW and NE (terrain number, 6, 7, 9, 42, 43, 45), weren't drawn correctly in the realistic mode. Their height of both wall were always 1 when one of a wall was cut away. Fixed this problem. Modified Graphics.cpp; draw_terrain_3D() corescendata2.txt begindefineterrain 6; // nw wall te_which_icon = 5; te_ed_which_icon = 4; te_cutaway_which_sheet = -1; te_full_move_block = 0; te_full_look_block = 0; te_blocks_view_e = 0; <-- add this line te_move_block_n = 1; te_look_block_n = 1; te_blocks_view_n = 1; te_move_block_w = 1; te_look_block_w = 1; te_blocks_view_w = 1; ------------------- [Edit] typo

Umm.. Isn't it mouse hardware trouble? I remember you are using a note. Dust may be filled the gap between mouse button and the body. I checked the revised version on a Powerbook also, it worked as I intended. If you have an external mouse, or you can borrow it from your friend, please check it connecting another mouse. "Town: Corner Wall display in realistic mode" problem Thank you for your example. I realized it exactly. Silly me, I tried it on surface. I'll look in it this weekend. [Edit] This problem appears both in dungeon and surface.

Dahak, Please check "Dialog Button fix". The fixed version is uploaded on --- deleted --- This file only includes the application itself and modified sources. To run this version, "3D Editor Graphics" included in Isaac's original version is needed. I'll delete this link when Isaac releases the fixed version. ------ note ------- 3DBoAEditor_v1.0.2b1 changed mouse click behavior on dialog buttons to prevent accidental click on the editor screen when the dialog is dismissed. Modified dlogtool.cpp: cd_process_click(), cd_process_keystroke(), cd_press_button() global.h: prototype of cd_press_button() Added dlogtool.cpp: cd_process_mousetrack() ------------------- As for the "Town: Corner Wall display" problem, can you email a simple example to me? My address is notosaurai_AT_yahoo.co.jp Please replace _AT_ to @

Thank you for the precise description. As the handling routine of the dialog button is common to every dialog, this problem may be found on another dialog. In other applications, you'll find the dialog button respond when you release the mouse button on the same button you clicked. You can cancel mouse click to a dialog button with moving out mouse cursor from the dialog button without releasing the mouse button. It's the ordinary dialog button response. Nowadays, we never code the dialog button handler directly, because plenty of GUI gadget is provided by the system or other framework. But in old days, the age of SE30, we sometimes made it by ourselves.

Ya, a little vague. Please describe as follows. Selecting "Outdoors" menu > "Load Different outdoor section", a confirming dialog with "Open", "Cancel" and "Save" button appears. In this dialog, clicking on the one of the button, such as "Cancel" dismisses the dialog immediately and draw a terrain to the edit screen just under the button. and so on. It isn't reproduced on my system, but I found the mouse click to dialog buttons responds on the mouse down, not the mouse up. It is bad design for a dialog response. As the dialog code is Jeff's original, this problem should be found on both platform. I'll look in to change the dialog response to the ordinary one. It'll fix your problem.

Thanks. The modification you made has been imported to the appropriate part on the Jeff's Windows version, including resources. Now converting Mac Carbon API to the equivalent Win API, preserving logic you made. Currently it is about 20% or so from the lines I converted to Windows. But the Graphics.cpp, the core part, remains still untouched.

Hi Isaac, Please wait a little more for the reorganized code. I found priority to port your excellent work to Windows. Windows users should be able to wait no more But the actual reason is that the Windows code doesn't immerse so much in Win API than Mac code does in Carbon API. It's suitable for the common code base. I compared your 3D editor code with Jeff's original line by line (of course using file compare utility), and extracted the modification you made. It was almost 80-90 blocks, though some blocks contain only one line and others have a several hundreds lines. Jeff's original BoA Editor for Win had already been ported to MS VC++.NET2003. Now I can start the actual porting work. It may take a several weeks, but programmer's estimation is always uncertain as you know. After the windows port, I'll return to the code reorganization for both platform.

Dahak: Thank you for testing the bug fixed version. Checked all compiler warnings and detected these two bugs only. Currently working on code reorganization and preparing for the Windows port.

I found next minor bugs on "3D Blades of Avernum Editor 1.0 for Mac OS X" Bug fix a) handle_action() (EdFcns.c) if(clean_up_from_scrolling()) return; // this line should be 'return are_done;' This code is found twice in handle_action(), both should be fixed as above. Fixed - This bug causes an occasional application quit triggered by scrolling to the other section on outdoor. Just Dahak reported as "Scroll & Crash" in "Betatesters for 3D Blades of Avernum Editor!" handle_ter_spot_press() (EdFcns.c) short current_terrain_type; // this line should be deleted This declaration shadows global variable of the same name, which is used in handle_keystroke() Fixed - The keyboard shortcut (a-z key) for custom terrain selection set by "te_shortcut_key" works correctly. This bug is also found in the original Jeff's code (v1.1) Dahak, Please check on "Scroll & Crash". The fixed version is uploaded on --- deleted --- To run this version, "3D Editor Graphics" included in Isaac's original version is needed. I'll delete this link when Isaac releases the fixed version. As for MacOS 9 support, compiling it with CodeWarrior will give a simple solution. [Edit] deleted the link

Congratulation again!! Perfectly works.

Yes, in the uploaded version, only "Bl A Editor.cpp" is changed. Any other file and compiler switch is not touched. My environment is Xcode 1.5 and November2004GCCUpdater on MacOS X 10.3.6.

Hi Isaac, I'm glad I can help you. I know this kind of bug is the most difficult one to find out by oneself, because one who made the change has no suspicion on that change. Most of bugs we are stuck have this character. If you'll continue to develop the code, I can help you hereafter. But if you want to take a rest, I'll wait for you until you recover. I'll reorganize the code totally, but it takes...a several months. It may be easy to write it from scratch if we know the feature clearly, but the feature is the code itself. Anyway, congratulation for ver1.0 !! Hi Infineon, The port to the Windows is almost impossible until the source is reorganized. In this code, Mac Carbon API is scattered here and there. Simple replacement to the equivalent Win API doesn't work. Jeff could do it because he knows the feature perfectly(?). One possible way is to extract the change Isaac made and apply it to the Windows version Jeff made. It is still hard work too.

Hi Dahak, Thank you for testing the extra-terrain fixed version. Unfortunately the scroll / crash error is not reproduced on my system. I think it may relate to the potential bugs that the compiler warnings suggest, because the reproduction is unstable. Anyway, I’m now working to fix that potential bugs. After finishing it, I’ll ask you to check the scroll / crash error is fixed or not. It may take a several weeks because I can work on this program only on weekend.

Thank you Kelandon, The bug is caused because Isaac accidentally reversed the order of the event handler. What I've done is finding out this and recovering it to the Jeff's original on that part. Isaac might have some reason to do this and I want to know it. I'll wait him patiently. If I could help him before he lost his interest on this excellent tool. I know a bug that cannot be fixed makes us exhaust so much. I hope this fix may make him recover his interest. Until he responds, I'll look in the potential bugs that the compiler warning suggests. It'll take fair amount of time to fix them because it needs fully understanding Jeff's code.

First of all, sorry for double post. I sent a message to Isaac, but he seems not to be aware of it. I know it's better for him to finalize it by himself, but old man is impatient. Dahak and Kelandon, May I ask you to check the bug fix is effective or not on your system? I checked it on my system, but I want to know it is good on other's. I uploaded the modified file on the next URL. ---- deleted ----- This image file contains next two files - 3D Blades of Avernum Editor v0.12b3 - modified editor execute file - Bl A Editor.cpp - modified code The modification is only the part I mentioned on my previous post. This image file doesn't contain any other file that is necessary to run the 3D BoA editor, such as "3D Editor Graphics". So Isaac's original set, "3D Blades of Avernum Editor v0.12b2 for Mac" is needed to run it. I'll delete this link when Isaac releases the fixed version. - deleted

Huh, only ten years! I have programming experience of almost thirty years. Anyway, the length of the experience is not a matter. Even if it is only one year, you can write it in better programming style. a) Overuse of global variables Most of them should be handled by subroutine parameters Copy-Paste programming style Make it a subroutine. c) Improper subroutine size His subroutine size is too large or too small. Large one should be divided to several subroutines. And many similar small subroutines should be combined using a parameter. d) Magic numbers Which one is comprehensive, "event.what != 23" and "event.what != kHighLevelEvent" e) Ignoring compiler warning Next warnings suggests potential bugs. 'yyy' might be used uninitialized in this function (occurrence 14) assignment of negative value '-1' to 'unsigned char' (6) comparison is always true (or false) (10) too many arguments for format (1) return-statement with no value (2) [EDIT] typo

Hello Isaac, Thank you for the excellent tool. I think I could figure out the cause of the trouble on the 3D BoA Editor v0.12b2, that Dahak and Kelandon pointed out. On the event handler, Handle_One_Event() (Bl A Editor.cpp), the flag "mouse_button_held" is raised by Mouse_Pressed() when the town mode is on. This makes handle_action() activate within the same click. Moreover, as the "event" is a global variable, "event.where" is converted by GlobalToLocal() twice. That is the reason the second drawing falls on another position. The bug fix is as follows. Simply return to the original on this part. Code: void Handle_One_Event(){... WaitNextEvent(everyEvent, &event, SLEEP_TICKS, MOUSE_REGION); if ((mouse_button_held == TRUE) && (event.what != 23) && (FrontWindow() == mainPtr)) { GlobalToLocal(&event.where); handle_action(event.where,event); } switch (event.what) { case keyDown: case autoKey:.... I respect you so much as you could decipher this spaghetti code. I always suffered headache during tracking this code with debugger. If JV could practice on coding technique a little more, his productivity would remarkably increase because he could do without spending so much time on bug fix. And we can play many more splendid games [EDIT] Sorry, mistook v0.12b2 as v0.12b1