Aran

http://spiderwebforums.ipbhost.com/index.php?/user/3580-niemand/ If you send a PM, he might get notified by email. I have not seen his new email anywhere in public, though, so we can't really help with that.

Shouldn't be too tricky; it basically involves finding the part of scenario.cpp where the various structs are defined, and start counting byte-lengths. It's not an investigation I can undertake, though. In fact the whole Forge thing is going on the backburner for the next month or two; I have classes starting next week, and another TA job.

Don't let him go until he promises to make Blades of Geneforge!

Exile and the first Avernum trilogy. Can't really decide between those two, but I'd have to say I like Exile 3 and Avernum 2 best.

Even more stories about ponies. But currently I'm reading A Brief History of Time.

About that. Let's assume that your end goal is a reasonably usable Total Conversion maker from scratch: Something with a learning curve like Blades, but that you can use without knowing the word "hexadecimal". Not necessarily WYSIWYG but still with a graphical interface. And you want the source to be in a state where anyone can join in or take over, otherwise there's no point. That is a huge project regardless of what game you want to do it to. Examining the binary game data is the smallest aspect, while the vast majority is simple generic software design: Data structures, modules, design patterns, UI, documentation, testing. The parts you notice the least in the end product are some of the hardest.

Now with scroll-wheel zooming and stuff. (Note: github URL is changed to http://github.com/cburschka/forge ) Edit: The next couple of updates will mostly clean up the code to change it from a dirty prototype into something easier to extend and maintain. Nothing interesting, in other words.

... "Putting the mare in Ermarian" Dammit, why does it take me this long to come up with pony puns?

Ugh. I have learned more about Gtk than I wanted today. Viewer basically works now, though, and you can open scenarios and stuff. Not sure if this even works on any other system. If any of you feel up to installing Python 3, PyGObject, GTK+ and the Windows version of BoA - regardless of the platform - some feedback would be awesome.

Pretty much, yeah. I don't think I can come up with any kind of long-term effort in that direction. Best I can do while playing around is to have my source well-documented and public, so it may at least be useful if someone else wants to take over. Choosing Python over some flavor of C like everyone else probably doesn't help, but at least this should never get stuck in a porting nightmare.

Definitely! As far as the python GUI goes, I'm having some difficulty with different toolkits and libraries that don't work well together. pygame is essential for the image manipulation and drawing - it can "blit()" (no relation) bitmaps into other bitmaps (such as tons of sprite images into a map) incredibly fast. But there are no GUI toolkits that have been maintained for any length of time - one of the most popular died on Google Code about two years back. GTK+ is an awesome toolkit for that, but connecting it to pygame has some pitfalls I haven't worked out yet.

AAAAAAAUUUGHH I found some other bug in the scenario scripts, by the way. begindefineterrain 332; import = 122; #122 is never defined anywhere. I'm going to treat that as a "clear" command in my parser for now. Edit: New AvernumScript parser, and some better mapping code (see github) that works with walls, offsets and multi-icon terrains. New VoDT map: http://stuff.ermarian.net/arancaytar/valley4.png (Wall corners aren't drawn yet; that takes more special code.) Edit: Apparently my bitmap-drawing code is crazy-slow. I replaced it with pygame and now the VoDT map is done in 2 seconds. Edit2: Scrollable Map GUI is done. Kind of primitive (no zoom, resize and stuff), but done. Scripts are at https://github.com/cburschka/forge Now includes a setup.py installer for configuring the location of the BoA data (Windows version required; it can't handle resource forks). I'm kind of surprised that I got this much working in three days. Edit3: In fact, there's an experimental GTK+ based program now that can open scenario files to scroll around the world and stuff. Also, I'm noticing that my current mapping method (make one big picture) is only useful on roughly square outdoor maps. With crazy dimensions like 1x15 (not that that would be something anyone would ever do), the isometric map is as big as a stupendously massive 7x8 map, rendering a whole lot of blackness just for a single diagonal strip. For ZKR, pygame just gives up. A better idea would be to render each sections individually, to avoid wasting space.

It would probably be feasible to make a new editing GUI with the pygame library. If I did try to make a new editor, that'd be where I'd start looking - but as mentioned I don't have the stamina or time to stick with that kind of project for long. (I'm doubtful that any of this - especially the Python code - could be integrated in the existing editor, because it's an ancient codebase and apparently isn't cross-platform.) (Not to bash the existing editor, but this whole concept of loading only one zone and one town seems like an obsolete legacy from back when memory was scarcer.)

Yeah, that's how I got the docs I made so far. Right, forgot there has to be a reference to the outdoor location... and I guess that unless the section is changed with a script, you always exit in the currently loaded outdoor section. Anyway, mapping code updated a bit. It can now generate a 1:1 isometric view of the outdoor map, but it only uses floor type so far (not height map or terrain). Unfortunately, my code for writing such large bitmaps is slow, and takes 10 seconds per outdoor section. It might be a good idea to look at tiles instead of a single file, like the Minecraft Overviewer does it. http://stuff.ermarian.net/arancaytar/valley2.png And with terrain: http://stuff.ermarian.net/arancaytar/valleyterrain.png Note that the wall-drawing code in BoA is quirky, and determines wall graphics by environment rather than defining a new terrain for each. The wall graphic is also shifted around a bit, and according to the script comments some of it is hardcoded into the engine. Haven't tried to touch that yet.

Yep, this information is only accessed by the scenario editor to generate script code. You could presumably leave this part blank (or put it to other creative uses) and only break inter-editor compatibility rather than game compatibility. I'll move it into the "editor information" heading. (The format appears to have several quirks like this, like the platform identifier that is always set to Mac.) What I haven't figured out is this: 1194..119b location exit_locs[4]; 119c..11a3 macRECT in_town_rect; Do these just store the same information; once as corners and once as a rectangle?

(Ractors!)

This all started with thoughts about the Blades Forge site (still want to bring it back some day), and potential features for it. For example, it could retrieve information from scenarios - maps, statistics, that sort of thing - for display. Or it could try to lend a hand with actual development work and version control, rather than just being a place for hosting zip files. All that, of course, required me to finally take an actual look inside the .bas file format. Considering all that's been done in the past nine years or so, I'm really late to the party. Well, the first thing I found out is that nobody bothered to document the structure of the .bas format; probably because all the work so far has been in C++ where you can just reuse the classes from the editor, and don't need to pay attention to which record is stored where. So I took a look at the editor source and made a start at writing this stuff down. It's mostly a list of byte offsets from adding up the variable lengths, plus some notes on value ranges and usage. Still has a lot of errors, probably. After getting acquainted with the format, I wanted to play around with it a bit, and wrote some Python scripts. Managed to print out a text-based map (hex codes) for VoDT. The next, somewhat more ambitious idea was a colored pixel map (it's tiny of course), where the pixel colors are derived from averaging the floor graphics. I'm not sure what to do next. If I set out to create an entire new scenario editor on my own, it'll join the scrapyard of unfinished projects pretty quickly. But I rather like the idea of having a Python toolset that can read and write scenario files, even without a GUI. So here's the small amount of stuff I made so far: http://github.com/cburschka/forge

The Pied Piper Project has joined the Encyclopedia on eris. You may experience a brief outage as the DNS records propagate over the next few hours.

As of September 22nd, the Ermarian Network is being prepared for a gradual move to a new home. After more than seven years of being served by DreamHost (who I've been very happy with, but whose shared hosting plan isn't sufficient anymore), I'm going to be renting a virtual server from CloudSoarer. I'll be posting the status of the move periodically on here. For a start, the Encyclopedia Ermariana is the first site to be hosted on the new server, eris. (Edit: Better title - "Putting the clop in Encyclopedia.")

Oh come on, at least make it rhyme. Adventurers are Naught but trouble They'll surely turn Your town to rubble Unless you clear That awful stubble Burma Shave.

STOP RIGHT THERE CRIMINAL SCUM

I'll be there

And now it's an Apple computer. (I'll be here all week!)

"It's hard to know for sure. That was one hell of a night, let me tell you."

...okay.