BoA Editor Suggestions

[*i]

Okay, BoA is out and we are still in a phase where we can have updates. We should talk about things we want to be incorporated. So, reply with any suggestions you may have.

 

A few notes:

 

1) Any suggestions should not modify the engine, i.e. no custom races, spells, etc.

 

2) Calls can only be added and not modified.

 

3) Keep suggestions practical. Consider any changes that would have to be made to the call list.

 

List of Suggestions:

 

* add_dialog_pic(which_pic), makes a call that puts a dialog picture in the upper-left corner of the dialog.

 

* change_lighting(which_type), allows us to make the dungeon totally dark, fully lit, etc.

 

* add_light(what_amount), gives ability to change the light level. Can be negative.

 

* set_day(which_day), changes the day to which_day.

 

* set_year(which_year), changes the year of the scenario to year which_year.

 

* put_missile_animation(short source_x,short source_y,short dest_x,short dest_y,short which_sfx), missile animations.

 

* 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.

 

* 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.

 

* add_item_to_shop() -- Allow negative values for modifying shops.

 

* short get_creature_memory_cell(short which_char,short which_cell) - Returns the value of memory cell which_cell of creature which_char.

 

* short get_terrain_memory_cell(short which_script,short which_cell) - Returns the value of memory cell which_cell of terrain script which_script.

 

* void change_shop_money(short which_shop,short how_much) - Changes (as in increment and decrement) the amount of money a shop can have for buying the players items. Similar to Geneforge. I'm not exactly sure how the 'unlimited money' switch should work, so here is just a simple suggestion. If the shop ends up having equal to or greater than 30000, the shop has unlimited money, but it can only be given that much with this call. Shops default to having unlimited money.

 

* short shop_money(short which_shop) - Returns how much money which_shop has to buy the player's items. Returns 30000 if the shop has unlimited money.

 

* void shop_selling_options(short which_shop,short selective_sell_category,short cant_sell_this_category,short can_resell) A call to change 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.

 

* 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.

 

* 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.

 

* void calculate_ticks_forward(short num_ticks) - Makes the game calculate num_ticks forward, and of course will act upon these calculations.

 

* void set_char_presence_status(short which_char,short which_status) To serve as a way to set 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. One could do neat things with splitting up the party this way

 

* void set_up_lights(), Has the game refresh the lighting of a dungeon.

 

* identify_item(int item_type) - Identifies all items of item_type currently in the party's possession.

 

* identify_item_with_class(int item_special_class) - Identifies all items with item_special_class in the party's possession.

 

* 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.

 

* void put_party_outdoors(short what_section_x,short what_section_y,short loc_in_sector_x, short loc_in_sector_y)

It can only be used in a town script.

[Isaac]

void put_projectile(short source_x,short source_y,short dest_x,short dest_y,short which_sfx)

[Fort]

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.

[Groovejet]

short party_size() - Returns the number of characters in the party.

 

Also a leading_char would be good, but that can be implemented with script, I'm just lazy.

[*i]

Ummm...there already is a call party_size(). I should post my lead_char routine to the Codex.

[Kelandon]

I have some pretty thorough methods for checking party composition in the HLPM. Check them out if you're interested. The code is all commented, so it should be relatively easy to follow.

 

From my older versions of this topic, item descriptions. They would probably have to go in the custom objects script and look like:

 

it_description = "This is a flibbity-jibbity. It is much like a doohickey except that its thingamajig is connected to its whatsit rather than its whosit.";

 

Also, they might be able to go in the scenario script beside other initializing things, like quests.

[Fort]

The thing with the custom item descriptions is that strings take up so much more space than integer characteristics. The items also have to be able to be carried between scenarios.

 

It's just a save file size thing, I think. Definitely something I would like is a bunch of new calls for shops. Check the things in stock, prevent stores from reselling items, refresh inventories, selective buying (from the player), and gold amounts (like in Geneforge, but definitely optional).

 

Just off the top of my head...

 

shop_item_quantity(short which_shop,short which_item)

change_item_quantity_in_shop(short which_shop,short which_item,short amount_to_adjust)

shop_options(short which_shop,short resell,short gold_amount,short selective_buy_category,short selective_buy_category_status)

 

I may add descriptions later.

[void*_dup1]

Some things that i'd like to see changed:

 

