BoA Editor Remake
Pages
| Author | Topic: BoA Editor Remake |
|---|---|
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 13:09
Profile
I couldn't create a more generic form of the functions with an algorithm-like representation. They are much too dependent on the global variables, specifically scen_data. This should definitely change, but I don't know when we should change it. Concerning how, could it be possible to replace the indexes in the tr_type's to pointers. For example, instead of declaring it like this: class big_tr_type { ... public: short terrain[48][48]; ... } it would be like this: class big_tr_type { ... terrain_type_type* terrain[48][48]; ... } The file io would have to be changed to convert these pointers to indexes, and the opposite for writing. This is a very simple procedure, but the hard part comes in when copying the rest of the original code. Any code that uses scen_data to index has to be changed to just use the pointer. This shouldn't be hard, but will take a long time. Is this something we should do now? EDIT: quote:Ooops, I waited too long to post. Anyway, keyboard shortcuts should be fairly simple, but this will have to wait some time. At first we will most likely use the "hill formation" tool in the editor, but this will definiately change later on in development. [ Thursday, March 10, 2005 13:13: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 5289
|
written Thursday, March 10 2005 18:48
Profile
quote:It's OK. Preferable for display routine because pointers speed up the access to the terrain object than index. Index should be converted to pointer with terrain object array. quote:Yes, we can add index as a member to the terrain object. quote:".terrain[" (236 lines) and "->terrain[" (11 lines) Humm. fair amount. Auto hill formation 1) Hill formation procedure Please refer next link how to develop a scenario? written March 01, 2005 04:57 AM by Notus 2) cliff terrain a) Height difference between given square and surrounding eight square determines whether a cliff terrain is attached to the square or not. If any one of eight squares isn't one step higher than the square, the square doesn't have cliff terrain. 1 2 3 8 X 4 7 6 5 Scan each of eight squares. If it is one step higher than the square, give it a value H, otherwise give it L. Then we'll get the eighth paower of 2 = 256 cases. b) Type of cliff terrain (including convex or concave) is determined by the pattern of these eight squares. But in some cases, no terrain is attached. Ex. L L L H X H L L L We can reduce the case using symmetry. But maybe we use a table which has 256 elements for process speed. This algorithm is same as current method essentially. But we can prevent flaw by listing up all cases. Even if some bug would be found, we can easily specify the element which has bug. -------------------- 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 Thursday, March 10 2005 19:00
Profile
I'll get started on the change to the terrain objects. Concerning heights, I think I recall your idea of the color map for editing heights. I believe this is a very good idea. Did you ever find out if it was implementable? Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 5289
|
written Thursday, March 10 2005 19:50
Profile
quote:I think I can. On 2D, simply change the square color according to height. On 3D, replace floor with color tile. a) Do we need to paint side walls with color on 3D? b) Do we need to display terrains, items and creatures on colored map mode? It makes the view too complicated. If the mode switch between normal and map mode is quick enough, simple color map may be preferable. -------------------- 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 Thursday, March 10 2005 19:58
Profile
I would be in favor of the simple color map, but we can put options for displaying items/creatures/etc. in the program. Come to think of it, I can't see any use for displaying items/creatures/etc. in this type of view, but then again I'm not a scenario designer. Either way we should just ask the community before adding it. EDIT: Finished applying the change to the terrain classes/outdoor class. I'll start working on the load_campaign function. I should be done pretty soon. EDIT: Finished with the file io functions. I need to check if they work completely. The save_campaign function does not work if the current town has changed its size. This should be changed. [ Sunday, March 13, 2005 12:25: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Shock Trooper
Member # 4557
|
written Monday, March 14 2005 13:10
Profile
I finished testing the I/O functions, and I'm fairly sure they work completely. To test them, I used the load_campaign function to load a scenario. I then saved it to a new file, and opened the new file in the editor. The new file worked just as the old one. There was, however an oddity when I tried another test. Instead of loading the file in the old editor, I compared the two files, byte by byte. According to this method, the current town was not saved correctly. This makes no sense as it was loaded fine in the old editor. Notus, could you do a quick check to see if the functions work? Also, I won't be able to do too much coding for a little while. I'll be able to do some, but not a lot. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Off With Their Heads
Member # 4045
|
written Monday, March 14 2005 13:14
Profile
Homepage
Every time you post something here, I get excited. Would it be possible to summarize the status of the project as of right now? You've been working for a couple of months, and I was just wondering where things stand. EDIT: Well, talking for a couple of months, working for a few weeks, I guess. [ Monday, March 14, 2005 13:15: 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 |
|
Shock Trooper
Member # 4557
|
written Monday, March 14 2005 16:21
Profile
quote:Well, so far, the remake project has just begun. The first step in this is to port the current editor to the wxWidgets framework. This is currently what we're working on. Unfortunately, since the original code was so dependant on global variables, this will take a little longer than expected. Specifically the loading of the game's core data and the loading/saving of .BAS files are supported in the unfinished port. This may not seem like much, but these are the core components to the editor (new and old). I believe Notus has already created a User Interface prototype, and by now, he should be able to start putting the editor's views (3D view, 2D view, Realistic view) in. Then we'll have to put in the tool/graphics palette, and at this point we should have a rudimentary program that allows for editing. It probably won't, however, be any better (if its not worse) than the old editor. If this version is released, it will be a very early alpha release. This is pretty far off, so I'd rather not do any speculation for the future course of this project. If you have any more questions, I'd be more than happy to answer. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Warrior
Member # 5289
|
written Tuesday, March 15 2005 14:19
Profile
Kelandon, Your expectation encourages us much. But please be patient. We started to code new editor actually just after we released Win 3D Editor a month ago. We are now coping to rebuild not only the user interface but the basic internal structure of the editor. This process is absolutely needed to make large enhancement to the editor, because 3D editor code doesn't have enough strength as the basement. This process is not exciting work for us and also users, because no new function is realized by it. But we know this effort is inevitable if we want to go far. I hope we can finish this stage in early April. KernelKnowledge12 quote:OK. I'll check it. quote:- Split and customizable palette - Multiple and resizable edit windows for towns and outdoor - Simplified and comprehensive palette icons - Kohth's wall tool I think it's better than the original 3D editor in this stage. [ Tuesday, March 15, 2005 14: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 |
|
Off With Their Heads
Member # 4045
|
written Tuesday, March 15 2005 14:44
Profile
Homepage
I was just wondering where you are in the process. Sounds like you're making good progress. Keep up the good work, and I look forward to seeing the finished product in however long it takes! -------------------- 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 |
|
Shock Trooper
Member # 4557
|
written Sunday, March 20 2005 18:44
Profile
I started thinking and the file i/o code I wrote was a temporary solution at best. Thought up a better way to implement it and I wrote the code. I'll test it tomorrow, and start rewriting some of the algorithms in the old code. Also, I tried compiling my code on a different machine, and got some funky results. Turns out Spirit had a bug in its "intersection.hpp". (It didn't affect my computer since I used code straight from Spirit's CVS repository). If anyone's having trouble compiling the code, they should get this file ("intersection.hpp") from Spirit's CVS and put it in the correct place. EDIT: I came across an incredibly annoying problem that I have encountered time and time again in my efforts to port this code. The differing classes used to represent the terrain classes are used too frequently for a secular design to work, so I've decided to create an ambivalent class to represent all terrain types. It will be, physically, the same as the big_tr_type, but it will also have its own internal variable that tells what size it should act as. For efficiency, the iterators should be used whenever possible. This should solve most, if not all, of my problems. For convenience, here's a quick synopsis: struct _tr_type { terrain_type_type* terrain[64][64]; floor_type_type* floor[64][64]; unsigned char* height[64][64]; unsigned char* lighting[64][64]; size_t _size; // can be any number less than 64. hmm, I might templatize it so the max number can be greater than 64. }; [ Wednesday, March 23, 2005 11:53: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Shock Trooper
Member # 4557
|
written Tuesday, March 29 2005 09:46
Profile
Its been awhile since I've been able to work on this, but I've finally gotten some time. I completely redesigned the terrain classes. Instead of containing four separate arrays, they contain one multi_array (courtesy of Boost) of tiles. I rewrote the outdoor_record_type and town_record_type to hold the terrains. For the sake of simplicity, both structs use the same type of terrain, even though the outdoor's has no need for lighting. Also, the town_record_type struct holds the terrain class, but does not read/write it unless a special read_terrain/write_terrain function is called. I wrote a better file i/o system, and cleaned up the algorithms. After I test my changes, I'll load it into the CVS. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
BoE Posse
Member # 15
|
written Wednesday, March 30 2005 04:11
Profile
Homepage
Has any work been done on a visual editor for creating dialog? There was a topic on this several months ago. Most RPGs have a heavy dialog component. A tool that would allow one to visually create and see dialog flows, with a back end DB to store them, and an engine to spit out completed code would be of great service not only to BoA, but could also be tweaked for use in other RPGs. Someone could make BIG $$$ here if they did this right. -------------------- All that we see, or seem, is but a dream within a dream. Visit the Louvre, the BoA Graphics Database at http://www.personal.psu.edu/bxb11/boa/louvre/ Visit Alexandria, the BoE Scenario Database at http://www.personal.psu.edu/bxb11/boe/alexandriajs/ Posts: 653 | Registered: Thursday, September 27 2001 07:00 |
|
Shock Trooper
Member # 4557
|
written Wednesday, March 30 2005 06:06
Profile
I think there's one for PC. I can't remember who wrote it or where to get it, but I believe the information is in Kel's Designer FAQ. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Shock Trooper
Member # 4557
|
written Friday, April 1 2005 21:36
Profile
I was checking my code, and I came across an odd error that I could not trace at all. After about two days of tedious debugging, I found three bugs in the BoA Editor itself that will cause unpredictable effects if fixed. The errors are primarily in the locs_to_dir function. This is indirectly called by the set_up_lights() function, and so has immediate ramifications on every scenario's lighting. I believe I know the basic algorithm used, so I'll correct these bugs, and see how the lighting changes. The main problem with this bug is, that I don't really know if this was a just a mistake or was intended to be wrong, so I don't know if I should correct it. I guess I'll just experiment with one town in a scenario, and if it looks okay, ask the community which type of lighting to keep. Also, on a side note, I think I've noticed a possibility for very limited lighting effects, but I really haven't thought it through. EDIT: Nope, those weren't bugs, just how BoA displays maps. Either way, there's still something wrong with the algorithm, and I think I've found it. As for lighting effects, there's a definite possibility, but it will be limited to night time. [ Thursday, April 07, 2005 14:13: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Off With Their Heads
Member # 4045
|
written Sunday, May 22 2005 14:32
Profile
Homepage
Update, anyone? Is this project still going? What more needs to be done? -------------------- 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 |
|
Shock Trooper
Member # 4557
|
written Sunday, May 22 2005 15:11
Profile
Sorry for the lack of updates, but I thought people might be getting tired of them. Anyway, I've been able to get back to work, and for now I seem to be the only developer working on this. I'm currently working on the graphics code, and by the end of the week I should be able to start some runtime checking, as I have finished the overall reorganization of the old code. The current code in the CVS will build into a gui that loads all core data as well as the graphics library and is able to save/load .bas files. I'm hoping to have an alpha version released sometime in early June. After the alpha release, however, development (in terms of new features) may become very slow. Any other questions are welcome. [ Sunday, May 22, 2005 15:12: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Off With Their Heads
Member # 4045
|
written Sunday, May 22 2005 15:27
Profile
Homepage
Neato. Good to know that progress is being made. I look forward to seeing the result soon (mere weeks from now, it sounds!), even if it may be a bit crude at first. -------------------- 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 |
|
Shock Trooper
Member # 4557
|
written Sunday, May 22 2005 16:35
Profile
"A bit crude" may be an understatement, but after the alpha release adding features shouldn't be too hard. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Infiltrator
Member # 5567
|
written Monday, May 23 2005 21:13
Profile
Homepage
Will the alpha release be available for download? Because I really want a new, easier way for editing BOA so I can finish my scen. -------------------- How many shapers are there? Why is Drypeak controlled by Zakary? Why is Barzahl a Guardian? How does the Geneforge work? What's as small as nothing? Why am I asking stupid questions? -------------------------------- Shaper teacher : "DON'T TOUCH THAT!" BOOM!! apprentice :*little voice* "Sorry..." --------------------------- CSM RIFQ Neopets Do join, it's fun. Do you know what is the answer to the greatest question ever? It's here. Posts: 576 | Registered: Wednesday, March 2 2005 08:00 |
|
Infiltrator
Member # 5566
|
written Tuesday, May 24 2005 08:53
Profile
quote:Im with you better words were never spoken :P Posts: 507 | Registered: Tuesday, March 1 2005 08:00 |
|
Off With Their Heads
Member # 4045
|
written Tuesday, May 24 2005 09:37
Profile
Homepage
The editor is clunky right now, but other than being a bit more convenient, I don't think the new one will be that much easier to use, at least in the forseeable future. I mean, BoA is hard and arduous to design in. No amount of utilities will make it easy, even if they make it easier. -------------------- 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 |
|
Shock Trooper
Member # 4557
|
written Tuesday, May 24 2005 10:10
Profile
quote:The alpha release will not be meant for editing, its mainly just a base to build features (new and old) upon. These new features will most likely be added in July, as at that point I'll be done with the SATs and my finals. quote:In what ways (be very specific)? I may be able to help here. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
|
Off With Their Heads
Member # 4045
|
written Tuesday, May 24 2005 10:36
Profile
Homepage
I think the most useful sort of utility that we don't have right now and no one seems to be working on is a custom objects script utility. I imagine it having four lists, one each for floors, terrains, creatures, and items. Each list would have the number, name, and graphic of the objects. Blank objects would just have a number. Clicking on the object in the list would pop up a window in which one could edit the object. It would look sort of like the HTML editors already in existence: basically, it has a bunch of fields for every possible call (like cr_hp_bonus for creaturs or te_light_radius for terrains) and a few menus for certain things like cr_special_abil that obviously need lists. However, it would read and write directly to the scenario's custom objects script file instead of requiring cutting and pasting. Also, it would also indicate two things for each field, perhaps with colors or perhaps next to the fields: the default value for the field (so 0 for cr_hp_bonus) and the value imported with the initial "import" call. I'm imagining that if the default value was the dominant one (i.e., no call had affected the value yet), the default value would show up in the field in one color (green, let's say), but if the imported value was dominant (i.e. the creature imported had cr_hp_bonus = 30) then the imported value would show up in the field in a different color (blue, perhaps), and if the user changed that value to something different, then it would show up in a third color (black). It'd be nice if it had a built-in feature to read and modify the default items (i.e. it reads corescendata.txt and corescendata2.txt and knows the trick to modify them in a custom objects script), too, because I do this a lot and I'm sure others do as well. Perhaps this could be one of the add-ons to the remade editor. It's not urgent by any means, and remaking the editor is probably more important, but it'd be good to have eventually. -------------------- 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 |
|
Shock Trooper
Member # 4557
|
written Tuesday, May 24 2005 10:51
Profile
I thought about doing something like this eventually, and its definitely, as most neccessary components, save the graphical ones, are already evident in the current remake's code. It'll probably be created as the script editor is created. Concerning scripting, are there any things you find yourself doing over and over? Also how exactly do you use SDFs? Do you reserve certain SDFs for certain things in all your scenarios and does keeping track of these places get annoying? Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |