Aran

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.

simplest possible Blades of Spiderweb project

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.

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.

// This bug affects not only terrain 6, but terrain 7, 42 and 43.
// And because of this bug, NW corner wall display in realistic mode becomes odd.
// It's better to fix this bug on corescendata2.txt itself, but it may cause unpredictable errors on the BoA Game.
// For this reason, correct them here.
void patch_corescendata2( void )
{
   // equivalant of "te_blocks_view_e = 0;"
   scen_data.scen_ter_types[6].blocks_view[3] = 0;
   scen_data.scen_ter_types[7].blocks_view[3] = 0;
   scen_data.scen_ter_types[42].blocks_view[3] = 0;
   scen_data.scen_ter_types[43].blocks_view[3] = 0;
}

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.

I don't think the game pays any attention to these:

boat_record_type scen_boats[30]; 6,436 300

horse_record_type scen_horses[30]; 6,736 300

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?

Even when photorealism is possible there will be people wanting to do it with people. For art, if for no other reason. And audiences like real people behind their viewing too.

(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

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.

You have suddenly become a Town Guard.

 

An group of adventurers just stole some random junk.

 

What will you do?

STOP RIGHT THERE CRIMINAL SCUM

For poops and giggles, I once ran a geoIP on everyone who was in the calref chat at one point, and ran it though a script that calculates the "optimal" meeting point (through some sort of weighted average, i presume).

 

Apparently the next meet has to happen in the wilderness of Quebec.

I'll be there

The third had cider spilt on and through it.

And now it's an Apple computer.

(I'll be here all week!)

 

Luke. I might be your father.

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

...okay.

Rereading the original thread, it looks like Dragyn Bob should be connected to Drakefyre (as in Sylae's chart), but not to Alorael. I'll change that, if nobody objects.

Whee, if I have it right on my head, that should make the graph chordal again (no cycles except for cliques)!

Edit: also, if we can maintain this thing as an edge list in a text file and not just a diagram, that'd allow using tools to draw it automatically.

I'm trying to unify those charts and noticed a weird discrepancy.

Diki's chart isn't a superset of Slarty's old one, in that it does not link Sarachim to Marlenny.

Sy's chart is a superset of Slarty's but not Diki's, in that it doesn't link Sarachim and Nicothodes, nor Nalyd and Vergil. (It also omits Archmage Micael and my dad, but both of those are debatable.)

For reference, here are each of the graphs as edge lists with consistent names (eg. Lilith), including in normalized (symmetric+sorted) form.

http://stuff.ermarian.net/arancaytar/swgraph.tar.gz

In an effort to frustrate Neb, I've chosen to behave as if it's inevitable that Iffy, Tyran, and Nalyd will end up living with them in Denver, too.

I secretly ship all of you.

( )

 

...it took you almost twenty-four hours to notice Dikiyoba was wearing a hat. Actaeon could have been facepalming the whole time, and you wouldn't have noticed.

It took me a couple hours of seeing you wear it constantly, even indoors, to find it remarkable enough to comment on, but then I felt weird about bringing it up for a while.

(I mean, sure you've worn a hat in all photos I've ever seen of you, but until then I'd assumed that was coincidence.)

Here's an awful secret: The facepalm was A LIE. There was no facepalm. My worldview was shattered. Does that mean when people type "rofl" they are not, in fact, rolling on the floor at all?