Banana

Maybe it's still missing an important patch, or maybe it's just that the administrative stuff (purchasing etc) isn't ready for release.

I like almost all Spiderweb's RPGs, though for different reasons. Nethergate would slightly edge out the others if I had to vote for a "best".. I love the setting, the dual storylines, the system, the Phil Foglio pictures, etc etc. Actually, a slight digression: Jeff's mentioned doing an update of Nethergate that Carbonises it, increases the resolution, adds bits etc. I think that's a good idea, and will almost certainly buy it, but I just hope the system doesn't get overhauled for the worse. Though it was extremely minimalist compared to Exile III, I liked the explicability of various things - for example formulas like "hp = level * endurance" were right there on the character sheet. I don't think it worked quite so well in Avernum 1, but that's yet another digression. As for the actual topic question: no Avernum 4's good, better than some of the Avernums, but it's no Geneforge/Nethergate/Exile III. It's simply too action-oriented to be the best.. although the action is rather good. Actual new 'tricks' and elements to fights were a nice surprise.

Quote: Originally written by Walker White: Are you suggesting arrays that only persist within a single state and need to be reinitialized each time the state is called? No, I just wasn't thinking properly when I made the post. It doesn't matter that the SDF-heap is persistent, as long as different scripts don't clobber different parts of it. Space vs time tradeoffs.. it's just like Embedded Systems 204 all over again I agree that a real malloc system would be unnecessarily messy. It would necessitate something like your states-as-functions hack, too. Incidentally, I do that slightly differently - I've been playing with having a set of globals like this in every script: Code: short s0, s1; //stack pointersshort r0; //return valueshort a0, a1, a2; //arguments and setting up a proper calling convention - caller's responsibility to save stack, callee's to return properly. I have state constants along the lines of Code: short GET_VALUE = 130;short GET_VALUE_A = 131; and use set_state_continue(s0 / 10); to return or jump around. This allows for granularity within states without having to swap memory cells around or massively overload return_offset, but it does turn some states into a mass of Code: if (s0 == STATE) {} else if (s0 == STATE_A) {} else if (s0 == STATE_ {} I'm thinking of writing a set of m4 macros (or a "compiler") to turn all this out given c-like functions as input

Linked lists are not hard at all. Here's an implementation: http://banana.ucc.asn.au/t0NewTown.txt Drop it in as a town script and watch the console output when the party enters. Notes: This implementation pretends that SDFs are a flat address space by using / and %. For example, SDF "8000" -> (8000/30,8000%30) -> (266,20). The only issue with using SDFs as pointers to SDFs is that they are 1 byte rather than two, so I've encoded pointers across two SDFs with a naive algorithm: bitshift one of them left 8 by multiplying by 256. The overhead is therefore 2 bytes per link node. Unfortunately, given a 9 KB address space, this is not insignificant. A tree or other multiply linked structure would be trivial

The 9k limitation is certainly annoying if you want to use this trick for persistent data structures, but it's not a problem for pseudo-stack arrays. We could just set aside a range of, say, 1000 SDFs as the 'array area' and reuse it as necessary. Of course, you'd need to make sure to initialise it every use, which could get slow.

Much appreciated news. It's great to know that bugs are being fixed and capabilities added.

I, and many other UK English speakers, use "dialogue" for both computer things and speaking. Similarly, I've met Americans who use "dialog" for both. It's just another one of those color/colour things.

You could, for example, have the monster drop a "crate" (or have it created when the monster dies) which is actually an item, and which when opened (used) grants the special item.