Kelandon

Resorcerer . Not free, though. There are demos floating around, I think.

Preview, ResEdit. Both free. Use Preview to open anything you've downloaded off the web in, say, GIF or JPEG format. Paste those into ResEdit to use them in new scenarios. Also use ResEdit to look at the included graphics.

If we get these things, I would also like a much more solid variables system. Right now variables get messed up when reloading in the outdoors. I want variables to STAY, just like SDFs.

I think the max level for NPCs is actually 100. Chapter 2.6 under "Level and Statistics" in the docs says this, and I have monsters set up as high as level 100 in the HLPM.

Max script size is something like 172k. I hit it in the HLPM's scenario script (all those darn shops). Consecutive executed snippets of code: 32000, or thereabouts. What actually counts as a snippet is not 100% clear; apparently flow controllers are one and their conditions are a second. Placed monsters per town is (obviously) 80, plus 34 summoned. This is the only maximum I've actually had trouble with. Joined NPCs is 2. More as I think of them. EDIT: String characters, 254 (256 if you include the quotes), except in text bubbles, where it's 38. Dialog box choices, 3 (obviously). Custom graphics sheets, 100 (supposedly, although I think you can just ignore this one).

Numbering system in place now. Could someone explain to me (because I don't knw any programming whatsoever outside of Avernumscript) what matrices and vectors can do that SDFs can't? My thought was that request_target would work exactly like targeting a spell or wand. It would just return the number of the target selected, which could be hostile, friendly, neutral, whatever. I wanted set_char_presence_status to look an awful lot like char_status, because char_status checks the value that set_char_presence_status would set. That's why (unless more people object) it stays as is. Besides, Jeff will come up with the final names anyway, assuming he even implements any of this. TP suggestions: 1.1, 2.1, 4.1, 4.2, 5.3, 7.9, 8.1, 8.2, 8.3, 8.4, 10.1, 11.1.

Because I suspect the possibility of Jeff implementing something like that is even smaller than the possibility of him implementing our easiest suggestions. Am I off-base here? Other opinions?

Okay, there's a new thread for prioritizing our list . Stop by and explain which calls you think would be most useful and why.

Okay, so we've brainstormed a list of calls that we'd like to see added to BoA for the next scenario format, assuming that such a thing happens. The list is rather long, so it seems like we should pare it down a bit before we submit a finalized list of realistic calls to Jeff. Some basic rules for prioritizing: 1. The new calls should be simple to implement but add powerful functionality. As an example, I think the missile animation call would be great because it hardly requires programming anything new: it would be very similar to the Animation and SFX Calls already in existence, and it uses animations that BoA already has. 2. Our top priority should be to make things possible that aren't possible now. Calls to make certain things easier to implement would be fine if we expected to get all of our ideas into a new scenario format, but we won't. Anything that can already be done or simulated is a low priority. 3. Everything needs to be backwards-compatible with older scenario formats, so no one has to go back and reprogram VoDT so that it works with BoA v1.2. We can still change existing calls -- and in fact, since these don't require a new scenario format, these suggestions are the most likely to be implemented -- but the suggestions need to be like the suggestion for add_item_to_shop: they can't change the effects of any code that's already written. 4. For the most part, we are now prioritizing, not brainstorming. Keep new call suggestions to a minimum, although they are still acceptable at this point. I have preserved the old numbering system (even though, by deletions and moving, it doesn't quite make sense anymore) so that one can still follow our old discussion. We have discussed using the following terminology: Top Priority: these calls would be tremendously useful and easy to implement. If Jeff does nothing else, we hope that these get put in. Top Priority calls are marked with a TP. Would Be Nice: we'd like to see these, but they are not Top Priority. Maybe they'd be so complicated to implement that we doubt that Jeff will actually take the time to do so. Maybe they would only be useful in very specific situations, so that they're not as powerful as we would like. They'd still be useful, but we're not pushing them nearly as much. Would Be Nice calls are marked with a WBN. Not Likely: we have serious doubts that these will make the cut for the new version. We may not even send these in to Jeff once we're done prioritizing. Not Likely calls are marked with an NL. THE LIST OF CALLS Advanced Dialog Box Calls **** OUR #1 TOP PRIORITY **** 1.1 void add_dialog_pic(short which_pic) - Puts a dialog picture in the upper-left corner of the dialog. Animation and SFX Functions TP* 2.1 void put_missile_animation(short source_x,short source_y,short dest_x,short dest_y,short which_sfx) - Missile animations. 2.2 SFX calls to work in the outdoors (or at least the ones that put an SFX on a space -- putting them on characters could be somewhat odd). Terrain Script and Creature Calls TP* 3.1 short get_creature_memory_cell(short which_char,short which_cell) - Returns the value of memory cell which_cell of creature which_char. TP* 3.2 short get_terrain_memory_cell(short which_script,short which_cell) - Returns the value of memory cell which_cell of terrain script which_script. 3.3 cast_spell(mage_or_priest, which_spell, spell_level, is_forced) - For creature AI scripts only. Causes the creature to cast spell which_spell at spell_level depending on mage_or_priest regardless of mage or priest spell ability. If is_forced is 0, the spell is only cast if the creature has enough spell points, otherwise the spell is always cast. 3.4 void revive(short pcent_or_amt, short amount) - where if pcent_or_amt is 0, then amount determines the percent of HP the character is revived at, and if pcent_or_amt is 1, then amount determines the number of hit points the character is revived at. It would be used in a creature's death_state. I want this so that creatures can be killed but still not-totally-die. (This would simulate Lifesaver amulets on monsters.) Shop Calls (a new category) 4.1 short shop_item_quantity(short which_shop,short which_item) - Returns the quantity of which_item still left in the shop that can be bought with enough gold, 0 if the item is not there. TP* 4.2 void add_item_to_shop() - Allow negative values for modifying shops. 4.5 void shop_selling_options(short which_shop,short selective_sell_category,short cant_sell_this_category,short can_resell) - Changes whether or not a shop will purchase certain kinds of goods, like in Exile. selective_sell_category is the variety of the item that is affected. The varieties are exactly the same as they are in the custom item scripts (like 1-handed,pants,ring,etc...). If cant_sell_this_category is 0, a shop may purchase items of the defined variety from the player. If 1, not. If can_resell is 0, the shop won't list the bought item back on its inventory for sale. This means that a shop can buy an item, but not resell it. All of the varieties default to being sellable by the player when possible, and can be resold by the merchant. The Passage of Time Calls 5.1 void calculate_ticks_forward(short num_ticks) - Makes the game calculate num_ticks forward, and of course will act upon these calculations. 5.2 void set_day(which_day) - Changes the day to which_day. TP* 5.3 void set_year(which_year) - Changes the year of the scenario to year which_year. 5.5 void set_daylight(short how_much_light - I assume that the engine has 'levels' of daylight as the day progresses to determine how much to darken terrain and such. This call sets the amount of daylight to how_much_light. 5.6 short get_daylight() - Returns the current level or amount of daylight. 5.7 void stop_daylight_progress(short stop) - Starts or stops the progression of daylight throughout the scenario. If stop is 1, then the daylight will stay the exact same as it is when this call is used. Daylight will change if stop is 0. Advanced Item Management Calls 6.1 void identify_item(int item_type) - Identifies all items of item_type currently in the party's possession. 6.2 void identify_item_with_class(int item_special_class) - Identifies all items with item_special_class in the party's possession. 6.3 void identify_item(short which_char_or_group,short which_slot) - Identifies the item on which_slot of which_char. which_slot of -1 implies all items on that specific character or group becomes identified. Should probably only be used on party members. 6.4 short item_loc_x(short which_item) - Returns the x of the location of item which_item. which_item refers to the items ID in the scenario editor. If the item has either been picked up or non-existent, call returns -1. 6.5 short item_loc_y(short which_item) - Returns the y of the location of item which_item. which_item refers to the items ID in the scenario editor. If the item has either been picked up or non-existent, call returns -1. 6.6 short item_on_spot(short loc_x,short loc_y,short which_item) - Returns 1 if there is an item of type which_item on location {loc_x,loc_y}. 6.7 short take_item_on_spot(short loc_x,short loc_y,short which_item) - Returns 1 if there is an item of type which_item on town space {loc_x,loc_y}, 0 otherwise. If there was an item of that type on the spot, destroys one of it (or, if item has charges, takes 1 charge). If which_item is -1, destroys all items on the spot and returns 1 if an item is destroyed. Basic Character Calls 7.1 void set_char_presence_status(short which_char,short which_status) - Sets the status checked in char_status (whether the character is dead, not present, etc), as opposed to the status checked in get_char_status (whether the character is blessed, hasted, etc) which is already settable. 7.2 short char_weight(short which_char) - Returns the weight of the character which_char. TP* 7.3 get_immunity(short which_char, short immunity_type) - Returns a value from 0 to 100 depending on the assigned immunity value. TP* 7.4 set_immunity(short which_char, short immunity_type, value) - Sets a value from 0 to 100 to the immunity_type. TP* 7.9 void deduct_ap_from(short which_char, short how_much) - Counterpart to deduct_ap(), but you can affect other character's ap. Probably more useful in terrain scripts and custom abilities. The affected character's ap is reduced by how_much, which can be negative to add ap. Town Calls TP* 8.1 void change_lighting(which_type) - Allows us to make the dungeon totally dark, fully lit, etc. TP* 8.2 void add_light(what_amount) - Gives ability to change the light level (as from torches or Light spells). Can be negative. TP* 8.3 short get_light(), returns the current light level (number of turns of light the party has left). TP* 8.4 void set_up_lights() - Has the game refresh the lighting of a dungeon. 8.5 void put_party_outdoors(short what_section_x,short what_section_y,short loc_in_sector_x, short loc_in_sector_y) - Puts the party outdoors. It can only be used in a town script. Grouping Calls 9.1 short group_member(short which_group,short which_member) - Returns the creature number that is in the which_member slot of which_group. So if which_member was 1 and which_group was 2, the call would return the first creature in group 2. Basic Script and IO Calls 10.1 short request_target(short is_forced,short causes_hostility) - Returns the number of a visible creature of the player's choice (like targeting a spell or a wand). If is_forced is 1, then the party must make a choice if there are any creatures in sight. Otherwise, they are allowed to cancel out of it. If a choice is not made for either reason, returns -1. If causes_hostility is 1, then the player will warned about targeting friendly creatures, and if they do, the town becomes hostile. Otherwise, it's just fine to target friendly or hostile creatures. Cannot be used outdoors. 10.2 run_imported_state(file_name, state_number) run_imported_state_continue(file_name, state_number) - Runs state state_number out of file file_name. The former call ends the current call whereas the latter finishes the given call. See set_state() and set_state_continue. 10.3 short request_crime() - calls the special, center-screen dialog, and would return a 1 if the character goes through with the action. This would fix a problem described here . Terrain Checking and Modification TP* 11.1 short space_blocked(short loc x, short loc y) - Returns 1 if the space is blocked and 0 otherwise. This does check if the floor or terrain type is blocked (fl_blocked = 1 or te_full_move_block = 1), as well as if the floor was made blocked in the editor. Data storage and Manipulation (a new category) TP* 12.1 vector v1(n) - Placed in the variables section. Creates a vector array of size (1xn). 12.2 matrix m1(m,n) - Placed in the variables section. Creates a matrix array of size (mxn) to store data. If full matrices are too much, vectors would be fine. TP* 12.3 v1(i) - Returns the ith component of vector v1. 12.4 m1(i,j) - Returns the i,jth component of matrix m1. Location and Distance Calls 13.1 short check_path_between_locs(short loc_x1, short loc_y1, short loc_x2, short loc_y2) - Has the pathing engine calculate whether or not a character at location {loc_x1,loc_y1} could reach location {loc_x2,loc_y2}. Returns 1 if a path is found, 0 if there is definitely no path, -1 if there was no path found because the pathing engine stopped before exhausting all possible nodes. 14.1 short waypoint_x(short which_wayp) - Returns the x coordinate of waypoint which_wayp. 14.2 short waypoint_y(short which_wayp) - Returns the y coordinate of waypoint which_wayp. Improved Spellcasting Calls (related to Terrain Script and Creature Calls) 15.1 cr_spell_lib(file_name) import_spell_lib(file_name) - Placed either in scenario data script for the former and in the INIT_STATE of creature script for the latter. Gives a range or library of acceptable spells to be cast which is stored in a text file like a script. If call is not given, defaults to some default spell library. Use of this call in a creature script clears the current creature's spell library. 15.2 add_spell_to_lib(mage_or_priest, which_spell, spell_level, spell_frequency) - Adds spell (mage spell for mage_or_priest = 0, priest spell for mage_or_priest = 1) which_spell at spell level spell_level to the library text file. Monster casts the spell seldomly for spell_frequency = 0, uncommonly for spell_frequency = 1, and commomly otherwise. Additional Non-Call Requests 16.1 The ability to customize outdoor wall sheets- type, height, etc (everything that one can do with town wall sheets). 16.2 Joined NPCs to use creature scripts. Right now they appear to follow a completely default AI. 16.3 Custom scenario icons. 16.4 Variables to STAY after reloading. Right now reloading in the outdoors (among other things) appears to screw them up. We'd also like fixes to the bugs described here , as well as the others that have been sent in already.

