KernelKnowledge12

Email sent.

Do you need me to email you the source, or can you access the CVS? (For reference, the CVS module is called Mac3DBoAEDitor.) EDIT: Are you willing to load it onto SourceForge also?

XCode Download: Here Apple Compiler Tools: Here Be warned, the XCode download is pretty big. You may want to just download GCC for OS X. The second link is supposed to get you there (that's what GCC's website says), but I can't seem to find exactly where the actual download is.

If you have Mac OS X 10.3 or greater you should have XCode (a C++ compiler) on your computer. If not you can download it at apple.com (though this will take a while). Either way, XCode is the compiler that the Mac 3D Editor's code was originally and is compiled on. Also XCode uses gcc, so you can use that as an alternative. I PM'd my email address to you, so just email me if you need me to email the source code. (Don't download the SourceForge release of the code, use the code from the CVS Server). Also, just so you know, as I don't have a Mac I don't know for sure if the bug fix will work, so make sure to check, although I'm pretty sure it'll fix it. (The bug I'm talking about is the bug mentioned in the Mac Editor Updated topic.) Thanks again.

As of now, I am the only developer who's working on the 3D Editor/Remake, but unfortunately I am a PC-user, which means I cannot create Mac binaries. So I need someone who can to build the sourcecode and give me back the zip/sit file, so I can load it up onto Sourceforge, or load it themselves, if they have the time and are able to. No coding would be involved, but coding experience is definately neccessary. Can anyone help out?

I think I found the bug, but I can't actually test it, since I don't have a Mac, which means you'll have to help me out. First things first, can you build the code yourself? If not PM me your email address or email me through sourceforge, so I can give you some instructions.

This is incredibly usefull!! I'll see if I can fix it, but I won't be able to actually build it into a program, so I'll probably have to ask someone to do this.

You might be the first person using the editor and 10.4 together. I don't have a Mac, and as of now it seems safe to say that I'm the only person working with any of the editors' source code, so I may not be able to help too much, but I'll do what I can. Did you get an error message or did it just crash? What were you doing right before it crashed? Did you just hit 'Ok" on a dialog button, and the program crashed? If so, try doing some other things that require a dialog box and tell me if they cause the program to crash too.

Linthar - What version of the 3D editor are you using? I looked at Jeff's/Isaac's code and they are near identical. Either Jeff didn't make the change where he said he did, or either Notus or Isaac made the change already.

I'll fix it as soon as I can, and hopefully there'll be a release for download tomorrow. EDIT: (Nevermind)

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.

On another note, does anyone not have support for OpenGL? It appears wxWidgets isn't quite as usefull as I had hoped in the graphical arena, and I am contemplating using OpenGL for this part of the editor.

Does anyone using the 3D Editor experience this problem?

Easy to change is somewhat of an understatement; I could change it in less than a minute, but for a change so small, I'd rather not make another release. I could, however, apply changes to the code and load it up to the CVS server if its really neccessary. Anyone who'd want to use the fix would have to build the application themselves (I'd include a Bakefile to make this as simple as possible). Just so you know, the game itself might work differently than the editor. It might do the check itself, or it might just crash instead of displaying the item outside of the container, so it would probably be better to do what Kel said.

Not in the current editor. You'd have to go in and change the editor's code, and I'd rather not create another release for something this small.

Sorry if I confused you. Essentially clicking on the aforementioned phrase, does change the contained/not contained (hereafter referred to as C/NC) status of an item, but quickly after this, the contained status is changed back. I'll now try to explain why this is not exactly a bug. An item can either be on the same space as a container or not. By default an item that is on the same space as a container has the status of "contained". An item that isn't on the same space as a container has the status of "not contained." Now while an item that isn't with a container can't logically be contained in anything, an item that is on the same space as a container does not neccessarily have to be contained within it, hence the reason for the existence of the C/NC property. Or at least what I infer to be the reason. When you click to change this property, what the editor does is first change it, then check to see if the said change is valid, in that the change does not defy logic. This check, however, does not take into account that an item in the same space as a container does not have to be contained. Whether this is intended or not I cannot say. Now as to why the item's C/NC status is always changed back to its original status. When an item is created, its C/NC status is set to the aforementioned "default". When you try and change this, the check notices that its changed away from the "default" and changes it back. Hope this clears things up.

This is another one of those confusing parts of the editor. Based on the code, clicking on the "Contained"/"Not Contained" text does change whether the object is contained. Afterwards the editor goes into the check_selected_item_number() function, which accroding to the commenting is called to ensure there are no errors in the selected item/creature/etc. This in turn calls a function (set_all_items_containment) that goes through each and every item in the current town, and checks whether the item is in the same spot with a container or not. If it is it's automatically set to contained, and if it's not, it's automatically set to "not contained". I don't believe its a bug, but rather a forced limitation. It all depends on how an item would look when its Not Contained, yet on the same spot as a container. Either way the new editor will have, what I hope, is an easier way to edit details such as that.

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.

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?

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: 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.

"A bit crude" may be an understatement, but after the alpha release adding features shouldn't be too hard.

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.

I am not in charge of that.

Quote: Originally written by Kelandon: I am told that the main coders on this project are all quite busy at the moment, so it will be a while before we see anything. I'd expect some results to happen this summer. Notus and I are very busy at the moment, although I will be free to code in about two-three weeks. Isaac did not plan to be a main developer, and will most likely help more when the graphics code gets ported. If the original graphics code does not surprise me with any other examples of bad code, there should be an early alpha release by the beginning of summer. At this point it should be like the original editor (with a 3D view), but with a palette for picking creatures/items/terrains/floors. After this, I'll try to create a better porting utility so some more BoE scenarios can be ported, though this may not be possible. Also I will take a lot of time to comment my code, so others may become interested to lend a hand. Just so it is known, I'll be pretty busy over the Summer with several projects, so progress may be a little slow. I am not aware of the other developers' plans for the summer, so this is mainly conjecture. Any other questions/suggestions are welcome, and thanks to Kel for answering Jadewolf.