Spidweb

I have no idea what's happening here, but I do know this: when someone searches a container and block_entry is called, that only affects whether the party is able to get the objects in the container. When searching, block_entry does not affect movement at all. If you are using set_terrain on the space, that the original terrain type was a container really shouldn't affect whether the space can be walked into or not. Odd.

Yep. Whenever you use set_total_visibility to make everything visible, always, always, always have a matching call turning total visibility off. - Jeff

Gotcha. Thanks! - Jeff

If you would like your article posted to our website please email it to blades@spiderwebsoftware.com in plain text. I think it might be useful.

Originally, I wanted to have a page on the Avernum site where we would provide tons of new, interesting scripts. I see now that this won't work. We don't feel comfortable doing this unless we can check over and test the scripts, and we won't have time for that. So, instead, we're going to have a page with links to Blades of Avernum sites. Since people are already making sites with scripts, graphics, and so on, we'll link to them. There are a lot of sites we should link to that we don't yet. Feel free to post links here or E-mail them to spidweb@spiderwebsoftware.com and we'll put them up. - Jeff

When you remove an item in a pack, all items above it shift down. So if you destroy item 18, say, item 19 shifts down into 18's spot. - Jeff

This call is currently broken. It will be implemented properly when I upgrade the scenario format. - Jeff

The legal range for a memory cell is -32767 to 32768.

Blades of Avernum is designed so any player can take any party into any scenario. The tools given to scenario designers to circumvent this are very limited. There is currently no way to determine the gender of a character. - Jeff

I've been chasing down annoying graphics glitches in Panther. I have a beta v1.0.1 patch available. Before I made it a big public patch, I wanted to see how it interacted with new scenarios. if you'd like to try out the advance v1.0.1, it's in ftp://ftp.spiderwebsoftware.com/temp/ If you try it, I've really appreciate it if you dropped me a line at spidweb@spiderwebsoftware.com. Feel free to write even if it works fine. Knowing it works for people is important. Have a nice weekend. We have babysitting and are fleeing to Norwescon, a science fiction convention near Seattle.

Another in a long list of things I should have documented but forgot to. When a monster is killed, any item in its inventory that has a value of less than 100 coins and is not magic has a 40% chance of disappearing instead of dropping on the ground. This was put in to keep the town's item buffer from being swamped by useless items (and keeping the player from having to sort through lots of trash). If you want the party to find an item for sure, make it magic or high value, place it with put_item_on_spot when the creature dies, or place in in the town, not on a character. - Jeff

DEAD_STATE Not Always Called What a character's character id is -1 (which happens, among other times, when a creature is in an outdoor combat or made by a splitting monster), its DEAD_STATE is not called when it died. DEAD_STATE is called normally for normal creatures. This will definitely be fixed when the Blades scenario format is upgraded in May or June. When this happens, other suggested changes will be made (including, for example, addition of a get_energy call).

Will try to put out 1.0.1 of the editor soon. I will fix broken outdoor section importing, add some minor fixes, and give improved documentation. Windows editor is ported. Windows game porting is well along. Hopefully, the Windows version will be out in 2-3 months.

Actually, I will add this. "If I were you, I would make strides to alienate your designer community a LOT less -- there's a HUGE amount of discontent with your attitude among the best designers and they do NOT grow on trees." Hrmm. Looking back at my posts, it strikes me that my disagreements are very mild and I was very complimentary of Drakefyre's post ("excellent article" were the words I used). I do not see what I have said in this thread to justify anger, alienation, or any reaction more strong than "Hmm. I disagree with his opinion. Oh well." Don't be so mad at me all the time. I'm just a guy sitting in his basement. You'd like me if you met me.

