spyderbytes

Point well made, Nasarius.

I don't think I'm understsanding what you're asking (my own brain fogginess at the moment, I'm sure--hayfever season with its antihistimines is upon this part of the country ). Does set_terrain() not work for what you're wanting to do?

<rant> We could argue this till we're blue in the face without either of us changing our opinion, but I think Java is overrated by those who claim it's underrated. It has its uses, to be sure, but game engines isn't one of them, IMO. And yes, I've programmed it (and at least a half-dozen other languages) professionally in my checkered career. If Java was really as hot as the vocal minority claims, why isn't everyone using it for x-platform development? It's not for a lack of programmers--professionals will learn what they need to land the paying jobs. You could blame some of it on project leads not knowing enough about it to specify it, but a project lead who doesn't do his homework won't be a project lead for long. Yes, there are plenty of options for simultaneous x-platform development, but you know what? This is Jeff's baby, and he has chosen not to use any of them for whatever reason. I could second-guess him if I was so inclined, but it wouldn't accomplish a thing. His living is the one that depends on it, so let him decide how to do it. I'm sure he's well aware he'll sink or swim based on his decisions of what to do and how to do it. That's business in the real world. Nothing personal, Nasarius... I guess I've just gotten a bit tired of the Jeff-sniping in the forums he provides as a courtesy to his customers. I find it to be in rather poor taste. Start alt.rec.we.hate.jeff.vogel on USENET or somesuch, if you really feel the need to spout off. That last is not really directed at you, Nasarius... just a general statement to those who seem to get their jollies from Jeff-bashing. Your straw just put too much strain on this camel's back... </rant>

This is another thing I'll probably only see in my dreams, but it would be really nice to have a predefined END_TALK state for NPCs, called whenever dialog is exited (whether by "The conversation ends", "That's all for now" or ESC/the Done button). I've run into several situations where it would be beneficial to have an NPC react in some way to the player ending the conversation with them. EDIT: Just figured out a way to "kinda sorta" fake this reliably. Just have the character set a flag when the conversation starts (in a code block attached to the INTRO), then have the START_STATE of the character's script check for that flag being set. The character won't do anything from it's START_STATE until the conversation is over. A predefined state to catch it would still be much nicer, if for no other reason that it would (presumably) catch the conversation end in the current turn, instead of waiting for the next one. It would also be much cleaner...

Considering that he's also making extensions to Avernumscript, not to mention bug fixes, and that he said recently Windows beta has been going on for a couple of weeks now, doesn't seem like it's taking him all that long at all. One thing I can pretty well guarantee: he's not taking longer than he needs, just to put off the sheer agony of getting paid by the Windows players.

Thanks, Jeff. That's peachy keen!

I've made a custom thrown missile that's supposed to be, in effect, a molotov cocktail (that is, small damage from thrown missile impact, big damage from fire). But the special ability for doing extra fire damage only applies to melee weapons or ammunition (NOT thrown missiles). Anyone have any brilliant ideas for some way to "fake" this? I'm coming up blank on this one. The best idea I've had so far is to make my thrown missile be, instead, ammunition for some sort of launcher. But I'd rather not do that if I can avoid it (that's getting a bit too 'hi-tech' for the tone of my scenario). EDIT: Ammunition for a launcher wouldn't really work, either. My launcher would either have to be specified a "bow" or a "crossbow". Meaning my missiles would be ammunition for any old bow or crossbow (which would be totaly nonsensical, given my missiles are shaped totally wrong). Not to mention my custom launcher would also fire either arrows or bolts. Humbug! EDIT 2: Anyone see the logic of not allowing thrown missiles to do extra damage like melee weapons and ammunition in the first place? They're essentially just ammunition delivered by hand. Any chance we could talk you into changing this, Jeff? I'd like to be able to come up with new and interesting variants of thrown missiles in just about any scenario I design...

Whenever you're invisible and try to talk to someone, you get a message (via print_str()) telling you that you can't initiate conversation while you're invisible. It was either that or some really complex flag work to have NPCs react to "hearing voices". I tend to use up almost all of my dialog nodes without having two completely different trees for NPCs, based on whether the person addressing them is visible or invisible. EDIT: About the special ability bug... kinda makes it pointless for a designer to go to the trouble to designate something property. I rather hope that hole gets plugged...

Last night, I added a special encounter rectangle to a town, and the only way I could get it to be recognized was to go back to a saved game before the party had ever entered that town. I just now added another, and simply leaving town and re-entering forces it to be recognized. Same town, same exact save file that last night didn't work, different special encounter rectangle (but actually quite near the one that didn't work). The only difference I can think of is that the one last night covered several squares, and the one today only one? So... someone (presumably Jeff), could you please explain to me the rules governing what forces special encounter rectangles to be reloaded and when? It gets rather frustrating, with my "design it as you need it" style, not having a clue whether what I just added isn't working because I have a bug in it, or because it doesn't init on every town entry.

Well, there's also adding and removing special encounter rectangles to be accounted for; but again, that's nothing that would ever affect the player. This would be completely for the designer's convenience. EDIT: See this post for more on this subject. After that discovery, I felt the topic deserved its own thread.

What's this? Special ability bug? Guess I missed that one...

If I'm understanding you correctly, and you're wanting an event that happens every nth tick, an alternative would be: if ((get_current_tick() % n) == 0) { // do stuff here } (where n is the number of ticks between occurences). Of course, that doesn't allow you to start on a particular tick and then every nth one after that... it just hits every nth one starting with the next multiple of n.

I considered that, Drakefyre. It would certainly be easy enough to just call set_items_not_property() when they become invisible. But I couldn't figure out any (good, at least) way to make anything they hadn't gotten to property again when the invisibility wears off.

Picky, picky, Thuryl! Good point I hadn't really thought of (I'm still thinking in designer mode, not player mode ). I was thinking more of the decision on what items to actually place and what are unnecessary junk (which can change significantly if you add a slew of new items, I suspect). But the location of a special encounter rectangle (and which scenario state it calls) shouldn't cause any such problems if they're re-inited every time the town is entered. Or not in any way I can see offhand, at least.

Nutter thing that isn't a call, but something I really, really, really wish Jeff would change. Please, please, PLEASE, make it so that special encounters load every time the party enters a town, instead of only the very first time. It's getting to be a pain to go back to a really old save just because there's a spot that needs a special encounter I didn't think of when I was first designing the town. I'd like to extend that to placing items, but I have an idea there's a more valid reason for only doing that the very first time the town is entered. So I'll compromise and not bellyache too much about the items if I can have special encounters that load each time. EDIT: DOH! I don't know why I didn't think of this before, but one can save SOME trouble, at least, by putting a "dummy" terrain script somewhere outside the town that, when stepped into, calls set_town_status(some_town, 0). That forces the town to be completely reset (including placed items and special encounter locations) the next time you enter it. That's not as good as just having that stuff re-init on every town entry, but at least I can use a save file a BIT more recent since I thought of that.

Actually, I'm not overly concerned about the town turning hostile. In this particular case, the town is teetering on the brink of hating your guts to start with. I just didni't really want to have to come up with some way to make it consistent, within the game, that you're invisible but still "seen" stealing something. The invisibility potion already has some limitations on it (so it's not overpowering). I guess the character who gives it to the party can just add "and oh, yeah... if you steal something while you're invisible, someone might notice it disappearing into thin air and figure out there's someone invisible nearby." Otherwise, I'm afraid players might either think it's just sloppy implementation or that I'm "cheating" them out of their right to steal while invisible.

Any way to override that (crimes being seen) while leaving items marked as property? At one point, the party in my scenario becomes invisible, and I'd rather they could steal with impunity while it lasts. Even if the theft is "seen" and it pushes the town into hostility, no one in this town will react until the invisibility wears off; but it would just be nicer if there were some way to switch off crimes being detectable for the duration of the spell.

Ah... I should have thought to mention that, as well. That means that the call expects you to supply a value to it. IOW, that particular call expects you to supply a short, on_or_off--in this case, either 0 or 1, TRUE or FALSE. In your script, it would look like: set_incidental_sound(TRUE); to turn on incidental sounds, or: set_incidental_sound(FALSE); to turn it off. Of course, 0 and 1 are the exact same things as TRUE and FALSE. EDIT: Since my post doesn't make it entirely clear, 1 == TRUE and 0 == FALSE, by programming convention.

That's probably a good point, for those who aren't familiar with programming language conventions. No, you don't type them. They're only there to let you know what you can expect to get returned (if anything) from a function, when you call it. IOW, if the call definition starts with 'short', for example, it means it 'returns' a value that you can assign to a variable. For example: how_many = party_size(); spot_x = my_loc_x(); Calls that start with 'void' indicate that the call doesn't return any sort of value to you. It just "does its thing".

This isn't a call, but this seemed the best place to add it. When editing a NPC in the Editor, I'd like the dialog to have "next/previous" buttons, to cycle through all the placed characters in town. I made a change that required a new memory cell to be correctly set for all the inhabitants of a particular (populous) town. Scrolling through the town and clicking each inhabitant, then "edit this character" is a hassle, when all of them have to be changed.

Quote: Originally written by Kelandon: EDIT: I hadn't tried it_ed_icon_adjust or any of its siblings, though, because somehow I neglected to notice that they exist. My suspicion is that this will give some idea of what it looks like, but not always a great one. Actually, the only ones (that I see anyway) that exist are fl_ed_icon_adjust and te_ed_icon_adjust (floors and terrains). Presumably, that's because those are used on the mini-map. But for items and creatures, looks like we're stuck with only seeing what it looks like in game.

The method of sending a message to a terrain script should erase the stains at the end of the current turn, rather than at the beginning of the next turn (I'm fairly certain I remember reading that messages are handled at the very end of the current turn). I think that'll get you closer to what you're wanting. The terrain script can just sit somewhere out of the way... doesn't need to be "on" the terrain where it's needed. When it gets the message to go into action, it can either just cycle through the water squares removing stains, or use the trick of the dying monster recording it's x and y in SDFs so the terrain script knows just where to act. A bit of a hack, but I think it'd be pretty close to what you're after. The blood will at least dissipate into the water more quickly than waiting for the player's next action.

I'm guessing the logic is that the windows betatesters will have first access to the "new and improved" Avernumscript. The one where the broken calls we're having to avoid now actually work and the new features that have been promised (and possibly a goodie or two that haven't been mentioned yet) have been added. I can see both sides of the issue, but think that, overall, the way things are is the fairest. As in, given the chance, my baser nature wouldn't at all mind having early access to the new features before the rest of you got your hands on them.

If there's a better answer than that one, I don't know what it would be. Either that or have the DEAD_STATE send a message to a terrain script that breaks out a mop and cleans up any nearby stains. I don't think you'll find a way to prevent the stain. The best I think you can hope for is to remove it as quickly as possible once it's there.

Try just changing the scenario name to hellhole.bas and the main scenario script to hellhole.txt. I think that should do it.