KernelKnowledge12

I looked at the Angband code and all the dungeon creation code seems to be in generate.c. The code is basically straight C, the functions are in an ascending order of importance (meaning the very last function generates a random level) and its very well commented, so it shouldn't be too hard to extract a generic algorithm for each function. EDIT: The code is in generate.c, not dungeon.c.

Angband source: http://www.thangorodrim.net/download.html#source Quote: besides, walls are no longer separate floor squares unlike in the Exile engine. This shouldn't stop you from treating a wall as just a floor. If a spot is to designated a wall, put the corresponding terrain and nothing else. EDIT: typo

You could convert the Angband code into Avernumscript. It might be easier.

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.

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.

PICT files are very well supported in Carbon, and are to Macs what BMPs are to Windows.

Quote: Originally written by Kelandon: In fact, I imagine that once the BoA Editor Re-make is finished, we can just make the editor automatically generate a fixed custom objects script with each new scenario. Actually it'd be easier to create a base custom object script and package it with the 3D editor, as is done with the warrior's grove data. I'd have to add a few extra lines to the code to automate copying, which I won't be able to do for a week or two, but after that is done it would only be neccessary to update the base script. Of course someone will have to build the OS X version.

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.

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: Originally written by Marvin, the paranoid android: Quote: Originally written by The Almighty Doer of Stuff: remove screen stretching plz I'd love to, but I don't know how to. Your post with the script has some very long strings. Get rid of them.

Quote: Originally written by Kelandon: Okay, Apple has now claimed that sound resources are "third-party software," so they cannot provide any technical support. The sound resources aren't corrupt, the part of OS X that loads/plays them is. Fixing this is Apple's responsibility. Perhaps you should explain this to them. If they still refuse to help, I googled OS X Support, and got this site: http://www.macosx.com/ Seems promising.

Well there's some good news in that. Since you can build the editor's source code, you should be able to get rid of sound in the editor (I can tell you what to do if you want to) and get that to work. Also, you can manually go into BoA's preference file and turn the sound off (with a Hex Editor) to get BoA working. This might help, in case fixing the bug takes longer than expected.

Quote: Originally written by Kelandon: EDIT 2: It appears that my computer has some sort of serious internal error. Thanks guys, but I don't think we can solve it here. If you ever do find out what the problem is, could you post it? It seems odd that an internal error would only affect BoA/Editor.

Quote: A corrupted preference file seems the next obvious suggestion. The editor does not use this file, but it does need the graphics from BoA. According to the crash data, the editor stopped upon entering the function load_sound(), which is incredibly odd, and suggests that OS X, did something wrong. Did BoA or the original editor give data when it crashed? Quote: Originally written by Kelandon: The original editor does not work either. I have Xcode, but I have very little idea how to use it. With detailed instructions, I could build the source, but I wouldn't know how to do it myself. The last thing I did with the editor was check the demo's version of VoDT. I chose not to save anything. It was working fine at that point. I've never used XCode, but from the tutorials on apple.com it seems pretty easy to use. Here's the Quick Tour Guide: http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeQuickTour/ index.html First you should get a copy of the Mac editor's source. I can email it to you if you can't access it from the CVS server. I'm not sure, but I think the XCode project file is in the editor, so if it is, open it. If not, you'll have to create it. After that you should just have to compile/build it. All of this should be in the first section of the quick tour guide. After you successfully build it once, we can figure out exactly where the editor stopped working.

Do you have the original editor? If so check if that works. (It shouldn't.) Other than this, I'm pretty much at a loss. If both BoA and the editor don't work the problem is either with the files they share or any calls to Carbon they share. If no other programs (except those relevent to BoA) fail, then the problem should be with the files they share. Can you build the source to the Editor?

Any other programs fail?

Quote: Originally written by Kelandon: EDIT: And oddly enough, no version of the 3D Editor will open. They all do the same thing. EDIT 2: What the heck? BoA won't open either. Gah, time to try re-downloading that. EDIT 3: I did download a demo of BoA and install it to check if VoDT had been fixed, which seem related. It was installed in a completely different folder, and I'm not opening that copy, though. Sounds like a corrupted resource file, although I could definitely be wrong. Check if the demo of BoA works.

Quote: Originally written by Venom: 1. Edit the BoA Editor code to recognize fences as walls (I am assuming it is hardwired into the source code to fill in the corner gaps for walls, as I can find no reference to this in the script). The editor mimics BoA, so doing this won't help. It may make it look correct in the Editor, but it won't in BoA. You'll have to do something else.

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

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.

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.

Windows or OS X? Is scrolling in 3D terrain too slow? If so this has been noted (on windows), but probably won't be fixed. If it's something else, say what exactly is slow. EDIT: Actually for scrolling through terrain, you can press shift and click the scrolling buttons to go faster. Quote: It just occured to me I don't have the 3Dwinreadme.pdf. Somehow this did not end up in the release file. Its there now.

Quote: Originally written by Thralni: I soon discovered that the files were exactle the same, so I just copied all the files of the scenario editor with the 3D view over the other files. This is not necessary. The 3D Editor should work from any location on your hard drive. Try redownloading the editor, and running it. Don't copy over anything.

For Mac Users: v1.0.2b6 - (Thanks to Khoth for building it, and thanks to Linthar for testing it.) Fixes the bug in OS X 10.4 that makes the program crash after closing a dialog box. For Both Windows and Mac Users: v1.0.2b6/Windows beta test release4 - Fixes the Contained/Not Contained bug. Now an item that is on the same spot as a container does not neccessarily have to be contained. Get it here. Concerning the Remake (for programmers): The project organization has been changed a little. The cross platform/non-gui elements of the remake have been extracted and put into a static library in the CVS module: BoALib. It's not complete, but it should help anyone who wants to create editing tools. Also, a bakefile is included in the CVS release.