"Further evidence that Jeff Vogel doesn't have any idea what the Blades audience is." The Blades audience is people who sent me a credit card number. Look. The only really good way to write a really good scenario is to write what you want to play. If you are only comfortable writing plot-heavy stuff, rock on. The only point I am making (and I feel it is a very mild point and I'm on pretty safe ground making it) is that a large portion of your potential Blades-playing audience mainly gets off on hitting things. Trust me. I read their fan mail. That's all I have to way on the age-old Plot Versus Carnage rpg debate. Back to porting. - Jeff

"The purpose of Blades is to tell a story FIRST and make a fun game to play SECOND" Heh. This quote is going up on my wall. The idea that anyone writing a game would purposefully put fun second is, I admit, alien to me. You will have to remember that any advice I give is tinted by the community I write for. Consider Geneforge. That game has as elaborate and detailed a plot as anything I have ever done. But a huge portion of the player base is mainly excited by the ability to have a bunch of pet dinosaurs and burn everything to the ground. That is why I was very careful to make sure that the plot does not get overmuch in the way of the people who have no interest in it. It's been quite a success. Or, to put it another way, a considerably part of my income comes from parents on behalf of their eight year olds. Sometimes, I get ideas for really plot heavy, intricate story games. I tend to discard them, as writing too many games like that would cause me to end up losing my house. And, while ratings of scenarios are interesting, it is important to remember what any statistician can tell you: self-selecting samples are invalid. The people most likely to enjoy carnage-rich scenarios are arguably the people least likely to get into message board discussions about them. But one person's opinion (mine or yours) won't make any difference. Just write what you want to play, and then hope that the audience is there. - Jeff

Another excellent article. When I am stuck designing an area or making the plot of a game, I always find ideas by returning to basics. "Who is here? What do they want? How are they going about getting it? Where do they live? What do they do from day to day?" In answering these questions, I always get ideas. I would only warn people not to let the tail wag the dog. Most people play Blades to beat up monsters and get phat lewtz. You need to come up with a reason why the Evil Monsters are in such and such an area, but don't feel the need to come up with something completely rational and bulletproof. My all purpose excuse is the "Area on the edge of the Empire." It is better to have lots of fun and action in an irrational setting than a scrupulously designed and plotted storyline that is on the dull side. Heck, the Roman Empire controlled more of the civilized world more totally than practically any empire ever, and there were still plenty of wild areas far from the core that needed the occasional pacifying. But Drakefyre is still 100% right here. Plotting and asying "Why?" are a marvelous tool and an opportunity. Thinking along the lines above will make designing a good scenario much easier. - Jeff

There is no call to actually instantly boot the party out of a town. The best you can do is teleport them to a location at which they are then forced to walk out. - Jeff

I think I can answer this one. Some graphics programs (AppleWorks/ClarisWorks, for example) can set the PICT's bounding rectangle in a weird way when the graphic is copied out of the application. This can cause this behavior. To fix it, in your graphics program, shift the icon so it is at the far upper left corner before you copy-paste it into the resource file. (In other words, move it to it's as far up and left as it can go without shifting off the edge.) - Jeff

I suggest going beck to section 1.1, rereading it, and going through all the steps in it. Scenario design is not easy, not at all. It's a complicated system. But it is possible, with not much work, to make simple scenarios. Go back to the step by step guide in 1.1 and work through it. Make simple scenarios and play through them yourself for fun for a little while. Only then, when you're comfortable with the basics, move to the scary stuff beyond.

Look at the script t9griffon.txt in Diplomacy of the Dead. I think this is along the lines of what you're looking for. The main risk is that the party will do so much damage in a round that the monster will die before it gets a chance to become friendly. If you really, really want this creature to live, you might want to have scripts watch for the creature being killed and respawn it if it dies before it has a chance to become friendly.

First, check the description at the top of the script. Frequently, there is a value you can give to a memory cell to make the monster immobile. For example, in the guard.txt script, setting memory cell 0 to 1 or 2 gives various flavors of immobility. Second, the set_mobility call can stop any monster in its tracks permanently. Third, you can make any monster never move by never giving it any calls that might make it move. This includes do_attack, by the way. If you want the monster to use regular attacks, you'll need to use set_mobility.

Yes. Humans are species 0.

In Mac BoA v1.0, all missiles have a chance of appearing on the floor. There's a 50% of a missile that misses landing. A missile fired by a PC that hits has a 60% chance of appearing on the floor. A missile fired by an NPC that hits has a 10% chance. In all later versions of BoA, only non-magical missiles will appear on the floor. They will only appear in the case of a miss, 50% of the time.

Just to play it safe, it is generally best to, after making a change, load a save file outside the town and enter the town. If the ONLY thing you change is a town script, reloading a save file will reload all the scripts in the town. If you chance a scenario script (or scenario data script), loading a save file in that scenario will cause those changes to be loaded.