1) NPCs initialize after towns. So NPCs can't use SDF values defined in town scripts in their own initialization.

 

2) There's no call to move NEAR a blocked spot (like approach_ter_script).

 

3) There is no way to send a message to a NPC before it is spawned (so the message can be used in the initialization of the NPC)

 

4) There is no way to access NPC cells from other scripts.

 

5) run_town_script apparently doesn't work before town initialization (so no workaround to #1)

 

6) There is no way to run a NPC state from other script.

 

Now, the solution to most of the above is messaging, except when you need to set up a lot of things in the one turn that the party enters a town.

 

7) A couple calls to manipulate the tick counter would be great too.

 

8) Having more than 8 waypoints per town would make them much more useful.

 

I noticed all of the above while experimenting with a NPC with a complex, 'realistic' daily routine. They are not important (I found the way to do what I wanted to) but force you to use awkward solutions to problems that would otherwise be simple

[*i]

Keep:

 

shop_item_quantity(short which_shop,short which_item)

 

The add_item_to_shop() call does this already.

 

change_item_quantity_in_shop(short which_shop,short which_item,short amount_to_adjust)

 

Sounds good, how about change_shop_quantity()?

 

shop_options(short which_shop,short resell,short gold_amount,short selective_buy_category,short selective_buy_category_status)

 

I think I get the general idea.

 

Void:

 

Most of your things change the engine. That is NOT going to happen. I understand Jeff is reluctant to put in new calls as it would require people to redownload the game, but perhaps we can reach a specific threshold on that. I doubt engine modifications will ever happen though.

[Kennedy]

What about a call to move or destroy boats and horses? Can the create_boat and the create_horse calls be used more then once on the same boat or horse? If not then some sort of move_boat and move_horse calls would be nice.

[Kelandon]

change_item_quantity_in_shop(short which_shop,short which_item,short amount_to_adjust)

 

This can already be done. The normal add_item_to_shop will do this. If you do...

 

Code:

add_item_to_shop(10,244,2); // Scroll - Bolt of Fireadd_item_to_shop(10,244,4); // Scroll - Bolt of Fire  