Um, why the hell do you need spell libraries? You can do this already with change_spell_level, as you pointed out. I've been maintaining the organized list here . Since it's so long at this point, we probably ought to prioritize and pick out the best ones once we're done brainstorming. That could very well be another thread.

In the Trilogy, I pretty much never used these spells, although they are indispensable in Blades. I think I had a Dervish, a Wizard, and possibly a Gazer or Mung Demon at some point or another. I never found them to be worthwhile to Simulacrum back up, though; on the rare occasions when I felt the need to summon something, I could always use Arcane Summon instead.

I strongly suggest you take a look at the pre-packaged scenarios. It's a good way to figure out how things are done.

From VoDT, t0Fort Talrus.txt, a snippet of code that allows the player to rest, comments added by me: Code: beginstate 11;reset_dialog();add_dialog_str(0,"This is your room, a haven thoughtfully provided by the commander of Fort Talrus. It's dusty, but reasonable.",0);add_dialog_str(1,"If you wish, you can take a quick rest before journeying onward.",0);add_dialog_choice(0,"Leave.");add_dialog_choice(1,"Rest for a few hours.");choice = run_dialog(1); // This is the line that most people miss// Note also that add_dialog_choice(1,"") corresponds to run_dialog being 2.if (choice == 2) { revive_party(); set_ticks_forward(100); }break;

Oh, I forgot about that part, the empty water flasks. Yeah, that sounds like it would work just fine. A tick is one step in town mode. I think it's a full turn in combat. One step in the outdoors is ten ticks, though. Everywhere but the outdoors, the START_STATE gets called once per tick, but outdoors, it only gets called once every ten ticks, which is the reason for the rather bizarre way of keeping track of time down at the bottom of that code.

It took some finding, but here it is. Shyguy, you're not the only one with misgivings. I think a good many of us have them, and in this old thread , we can see that Alcritas (among others) is one. I have mixed feelings, too. But eh. The question is, what would we want Spiderweb to do? My main issue is with the way they present their web site. At least they should have good links, if not good content.

Hey, look on the bright side! At least people can still get BSR's scenarios without trouble. Okay, ranting time. I think it has come time for Spiderweb to do what it should have done years ago, and that is declare BoE abandonware. They should admit that they don't have the first clue what's going on in the BoE universe, that their scenario tables are a joke, that their articles are hopelessly outdated, that Jeff Vogel has not answered users' questions in well over three years, and they utterly disregard about half the Blades-related e-mails that they get. I've told everyone by now that I got into BoE briefly three years ago and then quit, but I've never really explained why. I quit because I couldn't figure out how to interact with other BoE players. I couldn't find the community. I found the Lyceum only after making NK0P and after trying and failing to play a fair number of the scenarios on the Solid Adventures table (back when I trusted the SW tables, thinking that BSR must be one of the most prolific and talented designers). I didn't even look around the Lyceum, because I was just there to get beta testers so that I could get NK0P beta tested and forget about Blades, because by that point I figured that BoE was dead. SW's site is not just unhelpful: it is actively harmful. I played Erika's Legacy thinking that it was one of the classics. After all, it was one of the winners in the First Contest, and several of SW's articles mentioned it. It was rated pretty well on the SW tables, too. It seemed kind of stupid, and I got bored and never finished. I tried Doom Moon II and could make it NOWHERE, because I didn't have anyone whom I could ask for help. (BoE Scenario Help, anyone?) People say, "What if a new downloaded The Grinch, thought it was the best that the community had to offer because of its score, and decided not to stick with BoE because of the obviously pathetic ability of scenario designers if that was the best they could do?" People give this as a hypothetical example, but it's not hypothetical to me. That sort of thing is what I did, three years ago. Spiderweb's scenario tables are the first thing that a newbie finds, and they are the first thing that a newbie trusts. Their current state -- rating some scenarios far higher than they deserve, lacking comments to go with the ratings, not being updated really at all, and generally being terrible -- suggests to new BoE-ers that BoE is dead, especially now that BoA is out. BoE is not dead, and it never will be: Alcritas's scenarios, Stareye's scenarios, and all the other great scenarios that will NEVER be ported to BoA will keep BoE alive for as long as there are computers that will run it, not to mention the continued support at the Lyceum for any form of Blades, either of Exile or Avernum. BUT THERE'S NO WAY TO KNOW THAT IN SPIDERWEB'S SITE! I think that Spiderweb should take down its misleading parts of its web site. I think that SW's BoE section should basically consist of links to more current sites. There should be a link to the Lyceum IN BIG EMBLAZONED FIERY LETTERS, and a link to TMU's links list, and a link to the BoE Web Ring, and maybe even a link to the Designer's Forum in the section on Articles and Examples. I even sent in an article to them, hoping it would get posted on that page. (It was in response to The Perils of 250. Nothing special. Common knowledge by the time, but I didn't know it.) When I got no response -- not even an e-mail back saying, "We don't do this anymore" -- I was pretty well convinced that BoE was dead. Spiderweb needs to drop the pretense and stop driving away new players. Update the links. Tell the truth about Spiderweb updates, and hasten to add that other pages update considerably more frequently, and that BoE players congregate over at the Lyceum's boards. They could even keep selling it, if they wanted. They just need to tell players up front that they have to count on the community that has built up elsewhere, not on the company that sells the product. Eh, ranting mode off. I don't know if I even agree with myself, here, but I think these points are worth thinking over, anyway. I'm sure I'm not saying anything terribly new, but I am saying it at a different point in time than it has been said before, and context may make a difference.

256, Keep. I just include the quotes in my character count. Although, come to think of it, I try to stay away from the exact limit altogether and avoid anything over 250 or so. I use the default font, whatever that is. Eh, Courier New, apparently.

Wow. I just started using it, and it looks really impressive. I was thinking about mentioning the total lack of a separate compiler outside the BoA app itself and how useful such a thing would be, and BAM, here it is. Nice job, Khoth! It has some small issues. It gives double errors, sometimes. For instance, these two lines: Code: while ((j <= 84) && (i == 0)) {if char_ok(j) It complained that they were both wrong, even though the second one is the only one with an error. It does this from time to time. When a semicolon is missing, it consistently gives the next line, not line it's missing from. I don't know if this was intentional. It also doesn't seem to recognize the special SANCTIFICATION_STATE in terrain scripts.

Oh yeah, that's the other thing I like about BBEdit Lite in place of TextEdit: BBEdit Lite does word counts of selections, so I can quickly check whether my strings are more than 256 characters. As I tend to be rather long-winded, this is VERY useful.

Using other people's code is perfectly fine (and in fact preferred, wherever possible), as long as you give credit to the original authors. In a similar fashion, I "borrow" graphics incessantly, and the readme for my scenario will have a long chunk crediting each artist who created the graphics I'm using. Here's the newest version. This seems to work, as far as I can tell. I think I'll post it in the Codex, too. Code: // Dehydration v1.2// dehydration.txt// Original version by Dahak.// Revised thoroughly by Kelandon (tomwatts@berkeley.edu).//// This general script checks if the party has a special item, water, and does// increasing amounts of damage to the party if they don't have it. This// simulates thirst, as in a desert.//// This script should probably go in the scenario script and be run in the// START_STATE, as depicted below.//// This script uses three SDFs. The default SDFs to use are (250,0), (250,1),// and (250,2). If you want to use others, replace the values in the variables// section. Several other values are editable, too.variables;// How many turns since the party last had water.short last_drank;// ALL OF THE FOLLOWING VARIABLES CAN BE EDITED TO SUIT WHATEVER YOUR SCENARIO'S// SPECIFIC NEEDS ARE. CHANGE THEIR VALUES TO WHATEVER YOU LIKE.// Change the following variable to whatever special item the water is.short water = 0;// Change the following variables to the coordinates of the SDFs keeping track// of the time between water checks. This works by using the SDFs as a two-digit// base-256 number. That is, the first SDF set to 5 and the second set to 2// means that 2 * 256 + 5 (equalling 517) turns have passed since the last water// check.short sdf_x = 250;short sdf_y1 = 0;short sdf_y2 = 1;// Change the following variables to the coordinates of the SDF keeping track// of how many consecutive times the party has failed a water check.short thirst_sdf_x = 0;short thirst_sdf_y = 2;// Change the following variable if you want the party to dehydrate slower or// faster. This is the number of turns between each water check. NOTE: This can// reasonably go up as high as sixty-five thousand. Any more than that, and you// will need to add more SDFs to keep track of the ticks in between water// checks.short dehyd_speed = 500; // Change the following variable if you want the party to die of dehydration// slower or faster. This times dehyd_speed equals the number of turns without// water after which the party will automatically die.short dead_of_thirst = 8;beginstate START_STATE;// Figure out how many turns it has been since the party drank water and save// that in last_drank.last_drank = (get_flag(sdf_x,sdf_y2) * 256) + get_flag(sdf_x,sdf_y1);// Check if enough time has passed since the last water check. If so, proceed.if (last_drank >= dehyd_speed) { // If the party has water, drink it. if(has_special_item(water)) { print_str("You drink some water."); change_spec_item(water,-1); // Reset all flags and counters. set_flag(thirst_sdf_x,thirst_sdf_y,0); set_flag(sdf_x,sdf_y2,0); set_flag(sdf_x,sdf_y1,0); } // If the party doesn't have water, do other things. else { // Damage them based on how long they've been thirsty (recorded in the // variable thirst_turns). inc_flag(thirst_sdf_x,thirst_sdf_y,1); damage_char(1000,(10 * get_flag(thirst_sdf_x,thirst_sdf_y)) + get_ran(1,0,9),4); print_str ("You're thirsty!"); // Reset flags. set_flag(sdf_x,sdf_y2,0); set_flag(sdf_x,sdf_y1,0); // Warn them if they're dying. if (get_flag(thirst_sdf_x,thirst_sdf_y) == dead_of_thirst - 1) print_str_color("YOU ARE NEAR DEATH. YOU NEED WATER.",1); // If they are too thirsty, kill them. if (get_flag(thirst_sdf_x,thirst_sdf_y) == dead_of_thirst) { message_dialog("You die of thirst!",""); kill_char(1000,2,0); } } } // Increment the SDFs keeping track of time. This works differently outdoors // because although ten ticks pass for every step, the START_STATE is only // called once per step. if (get_flag(sdf_x,sdf_y1) < 255 - (9 * is_outdoor())) inc_flag(sdf_x,sdf_y1,1 + (9 * is_outdoor())); else { inc_flag(sdf_x,sdf_y2,1); set_flag(sdf_x,sdf_y1,0); } break;

Quote: Originally written by Dahak: I believe that variables are wiped when the game is reloaded outdoors, or scripts are reloaded. Have you actually tested that? I've heard rumors both ways, but to the best of my knowledge, variables stay, even after the game is reloaded. EDIT: Because I was curious, I just went and tested this code out. The new version works like a charm, except that Dahak is right: when the party reloads in the outdoors, something about the variables goes haywire, and the script fails. SDFs are necessary in this case. I guess I'll go re-write the script with that in mind.

Here we go. Streamlined code, written in Lyceum format. Code: // DAMMIT, THIS DOESN'T WORK. DON'T USE THIS SCRIPT. SEE BELOW.//// Dehydration v1.1.1// dehydration.txt// Originally written by Dahak.// Revised thoroughly by Kelandon (tomwatts@berkeley.edu).//// This general script checks if the party has a special item, water, and does// increasing amounts of damage to the party if they don't have it. This// simulates thirst, as in a desert.//// This script should probably go in the scenario script and be run in the// START_STATE, as depicted below.//variables; short last_drank = 0;short thirst_turns = 0;// Change the following variable to whatever special item the water is.short water = 0;// Change the following variable if you want the party to dehydrate slower or// faster. This is the number of turns between each water check.short dehyd_speed = 500; // Change the following variable if you want the party to die of dehydration// slower or faster. This times dehyd_speed equals the number of turns without// water after which the party will automatically die.short dead_of_thirst = 8;beginstate START_STATE;// Check if enough time has passed since the last water check. If so, proceed.if (tick_difference(last_drank,get_current_tick()) >= dehyd_speed) { // Set this turn to have been the last water check. last_drank = get_current_tick(); // If the party has water, drink it. if(has_special_item(water)) { print_str("You drink some water."); change_spec_item(water,-1); thirst_turns = 0; } // If the party doesn't have water, do other things. else { // Damage them based on how long they've been thirsty (recorded in the // variable thirst_turns). thirst_turns = thirst_turns + 1; damage_char(1000,(10 * thirst_turns) + get_ran(1,0,9),4); print_str ("You're thirsty!"); // Warn them if they're dying. if (thirst_turns == dead_of_thirst - 1) print_str_color("YOU ARE NEAR DEATH. YOU NEED WATER.",1); // If they are too thirsty, kill them. if (thirst_turns == dead_of_thirst) { message_dialog("You die of thirst!",""); kill_char(1000,2,0); } } } break;

For anyone who's curious... TEH MEGASITE BEGINS!!!!!111 TEH MEGASITE WEAKENS!!!!!!1111 TEH MEGASITE DIES TEH DEATH!!!!111

Use block_entry(1) to prevent that. EDIT: I should probably give more detail than that. Stick block_entry(1) into the beginning (or end or middle -- it doesn't really matter) of your cut scene and the part won't step on the space that they were originally stepping into. TM did this in Emerald Mountain.

With regard to the both of you, Drakey and Djur, I said that you joined sometime before 2001, which I'm pretty sure is accurate, not around the same time as each other in 2001, which is not. Come to think of it, Drakey, I don't know when you joined the community, because you've always been really vague about it. My impression was that it was more recently than '97 and significantly earlier than '01, but I've just been guessing. EDIT: And I know you've been playing the games since '94, but that's not the same. I've been playing the games since '99, but I didn't join the community until '04.