3D Blades of Avernum Editor 1.0 for Mac OS X released!
Pages
| Author | Topic: 3D Blades of Avernum Editor 1.0 for Mac OS X released! |
|---|---|
|
Infiltrator
Member # 148
|
written Monday, January 17 2005 12:11
Profile
ALL Terrain (only terrain) in 3D edit mode show 4 copies of the original floating above the terrain. In realistic mode, there are as many copies as the height of the wall. Also, some terrains are not displayed. The problem exists for towns and outdoors. E-mailed snapshots. -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Warrior
Member # 5289
|
written Monday, January 17 2005 12:55
Profile
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. [ Thursday, January 20, 2005 22:01: Message edited by: Notus ] -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Infiltrator
Member # 148
|
written Wednesday, January 19 2005 17:32
Profile
Another bug: Import Town for Large towns creates garbage in the town written over. No problems with Medium or Small towns. The problem exists for Jeff's Editor also. At first I thought it was the custom graphics of the town, but even with a duplicate .cmg and data file, the problem exists. Also, medium and small towns with custom graphics have no problems. The problem is not consistant. I have had screw-ups from importing other peoples towns. Outdoors imports okay. If the town is imported into the scenario it came from, then the problem does not exist. edit: Height, floors, terrain, and even creatures become scrambled. Also, the imprted terrain is always a 48x48 square. It should be 64x64. E-mailing snapshot. [ Wednesday, January 19, 2005 17:39: Message edited by: Dahak ] -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Warrior
Member # 4202
|
written Thursday, January 20 2005 10:47
Profile
Homepage
Could it be an endianness bug: Do you know whether the relevant scenarios were created on a different platform from the one being used to import with, or anything like that? -------------------- Creator of the 3D Blades of Avernum Editor for Mac. Get it at Ingenious Isaac's Illusion, my web page. Better yet, get Battle for Wesnoth, a wonderful free TBS game. Posts: 192 | Registered: Sunday, April 4 2004 08:00 |
|
Infiltrator
Member # 148
|
written Thursday, January 20 2005 12:08
Profile
Hm. The scenarios were made on Macintosh computers I believe (mine, TM, Vogel, and Stareye). I could not find a common thread among those that import correct and those that do not. I even tried making a new scenario via the 3D editor and another via the Vogel editor. I placed a spot of cave floor, tried to import, BAM. Screwy terrain and heights (I had heights of 255 mostly). And yet again a 48x48 square was affected. The rest of the town is unchanged. The unchanged is what was there before import. -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Warrior
Member # 5289
|
written Thursday, January 20 2005 15:43
Profile
"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. -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Infiltrator
Member # 148
|
written Thursday, January 20 2005 16:23
Profile
You mean this? The problem happens with every scenario. I haven't had any problems with the original scenarios (Vogel's), but all others released have trouble. Also, no scenario has trouble importing from itself. Edit: Case for the large towns seems incomplete. :( [ Thursday, January 20, 2005 16:24: Message edited by: Dahak ] -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Warrior
Member # 5289
|
written Thursday, January 20 2005 16:46
Profile
quote: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:I see, I'll check it. -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Infiltrator
Member # 148
|
written Thursday, January 20 2005 17:07
Profile
I wanted to check something else so I did the following: Test A was made with the Vogel editor Test B was made with the Vogel editor Test C was made with the 3D editor Test D was made with the 3D editor A - D are NOT using custom floors/terrains Vogel & Vogel Large town imported from A to B using the Vogel editor : Good Large town imported from A to B using the 3D editor : Good Large town imported from B to A using the Vogel editor : Good Large town imported from B to A using the 3D editor : Good 3D & 3D Large town imported from C to D using the Vogel editor : Good Large town imported from C to D using the 3D editor : Good Large town imported from D to C using the Vogel editor : Good Large town imported from D to C using the 3D editor : Good 3D & Vogel Large town imported from A to C using the Vogel editor : Good Large town imported from A to C using the 3D editor : Good Large town imported from C to A using the Vogel editor : Good Large town imported from C to A using the 3D editor : Good Odd thing is that I had no problems. I made other test scenarios via the 3D editor and I had problems galore. I remember having this issue last summer when the 3D editor first came out. I found a solution, but I can't remember. I'll check the posts. Edit: Found it quote:I'll double check. Dang. I forgot. I had this problem when importing from within the scenario (i.e. B town1 to B town2). I was so hoping that would fix the problem. Notus: Download this and import any large town (2, 3, 4, 5, 6, 7, or 8). [ Thursday, January 20, 2005 17:18: Message edited by: Dahak ] -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Warrior
Member # 5289
|
written Thursday, January 20 2005 17:21
Profile
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. [ Thursday, January 20, 2005 18:26: Message edited by: Notus ] -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Infiltrator
Member # 148
|
written Thursday, January 20 2005 18:09
Profile
Thanks. Maybe you should e-mail Jeff. He has the same problem. [ Thursday, January 20, 2005 18:13: Message edited by: Dahak ] -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Warrior
Member # 5289
|
written Thursday, January 20 2005 18:12
Profile
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() ------------------- [ Thursday, February 03, 2005 00:57: Message edited by: Notus ] -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Friday, January 21 2005 18:50
Profile
Might I suggest moving this project to SourceForge.net. This would help get the entire community involved in development, and there are quite a few programmer's here with the capacity to contribute. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Infiltrator
Member # 148
|
written Friday, January 21 2005 19:13
Profile
Import is good! :D ? Bug: After I scroll, I DO NOT have a accidental click occurring (yay!). However, unless I click again (nothing happens!) the editor assumes I am holding down the mouse. I borrowed a USB mouse from another computer and had the same problem. What happened? If it weren't for the USB mouse having the same trouble, I'd say it was a touchy trackpad. Edit: Nevermind what I said about the corner walls. [ Friday, January 21, 2005 21:16: Message edited by: Dahak ] -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Warrior
Member # 5289
|
written Saturday, January 22 2005 00:55
Profile
KernelKnowledge12, I don't think we can get so many participants. It's almost torture to track down the source code, as you know. Dahak, quote:Finally, it passed your strict test? Congratulation. :P quote:In which mode does it occur? 3D/Realistic or 2D outdoor or town -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Saturday, January 22 2005 14:04
Profile
Well, I'd like to help, although I'm currently working on quite a few other things, so I'm not sure how much actual time I may be able to commit. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Infiltrator
Member # 148
|
written Saturday, January 22 2005 14:37
Profile
Outdoors, 2D or 3D. Usually 2D. Edit: Remember, you cannot scroll from town to town. You have to load them. Personally, I'm just saving and loading instead of scrolling outdoors. If you do that or save before you cross-over, then no problem (no dialog box). [ Saturday, January 22, 2005 14:39: Message edited by: Dahak ] -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Warrior
Member # 5289
|
written Saturday, January 22 2005 23:55
Profile
KernelKnowledge12, There are a several things we can contribute to the community a) Porting Isaac's 3D editor to Windows and OS9 Mac b) Bug fix on the 3D and original editor c) Reorganize the source code or remake it from scratch d) Add more smart functions to the editor I'm working mainly on b) and a) now. Windows porting is about 70% complete. Anyhow, I cannot imagine how to cooperate on the current source code. We need more ordered source code to share our project. I remember you tried to remake it. Can you open it, as we discuss how to cooperate on it. Dahak, It was reproduced on my side. "Outdoor: drawing mode failure after moving section" bug. Just after scrolling to another section on outdoor, mouse drawing doesn't work correctly. If there is no change on the previous section, the transition to the another section goes without save dialog. Just after the transition, mouse click to the edit screen results nothing. No drawing occurs. If there is any change on the previous section, a save dialog appears on the transition. Just after the transition, moving mouse on the edit screen causes continuous drawing. This bug occurs both on 2D and 3D mode. I'll look into this bug, but please wait until next weekend. (It's Sunday evening now in Japan) [ Sunday, January 23, 2005 00:21: Message edited by: Notus ] -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Sunday, January 23 2005 12:58
Profile
The code I created was lost in a computer foul up, and I wasn't too concerned for how clean the code was when I created it. (The code was still much cleaner than the original.) Also the code was not in the least bit cross-platform (it used MFC and DirectX). I do, however, remember what I did and since I stopped working on it I've had several ideas. Either way, it should first be decided whether the code should be reorganized, or restarted. I vote for the latter as reoganizing it would just amount to more than double the work. Remaking it would also make it easier to update, as it would be a our code. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 5289
|
written Monday, January 24 2005 04:25
Profile
I agree to remake it from scratch and use a cross-platform framework. I don't know so much about cross-platform frameworks, but I suppose it'll provide so-called application framework, like MacApp, PowerPlant and MFC. It'll reduce our labor on the event dispatch, mouse/keyboard handling, menu, dialog and components on the main window such as tool/item palettes. Do you have any recommendation on a cross-platform framework? As for the file I/O, "port", endian conversion on the datafork is incomplete in most case. It doesn't care about resources. A standalone utility for cross-platform data converter is desirable. Resource fork of Mac .cmg file will be temporally converted to .rsrc (Resource Manager-style resources) with StuffIt expander when a .sit file is expanded on Windows. This means we can make a data converter from Mac to Win using .sit file even on Windows. In most of data classes, especially data saved in .bas file (scenario_data_type, outdoor_record_type, town_record_type, big_tr_type, ave_tr_type, tiny_tr_type) unsigned char is used. This reduces performance on the execution speed. Nowadays, PC has plenty of RAM. Saving a several hundred KByte memory is nonsense. These data types should be the natural size (int) for CPU. Even if we changes the data size, we only need dedicated serializing method for file I/O. Then we can freely add members to these classes. For example, adding two member variable, type and size, big_tr_type, ave_tr_type and tiny_tr_type are represented by one class. This will encapslate so many conditional branch on the source code. On graphic routines, the problem is more serious. Even the basic data types are different on PC and Mac. Not only the size of data but the order of members. a) Use only common data types defined explicitly on the source code in most of routine, except a several wrapper routines for porting. b) Do not use simple utility routines provided by the operating system, such as InflateRect(), PtInRect(). Make a compatible one on the source code. [ Monday, January 24, 2005 04:49: Message edited by: Notus ] -------------------- Project: BoA Editor Remake on SourceForge.net supports "3D BoA Editor" (Mac and Win), and creates advanced BoA Editor. Posts: 107 | Registered: Tuesday, December 14 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Monday, January 24 2005 06:56
Profile
quote:See how you like wxWidgets. It's extremely powerful and over 12 years in the making. quote:Not too sure why this would be needed. Please elaborate. quote:First I think we see if we can get inheritance on our side, but, yes, there are several ways the classes in the original source code can be bettered. quote:We should ignore most of the graphic routines ( except Isaac's code ) as the use of a framework will drastically change the way the underlying calls will work. The graphics code should wait for a while. On another note, since this is an editor, maybe we should split the entire application into two smaller projects: the "kernel", and gui. The "kernel" will deal with just basic totally cross-platform operations (such as porting, loading files, and editing the files). The gui will be mostly cross-platform, but will have to use different graphic loading code due to the different resource files inherent in BoA. Also the scripting engine used in the editor needs to be replaced. Fortunately, Boost.Spirit will make this incredibly easy. (We should be able to expand this to all types of scripts also.) All of these are suggestions; comments are welcome. [ Monday, January 24, 2005 07:00: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 4202
|
written Monday, January 24 2005 12:09
Profile
Homepage
quote:Probably a good idea, although I haven't looked at it much. quote:There are two things to consider: 1) More people know C than C++. The more people who can understand/modify the code, the better. 2) C++ is better than C for many things. I think that using Sourceforge would probably be a good idea. What we're doing now is not good. It is too much of a bother for me to update my version when other people make improvements. And if there is more involvement than a single person, we will need a better system for dealing with modifications than uploading modified source files. If we rewrite it completely, I think we can choose our own open-source license, although I'm not sure we'd want one different from the original's. I believe the current editor's license is not GPL-compatible. (I'm not sure of any of this though because I'm not a lawyer.... :rolleyes: ) -------------------- Creator of the 3D Blades of Avernum Editor for Mac. Get it at Ingenious Isaac's Illusion, my web page. Better yet, get Battle for Wesnoth, a wonderful free TBS game. Posts: 192 | Registered: Sunday, April 4 2004 08:00 |
|
Shock Trooper
Member # 4557
|
written Monday, January 24 2005 12:32
Profile
For liscensing issues, the GPL should be more than adequate, although before we start any coding, or even start a project on sourceforge, we should ask Jeff for express permission. Before this though, we should probably find out exactly how many people are willing to help. Actually we should decide on whether we should create a sourceforge project right now. I can create the project if neccessary, although I'm sure there are several people here that are also registered with SourceForge. On a side note, I just found out about this library a week ago, and IMHO it's brilliant: Phoenix (It is not yet part of the Boost distribution, but it probably will be in the future.) EDIT: Oh and about the C++/C thing, if we can write the code to completely separate the procedural part from the OO part, we can avoid the problem of confused C people. Also we can set a requirement for a certain amount of commenting/documentation. EDIT: I looked over the BoA Editor liscense, and would a remake of the Editor constitute a "Contribution"? Also, why does the last part, entitled "YOU MAY NOT:" seem to contradict the other parts? [ Monday, January 24, 2005 15:07: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Infiltrator
Member # 148
|
written Monday, January 24 2005 19:05
Profile
If this get off the ground, then I request a few features. 1) Tint the side bar icons just as they are tinted in 3D mode. 2) Add a "tinting" test. You load an icon/graphic and check off the tints you want. You may also include a numerical tester. This way you do not have to edit and reload for every tint. The tester would do it, and you could refresh until you get a good value, and paste that value into the data script. 3) Create a copy feature that lets you copy a terrain/floor pattern and paste it. Lets you organize better if something is off. -------------------- My ego is bigger than yours. Posts: 480 | Registered: Thursday, October 11 2001 07:00 |
|
Off With Their Heads
Member # 4045
|
written Monday, January 24 2005 19:18
Profile
Homepage
Two features I would love to see: Copy/paste for objects (terrain scripts, monsters, items). I get sick of writing the same name into a terrain script, putting in the same numbers into the memory cells, etc.Small pictures of the items and creatures next to their names in the menus. Finding these things would be much easier with images than with just text. [ Monday, January 24, 2005 19:19: Message edited by: Kelandon ] -------------------- Arancaytar: Every time you ask people to compare TM and Kel, you endanger the poor, fluffy kittens. Smoo: Get ready to face the walls! Ephesos: In conclusion, yarr. Kelandon's Pink and Pretty Page!!: the authorized location for all things by me The Archive of all released BoE scenarios ever Posts: 7968 | Registered: Saturday, February 28 2004 08:00 |