then shop 10 will have 6 of Scroll - Bolt of Fire in it: 2 from the first call, and 4 from the second. You can use these calls anywhere, even though the docs say to use them in the START_SCEN_STATE. (I use them in state 10 in the scenario script in the HLPM, because I'm using the state as a function, not as a One-Shot.)

 

If you want to reduce the number of an item, you can use add_item_to_shop also -- just reset the shop to zero using how_many as zero. Of course, you may have to keep track of how many items are in the store, but you can do this using SDFs.

 

The one downside to all of this is that the item will move to the top of the store's list, which is really annoying. Originally the shops in the HLPM incremented, rather than setting up each level specifically (ie going from level 20 to 25 I would add two more Iron Longswords or something like that), but the lists got too disorganized. But still, if you need to do this, it can be done.

 

EDIT: And the other one of Keep's suggestions sounds an awful lot like what's already done with begin_shop_mode. I don't quite get the difference.

 

And void*, if you don't like ugly workarounds, you shouldn't be programming for Blades. That's the nature of the game around here. If it's already possible, don't worry about how you're doing it, just do it.

 

I suppose item descriptions are probably not tremendously practical, come to think of it. Oh well. If we get the top five currently on Stareye's list right now, I'll be satisfied. I'd really like some sort of is_beam_on_space kind of call or some way to define other reactions to a reaction to a beam than just crumbling when hit by one -- for instance, sources turning off when they aren't being powered. However, I seriously doubt we'll get anything like this, so meh.

[Dahak]

I want a way to suppress the player from seeing the day count.

 

Something along the lines of set_day(day_number)

 

0 = No show

1+ = That day

[Kelandon]

If we got set_year, then we could shift over the effect of force_start_day(-1) to set_year(-1), and then force_start_day(-1) could take out dates altogether instead of just taking out the year.

 

Given that that no scenario would use force_start_day more than once, I don't think it would be that big of a deal even if it weren't backwards-compatible.

[Isaac]

Quote:

Originally written by Kelandon:
If you want to reduce the number of an item, you can use add_item_to_shop also -- just reset the shop to zero using how_many as zero. Of course, you may have to keep track of how many items are in the store, but you can do this using SDFs.

I didn't know you could do that! But you still can't check what the party's sold to the shop, unless you disable that entirely (in which case you still can't, but it won't confuse you).
EDIT: I tried that in my testing scenario and I couldn't get it to work!

[The Creator]

Stareye's pretty well covered everything I'd like added. Except maybe a call to force party members to equip items.

[Fort]

shop_item_quantity(short which_shop,short which_item) was supposed to be a function that returns the NUMBER of which_item in which_shop.

 

I'm aware that the add item to shop call exists, but it doesn't work relatively, and since there is no way to check the inventory, the only good way to increment or decrement shop items is to use a new call to specifically change them.

 

The way I would like shops to work is extrememly complicated, so I think it is best that those few calls are all that are necessary.

[Lilith]

I'm not sure exactly what you want to do with these features you're requesting, but if what you want is for a few specific items to be sold in limited quantities that are replenished at certain points throughout the scenario, the best way to do it might not be through a shop.

[*i]

Keep:

 

Post some discriptions and I'll add them to the list.

[Kelandon]

In reference to add_item_to_shop again, it appears that one feature is broken. From the docs:

 

"Note that, in all cases, you will want to put a number above 0 for how_many. If you don't, the item will disappear from the store."

 

I never tested this, but when Isaac said it didn't work, I did, and I second this: it doesn't work. This is a bug.

 

Quote:

Originally written by Keep:

I'm aware that the add item to shop call exists, but it doesn't work relatively, and since there is no way to check the inventory, the only good way to increment or decrement shop items is to use a new call to specifically change them.

I'm not quite sure what you're saying here. The call add_item_to_shop ONLY works relatively, which is to say that it increments rather than sets, to use SDF terminology.

 

As a correction to my post above: when you increment the amount of a particular item the shops sells, the item goes in the BOTTOM of the shop's inventory, not the top, I think. It still can mess up the shop's order, though.

[Fort]

OK, here are all of my current suggestions (with descriptions):

 

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.

 

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.

 

I KNOW that you said that we couldn't modify existing calls, but add_item_to_shop() doesn't accept negative values in the last parameter (how_much). Changing this would not interfere with the function of scripts already made, since this has no impact on positive values already there, and no one has used negative values yet because they don't work.

 

short get_creature_memory_cell(short which_char,short which_cell) - Returns the value of memory cell which_cell of creature which_char.

 

short get_terrain_memory_cell(short which_script,short which_cell) - Returns the value of memory cell which_cell of terrain script which_script.

 

void change_shop_money(short which_shop,short how_much) - Changes (as in increment and decrement) the amount of money a shop can have for buying the players items. Similar to Geneforge. I'm not exactly sure how the 'unlimited money' switch should work, so here is just a simple suggestion. If the shop ends up having equal to or greater than 30000, the shop has unlimited money, but it can only be given that much with this call. Shops default to having unlimited money.

 

short shop_money(short which_shop) - Returns how much money which_shop has to buy the player's items. Returns 30000 if the shop has unlimited money.

 

void shop_selling_options(short which_shop,short selective_sell_category,short cant_sell_this_category,short can_resell) A call to change 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.

 

Obviously, all this just ADDS to the shop system. Nothing pre-existing is changed, but I am kind of asking for all the shop features from all the other games.

 

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.

 

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.

 

void redo_lights() - Automatically recalculates the lighting in the level, especially useful graphically when regarding how much light is being given off by terrain because the lighting isn't refreshed even when you redraw the terrain and the light source is removed.

 

void calculate_ticks_forward(short num_ticks) - Makes the game calculate num_ticks forward, and of course will act upon these calculations.

 

To my understanding, set_ticks_forward() only makes the scenario time increase, but setting the ticks forward 20 times won't make the NPCs move 20 times, nor will it immediately trigger timed events. This would be very useful for opening and closing doors and such, because these actions do not currently take up ANY 'time'. You could open a door and see a bunch of monsters, then you could close it and they wouldn't have seen you.

 

EDIT: Sorry for not noticing those many nuances of the shopping calls. I always thought shops were somewhat impermeable. Also fixed tons of minor typos and terrible oversights in the suggestions.

 

Now, as I understand it, you all want force_start_day(-1) to completely remove dates (years, months, and calendar days), and set_year(-1) to remove years and months only.

[Kelandon]

Keep's suggestions, spelled out in this way, sound good to me. The call add_shop_mode has to be changed one way or another (because it has a bug right now anyway), so making it able to handle negative numbers and giving us a way of checking values seems better than just fixing the bug so that it works as described in the docs.

 

One more that I just remembered:

 

void set_char_presence_status(short which_char,short which_status) To serve as a way to set 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. One could do neat things with splitting up the party this way.

 

EDIT: Calculating ticks forward would be nice, but that's an engine change, and it seems unlikely.

 

What I meant with set_year and force_start_day is that force_start_day(-1) right now removes the months and years from the game, but the days still show up. If we got set_year, we could make set_year do what force_start_day(-1) does right now and make force_start_day(-1) take out displaying even the days themselves. That would be much more extreme, I imagine, because the player wouldn't know when special abilities regenerated, but the designer could figure something out, I'm sure.

 

Or we could not. It doesn't really matter that much. The set_year call would be cool, though.

[Isaac]

Quote:

Originally written by Kelandon:
In reference to add_item_to_shop again, it appears that one feature is broken. From the docs:

"Note that, in all cases, you will want to put a number above 0 for how_many. If you don't, the item will disappear from the store."

I never tested this, but when Isaac said it didn't work, I did, and I second this: it doesn't work. This is a bug.

I think that is a badly written part of the docs. What it means is, if a shop has 0 of an item, it doesn't have that item. (Although it would still be good if it did what you thought it did.)

Quote:

Originally written by Keep:


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.

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.

These would have possibly very strange effects. What happens when a player picks up the item? And if the player puts the item down again? Carries it out of town and back in, or into another town? And what if various calls are used on the item? Someone who was carrying it killed? I doubt the engine would be able to handle what you want it to here.

[Aran]

I don't know what the correct syntax for such a call would be, but couldn't there be one for recalculating the light radii in a town?

So when you delete a torch with a special, you can also make its light radius go away?

[Isaac]

Quote:

Originally written by Eferas Cirthain:
I don't know what the correct syntax for such a call would be, but couldn't there be one for recalculating the light radii in a town?
So when you delete a torch with a special, you can also make its light radius go away?

void set_up_lights()

(I actually copied that from the Blades of Avernum Editor source code)

[Kelandon]

For the item_loc_x and item_loc_y calls, I think the point is exactly what you're describing Isaac, that the item could move around. BoA would have to recognize two things: an item on the ground and an item being carried. If it's on the ground, it returns its coordinates. If it's being carried, it returns the coordinates of the character who's carrying it. If it's not in the town, it returns -1. I think this would be possible without changing the engine, although it would probably be difficult to program.

[Fort]

I just realized that the game returning the coordinates of a picked up item is probably impossible without an engine change, because they automatically lost their IDs when that occurs. And they are given new ones when they are dropped back on the ground.

 

Slightly tweaked variation to accommodate these issues:

 

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.

 

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.

 

I assume that items afffected by move_item_on_spot() will still retain their original IDs. To be truthful, the main reason for this call for me is to have certain creatures go hostile when they 'notice' that the items are no longer there or cannot be located.

 

Oh, and is just me, or is there NO call to check if an item of type x is on a certain spot? I see a call to check for an item of class x on spot, but no counterpart.

[Groovejet]

Also, is there a way to identify party items?

[Fort]

Not directly (of course skipping ID shops), no. There are many ugly workarounds, as you may imagine.

 

Perhaps

identify_item(int item_type) - Identifies all items of item_type currently in the party's possession.

 

identify_item_with_class(int item_special_class) - Identifies all items with item_special_class in the party's possession.

[Xeries]

Here's one:

recalculate_lighting();

[Groovejet]

Quote:

Originally written by Keep:
Not directly (of course skipping ID shops), no. There are many ugly workarounds, as you may imagine.

Perhaps
identify_item(int item_type) - Identifies all items of item_type currently in the party's possession.

identify_item_with_class(int item_special_class) - Identifies all items with item_special_class in the party's possession.

Maybe if we can identify the item that is in a slot?

Identify_item(short which_char,short which_slot) - Identifies the item on which_slot of which_char.

[Fort]

The slot thing doesn't seem to be too useful. I mean, Why? Because you force the player to equip a cursed sword and he won't be able to identify it until you make some weird encounter for it?

[Groovejet]

Maybe, but I would like a call that would allow me to emulate the identify spell of the Exile series.

[Isaac]

Quote:

Originally written by magoicochea:
Maybe, but I would like a call that would allow me to emulate the identify spell of the Exile series.

I also.

And,
void put_party_outdoors(short what_section_x,short what_section_y,short loc_in_sector_x, short loc_in_sector_y)
It can only be used in a town script.

[Kelandon]

Another thought: perhaps a call that would ask the player to target a creature in sight -- exactly like using a wand that requires a target, but without the wand. This would allow custom abilities to have targets, and it would also allow for cool RP actions like pointing ones finger at someone else. Something like...

 

short request_target() - returns the number of a visible creature of the player's choice. Cannot be used outdoors.

[Aran]

Quote:

Originally written by Isaac:

Quote:

Originally written by Eferas Cirthain:
I don't know what the correct syntax for such a call would be, but couldn't there be one for recalculating the light radii in a town?
So when you delete a torch with a special, you can also make its light radius go away?

void set_up_lights()

(I actually copied that from the Blades of Avernum Editor source code)

So what happens when you use it in a script? It isn't mentioned in the documentation, so does the scripting engine recognize it if you include that command in a town script?

[Lattan]

No, it doesn't. It's C code, not Avernumscript.

[Aran]

So how hard would it be for Jeff to include that call in Avernumscript as well? The game itself is based on C, isn't it?

[Fort]

I'm pretty sure that a large portion of the game was written in C.

[KernelKnowledge12]

Quote:

Originally written by Eferas Cirthain:
So how hard would it be for Jeff to include that call in Avernumscript as well?

the set_up_lights() function is used by the editor to put final touches on the current town's lighting array before saving. although its possible that this function also exists in Blades of Avernum, and that it could be linked to Avernum Script, i doubt it would have much use.

[Fort]

If what you say is true, Kernel, then the lighting points ARE NOT calculated when the town is entered like Jeff says in the manual, but rather in a matrix inside the town itself.

 

This doesn't bode well for the future of this call because then it would require an engine change. Personally, I don't understand how calculating which terrain spots give off light every time there is a force_instant_terrain_redraw() could be a performance problem.

[KernelKnowledge12]

the set_up_lights function itself is relatively short, and shouldn't be too hard to include into the engine (although it would be a performance dampener when called by Avernum Script). But it shouldn't be too hard to put in auxillary functions that recalculate lighting for certain terrain spots and maybe rectangles. This however could be too annoying for someone who would tends to use this function alot (whoever that may be), so Jeff would have to put in an auto check for it whenever the lighting array may have been comprimised by a terrain change or whatever. There can then be two more functions that enable and disable auto lighting, which again shouldn't be to0 hard.

[Fort]

I feel as if the best way to do it is to have the change terrain calls also do a quick check to see if they emit light. If they do, then the game will recalculate on next turn or when there is a terrain redraw.

[KernelKnowledge12]

My sentiments exactly.

[*i]

Bump.

 

Come on! I'm, sure we want other things. I give you guys one more week before closing this topic and sending it off.

[Dahak]

day_size(ticks_per_day)

[Kelandon]

*i, it might be helpful to group the requested new calls by category. I think the groups fall roughly along these lines:

 

Advanced Dialog Box Calls

 

* void add_dialog_pic(short which_pic) - Puts a dialog picture in the upper-left corner of the dialog.

 

Animation and SFX Functions

 

* void put_missile_animation(short source_x,short source_y,short dest_x,short dest_y,short which_sfx) - Missile animations.

 

Terrain Script and Creature Calls

 

* short get_creature_memory_cell(short which_char,short which_cell) - Returns the value of memory cell which_cell of creature which_char.

 

* short get_terrain_memory_cell(short which_script,short which_cell) - Returns the value of memory cell which_cell of terrain script which_script.

 

* 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.

 

Shop Calls (a new category)

 

* 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.

 

* void add_item_to_shop() - Allow negative values for modifying shops.

 

* void change_shop_money(short which_shop,short how_much) - Changes (as in increment and decrement) the amount of money a shop can have for buying the players items. Similar to Geneforge. I'm not exactly sure how the 'unlimited money' switch should work, so here is just a simple suggestion. If the shop ends up having equal to or greater than 30000, the shop has unlimited money, but it can only be given that much with this call. Shops default to having unlimited money.

 

* short shop_money(short which_shop) - Returns how much money which_shop has to buy the player's items. Returns 30000 if the shop has unlimited money.

 

* 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

 

* void calculate_ticks_forward(short num_ticks) - Makes the game calculate num_ticks forward, and of course will act upon these calculations.

 

* void set_day(which_day) - Changes the day to which_day.

 

* void set_year(which_year) - Changes the year of the scenario to year which_year.

 

* void set_day_size(ticks_per_day) - Changes the length of the day.

 

* 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.

 

* short get_daylight() - Returns the current level or amount of daylight.

 

* 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

 

* void identify_item(int item_type) - Identifies all items of item_type currently in the party's possession.

 

* void identify_item_with_class(int item_special_class) - Identifies all items with item_special_class in the party's possession.

 

* 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.

 

* 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.

 

* 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.

 

Basic Character Calls

 

* 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.

 

* short char_weight(short which_char) - Returns the weight of the character which_char.

 

* get_immunity(short which_char, short immunity_type) - Returns a value from 0 to 100 depending on the assigned immunity value.

 

* set_immunity(short which_char, short immunity_type, value) - Sets a value from 0 to 100 to the immunity_type.

 

* void set_hp_regen(short which_char, short what_percentage) - Gets what percentage of which_char's maximum health is regained every tick.

 

* void set_hp_regen(short which_char_or_group, short what_percentage) - Sets what percentage of which_char_or_group's maximum health is regained every tick.

 

* short get_sp_regen(short which_char, short what_percentage) - Returns what percentage of which_char's maximum spell points are regained every tick.

 

* short get_sp_regen(short which_char_or_group, short what_percentage) - Returns what percentage of which_char_or_group's maximum spell points are regained every tick.

 

* 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

 

* void change_lighting(which_type) - Allows us to make the dungeon totally dark, fully lit, etc.

 

* void add_light(what_amount) - Gives ability to change the light level (as from torches or Light spells). Can be negative.

 

* short get_light(), returns the current light level (number of turns of light the party has left).

 

* void set_up_lights() - Has the game refresh the lighting of a dungeon.

 

* 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.

 

* void set_town_status(short which_town,short new_status) - This call does not appear to do anything in the current version of BoA.

 

* short town_status(short which_town) - Right now always returns 0, even if the town status is not 0. It should return 0, 1, 2, or 3.

 

Grouping Calls

 

* 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

 

* short request_target() - Returns the number of a visible creature of the player's choice (like targeting a spell or a wand). Cannot be used outdoors.

 

* 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.

 

Terrain Checking and Modification

 

* 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)

 

