KernelKnowledge12

Quote: Originally written by Kelandon: *prod* Signs of life? I have not had much time to work on this, contrary to what I expected. I cannot remember when, but I added menu generation to the DSEL, cleaned it up, added a very quick document abstraction and factored it out into its own package. The view concepts and the directory tree for suncome were changed a bit. The document handling function objects were replaced by the document abstraction. I think that is all. I will not have any time to work on this for at least a few months.

Quote: Originally written by Kelandon: *poke* *prod* Two months later, where do we stand? Is there any possibility of you releasing an application that will at least allow us to look at bas files in a more reasonable manner? After a year and a half, do you have anything to show us? I have not had a whole lot of time to work on it, since last I posted here. About two-three weeks ago I found myself with enough time to finish/compile/test libremembrance, which took about three days (the changes are below). This would've have been released/in CVS, but SourceForge decided to change some aspects of their CVS service, which I'll be using as an excuse to switch to SVN. I have not worked on the GUI since last time. In about a week, I should have a lot more time in which to work on this. Quote: Semi-related question: is there (or can there) be a way to look at and manipulate .SAV files (this would help tremendously with a scenario idea floating around in my head right now). Jeff did not release any code that worked to this effect, nor did he release the file format, so first you'd have to ask him if it would be permissible then ask for the format. Changes to libremembrance (from the changelog): - Version 1.1.0.1 - Changed the bas_file class name to scenario - Removed the scenario_header class - Moved all the data that must be stored into the scenario (was bas_file) class - Moved temporary data (num_towns, town_size, town_starts_hidden) to the new class, scenario_meta_data, which the streampos iterators now link to - Removed the storage_shortcut class as that is used only in the Editor, and not BoA - Changed the serialization wrappers (convert, bytes, etc.) to templated inline free functions - Removed virtuality from the scen_data objects, so scen_data_type may be declared global - Changed parts of avs_data_parser that dealt with this - Started using Boost.MultiIndex for the town and outdoor containers in scenario (was bas_file) - Towns are now indiced sequentially and ordered by name - Outdoors are now ordered by location and by name - cleaned boa/iterator/scen_data_iterator.hpp considerably - Uses boost::iterator_adaptor<...> - Removed scen_data_iterator<game_object> - Removed signed_numeric<...> as it does little that numeric_mask<...> doesn't - Removed the use of operator bool() in the determination of a serialized object's validity - Added a scen_data_typed_object<...> base type - Towns/Outdoors now derive from basic_terrain instead of holding an instance of them - Removed the paired_container class and replaced it with the paired_fixed serialization wrapper - Removed the detail::serialize free functions and replaced them with the appropriate serialization wrappers - Put a serialize method inside set_vector - Cleaned up (removed superfluous methods) boa/class/std/set_vector.hpp - Added several specialized pair types in boa/primitive, such as special_rect, info_rect, sign... - Removed the num_dims metafunction, as it has not been used for some time - Moved some constants in boa/primitive/graphics.hpp to boa/detail/constants.hpp - Added a more descriptive, useful exception class - Removed set_string and replaced it with a fixed_string serialization wrapper class. fixed_string is used explicitly in certain pair specializations - Added a serialization method to introduction - Changed the arg type for move_block/look_block from scen_data_iterator<terrain_type> to terrain_type & - Added a utility module - Added a utility that glues outdoor sections into a multi_array - Added a mechanism for the creation/storing of terrain properties through the use of terrain_property_maps. The supported properties are: light, corner and cliff (UBB mangled the indentation)

I think I built a soundless editor for CPeters. Given he still has it, you could get a copy from him.

Quote: Originally written by White Lady xx: Is there a way to turn off the sound in the 3D Editor? There is no way to turn off sound in the 3D editor. If you are having audio problems starting GarageBand tends to help for some reason.

Quote: Originally written by Ephesos: I have version 1.02b5, the most recent one from the SourceForge site. I can't find anything newer. Version 1.02b6: http://tinyurl.com/fjjr2 Note: It has 1.02b5 in the Application's title bar, but it is version 1.02b6.

This bug was fixed in the latest version of the 3D Editor. You're probably using an older version.

Changes to suncome: - Created a modularization for the rendering algorithms, by creating a rendering package concept. Somewhat of a hack, but better than the original. - The two dimensional drawing algorithms were ported to this modularization, as well as some of the three dimensional drawing algorithms. The porting of the three-dimensional drawing algorithms prompted some changes to remembrance, listed below. - Solved the drawing problem created by wxWidgets, and added an illuminate_graphic algorithm used to apply lighting to a graphic. - Found a way to represent tools such as Select, Paint, Flood Fill, etc. using the event handling DSEL I wrote for suncome. Some of these changes should be in the CVS. Changes to remembrance: - Added an outdoor_cementer class that wraps a bas_file and treats the entire outdoors as one single terrain. - Removed the can_travel algorithms as their equivalents in the Editor are never actually used. - Removed the sight_map class, and generate_sight_map algorithm. - Introduced a system to deduce and retain terrain properties such as cliff height and visibility. The system uses the terrain_property concept and the terrain_property_map concept. - Added the light property (replaced the removed sight_map), cliff property, and corner property and their respective generation algorithms. I don't believe any of these changes are in the CVS repository. That was about one or two weeks ago. Given I have time next week, and there are no major compile-time bugs in remembrance, I may release v1.1 of remembrance. As to when the entire project will be finished, I cannot say (which you should know by now). Once I get the 3D view done, I should be able to release a build that lets one view .BAS files, without doing a whole lot of editing. I do not know when this will be. It probably won't be soon, as I won't have very much time, if any at all, to work on it in the near future.

Yes.

Quote: Originally written by Ashbywolf and Imbanophobia 5567: I was wondering how the project was coming on? As of now the current goal is to get past some of wxWidgets' more cumbersome details, and create a more concrete connection between the gui and algorithms, meaning the more redundant parts of creating a gui are almost complete. Technical Details: The sub-project BoALib (renamed remembrance, after the Avernum month) is more or less complete, in that its design is done. Several algorithms are missing, but it should be useful to anyone who wants to create a utility that manipulates/manages .BAS files. The current file release (v1.0.0) does not contain a readme, which I will have to put in sooner or later. The CVS version (v1.0.2) contains a fix for the generate_sight_map functor, and makes numeric_mask easier to use. The gui sub-project is now named suncome (cvsroot/boaedremake/boaedremake/suncome in the CVS repository). I have added a utility to get past wxWidgets' cumbersome interface that includes a small event handling DSEL, mostly completed. The view concept is next.

Try changing the name of the flag variable.

I don't know if this is it, but you seem to be missing a parentheses on line 55. (Where you call get_flag.)

Bah! Take it and leave me be!

If you don't mind, could you email it to kernelknowledge (at) users (dot) sourceforge (dot) net, so I can load it onto SourceForge. Thank you for your help. EDIT: Nevermind. EDIT: The correct version should be on SourceForge, but it contains no documentation, as I was too lazy to download Stuffit again.

This bug was fixed in the latest version. Taking this combined with what TM experienced in the importing of towns is leading me to believe that there is something wrong with the current file release on Sourceforge. Since I don't have a Mac I can't tell for sure. Could someone else with OS X 10.4 redownload the latest version of the editor and see if it works? Oh, and just to make sure its the same bug, Nicothodes, try using the About option in the Help menu and see if the program crashes. Also, just in case this bug doesn't get fixed quickly, you should know the original editor on Spiderweb's website should work.

Quote: Where do we stand with regard to a release? I mean, is there still a lot left to do? After I finish reimplementing Boost.Multi-Array, I'll go back to work on the gui. The big thing to do here is create an editing interface that works as independently of specific details as possible. As in, escaping an interface that requires separate town, outdoor and scenario menus. I should have a bit more time in about a week or two. Al my college application should be in by then. Quote: For those less erudite in code, could you explain what all of the things really do for the designer? Not much, if anything. Those changes are for better, easier-to-write code. Quote: It seems that KernalKnowledge12 is mostly optimising routines already present - by using a better implementation of them. I'm not optimising anything. Just conceptualizing someone else's code. Jeff wrote code that was meant to be finished, not changed. I am trying to make sure my code, at the very least, lasts.