Kyshakk Koan KernelKnowledge12 Posted March 10, 2005 Author Share Posted March 10, 2005 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: Originally written by Solomon Strokes: Say, could you have more keyboard shortcuts for placing and deleting objects (ie, barrels, blood, etc) like we had in BoE? And does your "hill formation" tool work on the same flawed bases that the one from the regular BoA editor is based on? 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. Quote Link to comment Share on other sites More sharing options...
Garrulous Glaahk Notus Posted March 11, 2005 Share Posted March 11, 2005 Quote: Concerning how, could it be possible to replace the indexes in the tr_type's to pointers. 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: 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, Yes, we can add index as a member to the terrain object. Quote: 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. ".terrain[" (236 lines) and "->terrain[" (11 lines) Humm. fair amount. Auto hill formation 1) Hill formation procedure Please refer next linkhow 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. 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. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted March 11, 2005 Author Share Posted March 11, 2005 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? Quote Link to comment Share on other sites More sharing options...
Garrulous Glaahk Notus Posted March 11, 2005 Share Posted March 11, 2005 Quote: oncerning 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? 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? 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. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted March 11, 2005 Author Share Posted March 11, 2005 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. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted March 14, 2005 Author Share Posted March 14, 2005 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. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted March 14, 2005 Share Posted March 14, 2005 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. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted March 14, 2005 Author Share Posted March 14, 2005 Quote: Originally written by Kelandon:Would it be possible to summarize the status of the project as of right now? 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. Quote Link to comment Share on other sites More sharing options...
Garrulous Glaahk Notus Posted March 15, 2005 Share Posted March 15, 2005 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: Notus, could you do a quick check to see if the functions work? OK. I'll check it. Quote: It probably won't, however, be any better (if its not worse) than the old editor. - 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. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted March 15, 2005 Share Posted March 15, 2005 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! Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted March 21, 2005 Author Share Posted March 21, 2005 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. }; Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted March 29, 2005 Author Share Posted March 29, 2005 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. Quote Link to comment Share on other sites More sharing options...
Ineffable Wingbolt Silent Motion Posted March 30, 2005 Share Posted March 30, 2005 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. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted March 30, 2005 Author Share Posted March 30, 2005 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. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted April 2, 2005 Author Share Posted April 2, 2005 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. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted May 22, 2005 Share Posted May 22, 2005 Update, anyone? Is this project still going? What more needs to be done? Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted May 22, 2005 Author Share Posted May 22, 2005 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. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted May 22, 2005 Share Posted May 22, 2005 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. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted May 22, 2005 Author Share Posted May 22, 2005 "A bit crude" may be an understatement, but after the alpha release adding features shouldn't be too hard. Quote Link to comment Share on other sites More sharing options...
Ineffable Wingbolt JadeWolf Posted May 24, 2005 Share Posted May 24, 2005 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. Quote Link to comment Share on other sites More sharing options...
Rotghroth Rhapsody Hawk King Posted May 24, 2005 Share Posted May 24, 2005 Quote: Originally written by JadeWolf: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. Im with you better words were never spoken Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted May 24, 2005 Share Posted May 24, 2005 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. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted May 24, 2005 Author Share Posted May 24, 2005 Quote: Originally written by JadeWolf: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. 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: Originally written by Kelandon:I mean, BoA is hard and arduous to design in. No amount of utilities will make it easy, even if they make it easier. In what ways (be very specific)? I may be able to help here. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted May 24, 2005 Share Posted May 24, 2005 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. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted May 24, 2005 Author Share Posted May 24, 2005 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? Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted May 24, 2005 Share Posted May 24, 2005 SDFs don't give me too much trouble. I organize them into groups by their first coordinate thusly: Town-specific SDFs (usually for one-time messages) get the town number. So in town 5, I use (5,0), (5,1), etc. If I need more than thirty, I add 100, because I'm not likely to make a scen with more than 100 towns, so that town 5 would then also get (105,0), (105,1), and so on. Outdoor section-specific SDFs get 200 + x of section times 10 + y of section. So section (3,4) would get (234,0), (234,1), etc. If the outdoors were large, I might have to modify this system, but I haven't yet. Scenario-wide SDFs (and there are only a few of these) get 250. If the outdoors were large, they'd get 290 or something. Thus in Bahs the major scenario-wide SDFs are (250,0), (250,1), etc. With this sort of organizational system and the notes that I take (which you can see because I leave those files in my scenario downloads), SDFs are not much of a problem for me. EDIT: As far as doing things over and over, the only thing that comes to mind is creating one-shot code. I copy and paste this all the time: Code: if (get_flag(1,0) == 0) { set_flag(1,0,1); // do something, usually a message_dialog } Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted May 24, 2005 Author Share Posted May 24, 2005 I was thinking about making a tool that worked kind of like C++'s precompiler. It would lessen the need for a large amounts of notes, but it would create a dependence upon the utility. Good idea? Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted May 24, 2005 Share Posted May 24, 2005 Oh! I just had a thought! I finally see how a useful scripting utility could work! It would basically be a text editor with modifications. It could use color-coded text, first of all, different colors for different kinds of calls or for strings or that sort of thing. It would also have a list of calls off to the side that would look sort of like this: void block_entry(short do_blockage) short get_ran(short num_dice,short min,short max) short is_combat() They could be dragged into the script so that dragging block_entry would put in the script: block_entry() Clicking a call in the list would bring up the Appendices entry for that call. Additionally, it would have a built-in script-checker, maybe based on Alint, which is really good but just has no GUI to speak of. Wow. With that scripting utility, the custom objects utility, and a redone editor, making scenarios would be vastly easier than it was when BoA first came out. EDIT: I have no idea how C++'s precompiler works, so a brief description may be in order. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted May 24, 2005 Author Share Posted May 24, 2005 The scripting editor would work like Dev-C++'s gui, though without the constant parsing it does. There won't be a drag and drop interface, but there will be a code completion utility. For example, you'd start writing a call to a function, and underneath it the function's declaration (in a yellow box) is shown, such as: block_en void block_entry( short do_blockage ) This is how it is done in VC++ and Dev-C++. As for C++'s precompiler, here are a few simple examples: if you wrote: Code: #define SOME_GUY_DEAD_SDF get_flag(10,1) everytime you wrote SOME_GUY_DEAD_SDF, the precompiler would replace it with get_flag(10,1). if you wrote: Code: #define CHECK_SET_SDF( x, y, action) if (get_flag(x,y) == 0) { \ set_flag(x,y,1); \ action; \ } , then this, Code: CHECK_SET_SDF( 1, 20, ( do_something(...); ) ) would become this: Code: if (get_flag(1,20) == 0) { set_flag(1,20,1); do_something(...);;} Also, you can say something like: Code: #ifndef DOING_THIS_PART do this code#elsedo this code#endif for version compatibility. For advanced uses of the precompiler, look here. All scripts using the precompiler would have to be run through the precompiler before it could be used in the game. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted June 13, 2005 Author Share Posted June 13, 2005 Its been a while since I've given an update, and soon I won't be able to devote much time to this project, as I have up 'till now, so I thought I'd give one. Due to several odd problems, of which I can't seem to find work arounds, I thought it best to switch from wxWidgets to NGL. This should make things easier, and allow for a better interface. Because of this change, the program's alpha release won't be for quite a while. Also, since I'll only be able to work on the project for a few hours a week, progress will be slow. To show that progress has been made, I put up a screenshot on sourceforge of what the editor looks like currently (using wxWidgets), here . The screenshot is of a partially working 2D view. The code for drawing the 2D view is fine, and the problems are due to the loading of textures, but NGL should help in this area. Also, if anyone believes they can help and is willing to help, please say so here on these forums (or fora as I believe the correct term was pointed out to be), or email me through sourceforge. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted July 18, 2005 Share Posted July 18, 2005 *poke* Wondering where this is these days. Badly wishing for the palettes. Update on progress? Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted July 18, 2005 Author Share Posted July 18, 2005 Well, after working on the GUI aspect of the remake, certain, more baneful parts of BoA's design started to show, and I quickly developed an intense migraine, so I started working on the actual editing part of the, umm, editor. This is essentially going to be (at first) in the form of a command line application that allows for directly editing/browsing a .BAS file. It will also contain a scripting engine to automate editing scenarios. While this probably won't be too much use to most people, it'll be the "shell" component of the remake. I've got the basic design down, and since this is a command line application, it shouldn't take too long to get a compiled version. Also, I've recently revamped the BoALib part of the entire project. It's cleaner and better geared towards C++ rather than C. As for the bug I described awhile earlier, I found a way around it that should be enough, though it may annoy some Windows users. Questions/Remarks/Suggestions are welcome. Quote Link to comment Share on other sites More sharing options...
Rotghroth Rhapsody Overwhelming Posted July 18, 2005 Share Posted July 18, 2005 It's looking great. The greater area view, all towns and outdoors in a tree at one side, the palletes... Keep up the good work! You're making it all easier for everyone to create their scenarios. Thanks! Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted July 18, 2005 Share Posted July 18, 2005 This sounds really good, or at least it sounds as though it will be really good when the first release comes out. My main question is how close we are to that. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted July 18, 2005 Author Share Posted July 18, 2005 Not too sure how I can answer that. Here's essentially what's left to do before an alpha release: Finish the editing part of the editor (about 45% - 55% done) </font><ul type="square"> <font size="2" face="Verdana, Arial, Helvetica, sans-serif">Technical Details: Add bas_file "registers" Put in inline "accessors" Create grammar that creates bytecode Create main application loop and release </font></li> [*]Change the graphic sheet handling part of the GUI code to accomodate both BoA's style and OpenGL's style [*]Link the editing part of the remake to the GUI, i.e. add menu items, a text box console, toolbox, etc.</ul><font size="2" face="Verdana, Arial, Helvetica, sans-serif">The good thing about the program I'm working on right now is that it should allow for a quick change from alpha release (of the remake) to beta release, since many editing features can be scripted. For example, it should be possible to turn Khoth's Wall Drawing Tool into a script, and therefore avoid going through the trouble of adding it directly to the code. As for when this should be completed, I can't say. I hope this helps. Quote Link to comment Share on other sites More sharing options...
Rotghroth Rhapsody Overwhelming Posted July 18, 2005 Share Posted July 18, 2005 Quote: Originally written by KernelKnowledge12: The good thing about the program I'm working on right now is that it should allow for a quick change from alpha release (of the remake) to beta release, since many editing features can be scripted. For example, it should be possible to turn Khoth's Wall Drawing Tool into a script, and therefore avoid going through the trouble of adding it directly to the code. Is that scripting accessible to other programmers? And non-programmers? Anyway, that sounds really interesting. It makes me imagine your editor remake as a customizable editor, where the scripts would be the plugins. Of course, I may have understood wrong. What's still left to do until alpha release sounds complicated to a non-programmer like me, but keep up the good work. We're looking forward for the alpha release. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted July 18, 2005 Author Share Posted July 18, 2005 Quote: Originally written by Overwhelming:Is that scripting accessible to other programmers? And non-programmers? Anyway, that sounds really interesting. It makes me imagine your editor remake as a customizable editor, where the scripts would be the plugins. This is the basic idea, except there will be no way to add menu items, buttons etc. to the actual GUI through scripting. People can write scripts and run them through the editor as if they were running a program through the command line. A script will essentially be a C source file since C is what Avernum Script is based on. There will be a main function that can take any amount of arguments, which, when the script is invoked, will be treated as command line arguments. People can use every part of C except: pointers, references (everything is passed by reference), structs, and dynamic arrays (with the exception of strings). There is one global variable, the .BAS file. Of the supported primitive types, there will be the following: bool, int, location, rect, town, item, creature, field, terrain_script, outdoor, wandering, boat, horse, storage_shortcut, string, terrain Details on these primitives and other elements of scripting will be supplied in the documentation. EDIT: Quote: everything is passed by reference Nevermind about this. Variables can be passed by reference if specified. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted July 19, 2005 Share Posted July 19, 2005 I wish there was something I could do to help, but I doubt there is. I don't know the first thing about C code, and while I've been meaning to learn, I don't have any books or anything, and I'm guessing that what you're doing is a bit too advanced for a beginner anyway. I'd love to help with any beta testing when the time comes, though, and I can point out some bugs/issues with the current 3D Editor. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted July 19, 2005 Author Share Posted July 19, 2005 Quote: Originally written by Kelandon:I wish there was something I could do to help, but I doubt there is. I don't know the first thing about C code, and while I've been meaning to learn, I don't have any books or anything, and I'm guessing that what you're doing is a bit too advanced for a beginner anyway. The scripting engine I'm creating right now that will allow for editing a .BAS file through scripting will use C, so if you plan to use this feature you'll have to learn. Here's a very good tutorial on C/C++ that should be as good as any book:http://www.cplusplus.com/doc/tutorial/index.html Also, if you have any questions, I'd be happy to answer. EDIT: Oh, please list all the bugs/issues with the current editor that you notice. There's a chance I can fix them all at once. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted August 10, 2005 Share Posted August 10, 2005 Somehow I never noticed the last response in this thread. Okay, here goes the bugs/annoyances I have with the current 3D Editor: 1. BUG: Realistic mode on the edge of outdoor sections sometimes misbehaves. You can see through walls (and they are shown in cutaway mode), as you can see here: screenshot . Compare this with what you see one step further north: screenshot . 2. BUG: Realistic mode on the edge of an outdoor section also sometimes blocks off areas of screen for no particular reason. This is inconsistent, but here's one example: screenshot . Here's the same spot in regular 3D mode: screenshot . 3. BUG: The 3D editing screen isn't exactly the same size as the BoA playing screen. Here's one spot in 3D editing mode: screenshot . I've made all the visible terrain cave floor, and everything around it is green grass. Here's the same spot in the game: screenshot . You can see corners of green grass. 4. ANNOYANCE: The default terrain script name is "dummy." When you place a terrain script, it should just pop up the dialog box asking for a name (and the box should be blank or "dummy" highlighted, so that you can just start typing the name without having to delete something). In fact, you could leave the default as "dummy" if you could change all the boxes to pop up with highlighted text instead of having to move to the end of the box and delete everything. 5. ANNOYANCE: The default state to call when placing a special rectangle is 0 and increments by 1 with each rectangle that is placed, although one will probably not ever place a special rectangle that calls state 0. The starting number should be 10. (I can just type in a "1," but I have no doubt that this has confused some newbies who don't know that they're supposed to start with 10.) 6. ANNOYANCE: I'd like to be able to edit the adjacent outdoor section's terrain when it's on the screen. This seems hard to do with the current editor setup, though. 7. BUG: The calls te_ed_icon_adjust and fl_ed_icon_adjust don't display in 2D mode in the editor, but they do display in the automap in the game. These are the ones that come to mind immediately. They are all really little things that don't bother me much, but if you can fix any of them, I'd appreciate it (and I'm sure all other BoA designers would, too). Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted August 11, 2005 Author Share Posted August 11, 2005 Hmmm, I didn't think there'd be this many. It would probably better to enter them in the bug tracker at the sourceforge site. It would be easier for me to manage them. I'm pretty close to finishing the scripting engine for editing, but if I can't get it to compile by tomorrow, I'll start working on fixing these bugs. If there are any other bugs/suggestions please say so. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted August 11, 2005 Share Posted August 11, 2005 I think I just put in the four actual bugs. The minor annoyances aren't a big deal, though, so I left them out. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted August 11, 2005 Author Share Posted August 11, 2005 Well the annoyances should go in either the support requests or the feature requests. If you really don't feel them to be important, you don't have to enter them, but I'll still try to address them. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted October 14, 2005 Share Posted October 14, 2005 Time for a progress update? I think so! Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted October 15, 2005 Author Share Posted October 15, 2005 I haven't worked on this in a few weeks, and I probably won't for a while longer due to a broken laptop, college applications, AP, etc. As for the current status of the effort, - the BoALib CVS module works and should allow for much easier development in creating any tool for editing. It parses scenario data scripts, and can load/save .BAS files, using a few calls. If anyone wants to use it, ask and I can give a few technical details regarding its use. - the current 3D Editor code in the CVS module (NOT the source files in the file releases) uses BoALib, and essentially works just the same as the original 3D editor, without import features. The plan is to alter the API dependent features to use wxWidgets and OpenGL, and then release the resulting program as the official, non-beta 3D Editor. All other questions/comments/suggestions are welcome. Quote Link to comment Share on other sites More sharing options...
Easygoing Eyebeast Thralni Posted October 15, 2005 Share Posted October 15, 2005 Quote: Originally written by Kelandon:Somehow I never noticed the last response in this thread. Okay, here goes the bugs/annoyances I have with the current 3D Editor: 1. BUG: Realistic mode on the edge of outdoor sections sometimes misbehaves. You can see through walls (and they are shown in cutaway mode), as you can see here: screenshot . Compare this with what you see one step further north: screenshot . I experienced this too, but not only in outdoors. Also in towns I experience this. I can't show a screenshot, because I don't have website, but what the editor does, is that it sometimes doesn't draw walls. This giving a blank spot which you can't see through. Its not something majot, but it really can get me irritated if it happens on a really important spot. What you mentioned, kelandon, happens when you have a cliff or walls in outdoors at the border of two outdoor sections. Still it shouldn't happen, but the reason for this, is simply that when you work on one outdoor section, you don't work on the other, meaning that the editor will just draw the other section as if you simply are not working in it. This also means it will draw the walls in the mode of very low, like you showed in the screenshots. Something I also noticed, is that the editor ussually makes places much darker than they are in the game. Mainly walls are sometimes totally black in the editor, but in the game I can still see textures on the same walls. Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted October 16, 2005 Author Share Posted October 16, 2005 Quote: Originally written by Thralni, emperor of Riverrod:I experienced this too, but not only in outdoors. Also in towns I experience this. I can't show a screenshot, because I don't have website, but what the editor does, is that it sometimes doesn't draw walls. This giving a blank spot which you can't see through. Its not something majot, but it really can get me irritated if it happens on a really important spot. What you mentioned, kelandon, happens when you have a cliff or walls in outdoors at the border of two outdoor sections. Still it shouldn't happen, but the reason for this, is simply that when you work on one outdoor section, you don't work on the other, meaning that the editor will just draw the other section as if you simply are not working in it. This also means it will draw the walls in the mode of very low, like you showed in the screenshots. Finding the causes to these bugs may take a while due to the way the 3D code is written. Unfortunately, it was written that way because the rest of the editor was written that way. Until serious modularization of code, and separation of concepts, so-to-speak, is done, smaller bugs like this will be somewhat hard to trace. Quote: Something I also noticed, is that the editor ussually makes places much darker than they are in the game. Mainly walls are sometimes totally black in the editor, but in the game I can still see textures on the same walls. This doesn't make too much sense. The editor is supposed to show places fully lit. Ah well, something else to look into, I guess. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted November 21, 2005 Share Posted November 21, 2005 *poke* Any progress made lately? Any progress coming soon? Quote Link to comment Share on other sites More sharing options...
Kyshakk Koan KernelKnowledge12 Posted November 21, 2005 Author Share Posted November 21, 2005 Quote: Originally written by Kelandon:Any progress made lately? Any progress coming soon? Not really. I've just started working on it again. Quote Link to comment Share on other sites More sharing options...
Magnificent Ornk Kelandon Posted December 27, 2005 Share Posted December 27, 2005 *poke* Time for a status report? I think so! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.