* vector v1(n) - Placed in the variables section. Creates a vector array of size (1xn).

 

* 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.

 

* v1(i) - Returns the ith component of vector v1.

 

* m1(i,j) - Returns the i,jth component of matrix m1.

 

Miscellaneous Special Calls

 

* 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.

 

Location and Distance Calls

 

* short waypoint_x(short which_wayp) - Returns the x coordinate of waypoint which_wayp.

 

* short waypoint_y(short which_wayp) - Returns the y coordinate of waypoint which_wayp.

[Isaac]

Quote:

Originally written by Kelandon:
* add_light(what_amount), gives ability to change the light level. Can be negative.

I am a little confused by this wording, but I think it means how much light the party has, given by torches, etc? If so, we need:

* short get_light(), returns the current light level (number of turns of light the party has left).

It would also be useful to have a chart of what numbers of turns of light correspond to which light radii the party can have.

[*i]

Yes, very nice. Thank you, Kel. And yes, I do mean the lighting level that the party has produced. A get_light() command would be nice as well.

[Fort]

I'm not sure if this would be a *call*, but there should be a way to disable the 'Done' button that is at the bottom right corner of the dialogue screen when you are talking to creatures. That way you could force the player to go through the dialogue thread to the end.

 

And this (could be under time or lighting):

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.

 

short get_daylight() - Gets the current level or amount of daylight.

 

void stop_daylight_progress(short stop) - This call 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.

[Djur Revolutions]

How about getting rid of the 64000-line limit for scripts?