KernelKnowledge12

As far as I know the BoA Editor Remake is the only project doing this. It is maintained by Notus, Isaac and I. Kelandon is the webmaster for this project. As for progress, well, there probably won't be much for a while. I won't be able to do any serious coding until after the AP Tests, and Notus is also busy, at least for the moment. The script editor will be implemented much later, and for the moment I'd suggest you download Alint by Khoth, if you don't have it already. If you need anymore information, or have any other suggestions, I'd be more than happy to hear them.

As far as I can remember, Isaac got his tinting code directly from Jeff, so it is most likely BoA's lighting system that is messing with the redness of your slith. I don't know this for sure, so Isaac's probably the only one who could really give an answer for this.

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.

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.

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.

The default sounds for the PC version of BoA are held in the application itself. As has been said before, to add sounds one would have to hack into the application and add these sounds. I can't do it, but there are those who can. Either way I strongly advise you not to do it. I think Notus gave a good explanation as to why.

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. };

Works for me.

Would a link to the Editor's Remake, suffice as useful? For convenicence, here is the link: http://boaedremake.sourceforge.net

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.

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.

Yeah I guess I overstressed the detriment to game speed, but the fact that some scripts are only run once every some turns, implies that BoA's scripting engine is generally slow. The editor's code implies that BoA does not go the traditional route of converting scripts to byte code before running them, which slows script execution. Of course, this is all speculation. EDIT: Just read your post, Kelandon. Alint checks one script. BoA simultaneously reads several scripts, relates them to game's actual state, updates the game state, and then actually runs the game. The added checks probably wouldn't do much to game speed, but as a programmer I guess I've been sort of indoctrinated to think in terms of efficiency.

Come to think of it these errors should not be fixed by Jeff. This would require the game checking every time for a possible error, even if the error isn't there. This might seriously slow the game. We should, however, ask Jeff to create a debug version of the game that does check for things like this. This should take just as long as fixing the App. As for errors, these come to mind: - Over indexing an item/creature/floor/terrain - Using a string that is over 256 chars - Using a string over 30 chars in setting an item's full_name - Using a string over 14 chars in setting a scripts name - Using a string over 20 chars in setting an object's (floor/terrain/creature/item) name These are only possible errors. I have no idea if they actually crash BoA. Also, this is a very small list, compared to all the things that could in theory crash BoA. I'd rather not put them all down until I have a better idea of what is handled in BoA.

I may be able to help in this matter by looking at the editor's code, but since I'm not a scenario designer I would need to know what BoA does give an error for. For example, if you specify a location that is invalid, like (2000,4000), does it crash BoA or give an error? EDIT: For clarity: by "crash BoA" I meant the program gives an Unhandled Exception, and by "give an error" BoA actually says what the error is.

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.

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?

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: Originally written by andrew miller: DreamGuy, what's with the abrasive tone? Others are somewhat guilty as well, but you seem to be taking the cake. Perhaps a better question would be why people keep arguing with him. It hasn't been very productive.

Quote: Originally written by andrew miller: DreamGuy, what's with the abrasive tone? Others are somewhat guilty as well, but you seem to be taking the cake. Perhaps a better question would be why people keep arguing with him. It hasn't been very productive.

I just finished the algorithms neccessary for set_up_lights to function (sorry for the delay). It is loaded into the CVS, but I think I should look it over some. It isn't commented, so I apologize for any confusion. I'll work on the fileio tomorrow, and then write the old_can_travel functions. Just saw the town limit part of your post Notus. I think I forgot that the editor writes those 2 arrays as full length no matter how many towns there are. The BoA application, then, must read it in this way. Thank you for clearing this up. EDIT: Finished with the save_campaign() function.

I've started porting a rather long string of functions into the new editor, and I've found it neccessary to remake most of them. To do this, I've created a line class with three iterators (in line.hpp), and made a new direction system (in directional.hpp). The line class' tile_iterator will be used on the old_can_see, etc. functions, which I plan to split into four separate functions. Notus, Isaac (any other developers who are working on this), please take a look at these files, and make sure you don't see anything wrong with them. I believe I'll have these functions done by the end of the weekend: look_block move_block old_can_see_to old_can_see_in old_can_travel_to old_can_travel_in set_up_lights After this, I should be able to finish the file i/o functions pretty fast. EDIT: Nevermind about my direction system; I don't believe I was thinking clearly when I coded it. Also, I think I'll only split the old_can_see function into two different functions. EDIT: FYI, I only tested my tile iterator for forward iteration. It my not work with backward iteration, but I'll test it soon. EDIT: I was looking at the terrain classes (ave_tr_type, big_tr_type, tiny_tr_type) and I thought it would speed things up if instead of holding indexes to a specific floor or terrain, they held the actual pointers to the objects. This way instead of referencing the scen_data object every time a terrain was drawn, the program could just use the terrain object. Notus, would this be a good idea, and if so, should we implement it now or later?

Not in the Windows version. I guess Jeff wasn't as lazy when he created the Mac version of the editor.

This is not an error, just an example of how primitive the editor is. In the new editor, this will not be a problem, but chances are it won't be fixed in the old editor. I am also curious as to how you managed to copy text within the application. I checked the code, and I couldn't find anything that would account for such a feature. Of course, I only looked in the Windows code.

Your designs look great ! As for my code, it might be awhile. I was able to write the parser quickly because a few storms closed the school systems for quite a while. I just finished a few metafunctions for the terrain classes (tiny_tr_type,ave_tr_type,big_tr_type), and I've commented a few of the files. I haven't loaded the metafunctions onto the CVS server yet, but I will soon.

Quote: Originally written by Notus: Please retrieve the previous build (build0026) of Win 3D editor from CVS, and cut out the data loader part. That version worked fine as the loader to the data object, but I gave up it by another problem I told. We can use it on our new editor. Revise it by your new template style. Show me a good example of template implementation I've looked at the save/load functions, and I have a few ideas. (I'll go ahead and do them, but I won't load it onto SourceForge until I get your approval. Actually I loaded some stuff before I read this, but this shouldn't be a problem.) 1) First, I'd like to change it to use fstream, and Spirit's file_iterator. 2) The save function is dependent upon the set_up_lights() function, which is an algorithm that works on terrains. I'd like to start a modularization of BoA-centric algorithms. I'll create two files, "algo_base.hpp" and "terrain_algo.hpp". 3) The save/load functions are dependent on global data, and so cannot be extended to any other use. I'd like to change their declarations to: save_campaign( const char* __original, const char* __to ); load_campaign( const char* __from ); Concerning my parser: Since my parser uses Spirit, which uses an excessive amount of template metaprogramming, it can be a strain on the compiler. To fix this I tried to put the actual functor definitions along with the parser's grammar definition in a .cpp file, so it won't compile every time the header is included. This, however, created linker errors that made no sense. Do you know of another way to solve this problem?