Requests for BoA Scenario Format 3

[Kelandon]

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.

[cfgauss]

Why does it have to be backwards compatable? Why not just have something you can add in the begining of the script like:

use_format_1;

use_format_2;

 

It seems like this might be a nice way to impliment commands that would otherwise break compatability.

[Kelandon]

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?

[Fort]

Might be out of place, but I feel as if it is necessary to voice out these problems since he will have to patch the game along with the new scenario format:

 

EDIT:

Spiderweb's mentality towards new formats has emphasis on backwards compatibility because otherwise every different version of the same call would have to be redefined in the compiler several times. Jeff also never meant the system to load different schemas, though it would certainly be nice. Rather than do it in a script, I think it would be best to add the format version in the .bas itself.

 

Or, we, the community, as a whole could devise a way to automate the necessary changes with every new format version.

 

I doubt the matrices will make it, but the vectors/arrays, maybe.

 

I think it would be easier for the shop things to just have Jeff implement whatever he did in Geneforge.

 

Shorten set_char_presence_status() to set_char_presence().

 

How exactly will the request_target() call work?

 

Allow a creature's target to be a friendly. Not quite sure how it will work, but it would be much better for scripted scenes or battles.

 

NPCs should be affected by terrain and floor effects.

 

I propose that the agreed upon rating for each suggestion be placed before the asterisk that already precedes each one. For example:

 

TP* suggestion

WBN* suggestion

NL* suggestion

 

The rating names are a little odd, but I don't really care.

 

Dialogue Scripts should use the variables of the containing town script.

 

Should variables be disallowed in the run_imported_script() calls? How will they be handled?

[Fort]

Don't post tl, dr.

[*i]

Kel -- Think you could give everything a numbering system? For instance 1.0, 1.1, etc. for the first category, 2.n for the second and so on down the list. It would make things easier to talk about and vote on.

 

Should variables be disallowed in the run_imported_script() calls? How will they be handled?

 

I've always assumed this would be like call_global_state().

[The Creator]

I obviously feel that the Dialog Box is by far the most important thing. Everything else is nice, but I could do without it. No Dialog Box option really diminishes my desire to design for BoA.

[Fort]

run_town_script() and run_scenario_script() work because the variables are guaranteed to be in memory, but what about the other ones? How could script 1 call script 2 state 4 and expect the variables that are tied to script 2 to work?

[Kelandon]

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.

[*i]

Matrices and vectors allow you to create a temporary, variable, and convenient ordered data structure. The problem I am having is that I want to store a variable number of components in creature scripts. Regular variables will not work unless I define a lot of them to ensure I don't run out under any situation. Here are some advantages:

 

* Of an arbitrary size (only 30 for SDFs) assuming Jeff doesn't program stupidly.

* Are created as a temporary file specific to a script and does not require reserving large numbers of flags.

* When you have them in different, it would be hard to keep track using flags and you need to be careful not to overwrite and spill over.

* Vectors and matrices should be able to store integers instead of just values 0 to 255.

 

Okay, I admit there are ways to do this with flags, but I'm having a hard time trying to organize it and I suspect other players will as well.

[Djur Revolutions]

* Of an arbitrary size (only 30 for SDFs) assuming Jeff doesn't program stupidly.

I'm skeptical, considering the arbitrary limit on string length. (If Jeff ever reads this: Was it that you only allocated a 256-byte buffer for each token? Thus 254 + 2 quotes = 256 bytes? If so, have you ever heard of malloc, realloc, and calloc?)

 

Vectors are a great idea, although matrixes are unnecessary with nested vectors/arrays.

 

a = [[1, 2], [3, 4], [5, 6]]

a[0][1] ---> 2

[Kelandon]

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.

[Fort]

Maybe a 'static' keyword preceding the variable declaration would make it be remembered like an SDF. I feel that memory cells should be remembered unconditionally. Example:

static short tick_counter;

 

Maybe if all the strings that can change sizes later could be appended onto the end of the memory stack so it has a lot of space to expand.

 

Given that the vectors and such are currently being suggested as a construct managed through calls, nested vectors would require a syntax change.

 

short array[10][2];

as opposed to the more javascriptish alternative.

 

But if it must be done through calls, it should be noted that you need to be able to accomplish 3 things: Declare and define the the vector in the variables section, get the value of an element, and set the value of an element.

 

Yet... Screw it for now, it is late and I should probably delve a little more into my little programming book before I say something stupid.

 

Oh yes, and am I right in assuming that request_target() would activate a targeting mode where the little letters appear above the correct monsters, and you get to choose a single target, the number of which is returned by the call?

[Donald Hebb]

Quote:

Originally written by Kelandon:
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.

How about no?
If you want a variable to remain permanent, use SDFs. You have, god, over one thousand of them.

For me, what I'd absolutely LOVE to see...

* Dialog boxes.
* Pathing.
* Getting/setting memory cells.
* Getting/setting time calls.
* Getting/setting daylight/nighttime calls.
* Getting/setting immunity calls. (Make the work easier for all of us- and hell, make Area-of-Effect spells possible with something resembling decent AI! Oh lord, have I got ideas for THIS...)
* Deducting AP, even though I'm not sure how this would work- would the character's turn thereafter somehow be compromised?
(Am I the only one who is seriously pissed that JV did flat-out nothing with his new day/night innovation for A3?)
* Vectors. Damn, it can't be THAT hard, can it?
* Is Space Blocked? calls would be lovely. But really, can't we split the floor+terrain and blocked to NPCs into separate calls?

Also, Kel, shame on you! Where are Stareye's spell libraries? I'd LOVE to have them. Put them up on the list, post-haste. A concrete, mid-combat way of changing strategies could make things incredibly interesting.

A few more ideas:

short is_valid_target(short from_who, short whom, short good_or_bad);
Where from_who is the person being compared to the target, whom is the target, and good_or_bad is the type of hypothetical ability being tossed about. This would only be of good use in creature scripts, but it still deserves mention.

Targetable items that call scripts- even scripts that help the creature- say if you want to anger the town or not by doing this. And then, even if you use a damaging item on the character, the character stays friendly to you. The latter can (obviously) be worked around, but the former is more difficult. Why not get rid of the default prompt as to whether the player wants to attack a friendly creature have this in its stead:

short request_crime();

It would call the special, center-screen dialog, and would return a 1 if the character goes through with the action. This also requires getting rid of the prompt on useable items, but still...

[Kelandon]

Request target would, yet again, work exactly like targeting a spell or wand, so yes.

 

Why would variables staying at the last value that you set them be bad? This seems strange to me. I just want reloading a game not to have any effect.

 

Also, SDFs are not a perfect substitute. Variables can go much higher and lower than SDFs. The range on variable values is vastly greater. One cannot keep track of time with a single SDF, which is annoying.

[Dahak]

Just a guess, but variables consume memory. The SDFs are limited to lower the memory requirements.

 

If the variables were to persist, then they would require larger (is there a limit to # of variables per script?) amounts of memory. If there was no limit, then you could reallllllllly big files, and a lot of RAM would be tied up.

[Donald Hebb]

You can replace any variable with 2 SDFs. To define the variable:

 

while(damage >= 255){

inc_flag(1,1,1);

damage = damage - 255;

}

set_flag(2,1,damage);

 

To re-use the variable:

 

damage = 0;

while(get_flag(1,1) >= 1){

inc_flag(1,1,-1);

damage = damage + 255;

}

damage = damage + get_flag(2,1);

 

Voila! Variables now become permanent at the cost of two SDFs. Three, I suppose, if you want to be able to keep track of negative values. (That is, set (3,1) to 1 if damage is negative, and multiply damage by -1 if 3,1 is 1.)

[Fort]

Yes, yes a matrix of base 256 numbers. But that isn't very easy. I can understand how increasing the SDFs from an unsigned byte to a signed short can increase the memory usage, but it is only 9000 bytes! Thats not even 10 Kb, and he could seriously use some compression on things like that.

 

There can only be 20 variables per script. Definitely would like that limit to be lifted, but I don't carry much weight in this argument.

 

I can't really reasonably suggest what the priorities, so I think I will make a list of likely ones.

 

Likely:

1.1

2.1

3.1

3.2

4.2

7.3

8.2

9.1

14.1

14.2

[Donald Hebb]

Personally, I'd like an unlimited *number* of variables.

 

Because as it's going, I'm going to flat-out run out of them for my Area of Effect custom AI script.

[Dahak]

Only 20! Gah. TM is right, you quickly run out. I had planned to create a squad script (I hadn't actually typed/tested it, only outlined) for a 5 man squad. It used a large number of variables... I guess I'll have to redesign.

[Isaac]

Quote:

Originally written by Kelandon:
Request target would, yet again, work exactly like targeting a spell or wand

So the player has the choice to press Escape and not choose a target? And it asks whether you want to make the town hostile if you target a friendly creature?

How about
short request_target(short is_forced,short causes_hostility)

If both of those were true, you might be forced to target a friendly creature and make the town hostile. Which could be part of an interesting plot... However there's also the possibility that there are no creatures in sight of the party.

Description: 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.

Note that even though it doesn't return whether the town became hostile, you can check its status before and after to figure that out.

[*i]

Here is my list:

 

1.1 - TP+ (if nothing else, this one)

2.1 - TP

3.1 - WBN

3.2 - WBN

3.3 - NL

4.1 - WBN

4.2 - TP

4.3 - NL

4.4 - NL

4.5 - WBN

5.1 - WBN

5.2 - WBN

5.3 - TP

5.4 - NL

5.5 - WBN

5.6 - WBN

5.7 - WBN

6.1 - WBN

6.2 - WBN

6.3 - WBN

6.4 - WBN

6.5 - WBN

7.1 - TP

7.2 - WBN

7.3 - TP

7.4 - TP

7.5 - NL

7.6 - NL

7.7 - NL

7.8 - NL

7.9 - WBN

8.1 - TP

8.2 - TP

8.3 - TP

8.4 - WBN

8.5 - WBN

9.1 - WBN

10.1 - NL

10.2 - TP

11.1 - TP

12.1 - TP

12.2 - WBN

12.3 - TP

12.4 - WBN

13.1 - NL

14.1 - WBN

14.2 - WBN

 

Also, having varibles preserved after reloading would be very, very nice and save a lot of trouble.

[Overwhelming]

What do you mean with "Dialog Box"? Doesn't BoA has a dialogue system?

[*i]

Okay, when you display a ood amount of text on the screen and are often offered choices, that is considered a dialogue box. Right now, it is impossible to put an image to go along with it.

 

Play the old Exile games and you should notice a picture of a Slime by the text or something. We're really asking for this nice feature back.

[Overwhelming]

You mean the NPC's portrait? That can be done in BoA.

[Lilith]

No, not an NPC portrait in talking dialogue, an arbitrary image to go with a message box. And not like in a splash screen, either -- instead of being big and central, it'd be small and up in one corner.

[Overwhelming]

You mean this ?

[Donald Hebb]

I still want this:

 

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 tried an erase_char(); call followed by a spawn_creature(); call in a creature's death state, but it resulted in a unary error. I want this so that creatures can be killed but still not-totally-die. (This would simulate Lifesaver amulets on monsters.)

 

I also think a DISPEL_BARRIER state in terrain scripts would kick ass. But that's just me.

[Fort]

Unary, as in one operand, as in negation and logical NOT. What the heck are you using as the parameter of spawn_creature to generate such an error?

 

By the way, I tested this out and it produces an unhandled exception, so there are definitely some problems with this usage of the call, though I have no idea what.

[Dahak]

This shouldn't be a major engine change, and would be backward compatible, but the town details menu has 2 unused fields. Could it be possible the convert one of those fields to load a custom town graphic background? (The picture behind the character in the inventory screen) It looks really odd to have a mountain in the background, but you're in the middle of the desert.

[Donald Hebb]

I used this:

 

not_used = spawn_creature(ME);

 

That was probably my error.

[Fort]

Ah, ME == -1. I have no clue why Jeff was so IDIOTIC as to not replace my_number() with ME() and kill the ME macro.

 

Anyways, Jeff coded spawn_creature() so that if the creature was still alive, nothing would happen and the call would return 0. But when erased with erase_char(), the creature is considered dead, so I guess the call doesn't know what to do if the creature is dead, but the monster's script and other variables are still in memory. That's what I think is going on.

 

Mind you that the game automatically quits because of application failure when you use spawn_creature(my_number()) in its DEAD_STATE after erasure. Revive_char would be a nice shortcut, though.

[Isaac]

Quote:

Originally written by Deacon:
I also think a DISPEL_BARRIER state in terrain scripts would kick ass. But that's just me.

There is such a thing. Check door.txt:

Code:

beginstate DISPEL_BARRIER_STATE;	if ((i_am_open == 0) && (i_am_locked)) {		print_str_color("Dispel Barrier: The spell fails to affect a locked door.",2);		}break;

[Fort]

I was thinking about this:

 

...and I was wondering how nice it would be to be able to have up to 1 dialog pic for each block of text. The call could be modified to:

 

void add_dialog_pic(short which_str, short which_sheet) - Makes the graphic which_sheet be displayed with the dialog. It will be placed to the left of the which_str block of text in the dialog, and the text will wrap around its edges.

 

To go along with the conventions of the add_char_dialogue_pic: Dialogue pictures are

placed in a sheet by themselves with no frame, and it is recommended that they are no larger

than 64 x 64. The number of the graphic resource is which_sheet.

[Donald Hebb]

Wow. I tried this:

 

my_x = my_loc_x();

my_y = my_loc_y();

erase_char(ME);

is_not_used = spawn_creature(my_number());

relocate_character(my_number(),my_x,my_y);

force_instant_terrain_redraw();

 

I crashed BoA is what I ended up doing. Yeah, respawning creatures upon death is an impossibility. I still want the revive(); call.

[*i]

DISPEL_BARRIER_STATE would be nice if it could be incorporated into creature scripts.

[Fort]

So you could have Walking Fire Barriers that breathe fire, which could be dispelled?

 

When do you think that this list will be sent to Jeff? What if he inadverdently makes SF3 without looking at these suggestion?

[Donald Hebb]

If he doesn't look at these suggestions, I will be extremely pissed.

 

I will also likely give up scenario design altogether.

[*i]

Anyway, people need to assign priorities or we'll just give him the list as is.

[Linthar]

I'm pretty sure that this doesn't exist, but if it does please tell me as it be very helpful.

 

I'd like a get_is_new_round() command.

 

It would be called in a creature or terrain script, and would return 1 if this was the first time it was called in the current round, and return 0 otherwise.

 

This would greatly help with making a custom creature script that did a special action once a round every round. I've been able to make crude workarounds but such a command would be very helpful.

 

Edit: Problem answered below. leaving this post otherwise unchanged in so those that have the same problem would have an easier time finding the answer

[Fort]

The script runs as long as the creature has AP, I think. Anyway, this call isn't particularly necessary because you can just use get_current_tick() to monitor when the creature used an ability.

[Donald Hebb]

There's a potential error with that- ticks wrap at 29999, so if a monster uses an ability on turn 29999, then they won't be able to use it again.

There are more useful calls, but that one has its uses.

[Fort]

Oy, that is why there is a tick_difference() call. It takes care of that.

[Linthar]

Thankyou, I knew I must have been missing something.

[Kelandon]

Okay, I just updated the list at the beginning of this thread. I labeled some things TP based on the four lists of priorities that people have already given (mine, *i's, Keep's sort of, and TM's from what I could figure out of it). If I'm still missing any calls or if you think some other calls might be more important, then post.

 

We have 15 TP's if we take ones that showed up on at least two lists, and 7 if we take ones that showed up on at least three. For comparison, we got four new miscellaneous calls and the five String Manipulation Calls for Scenario Format Version 2. It seems to me that 10-15 calls would be a good number to submit as our top priorities, because then Jeff can narrow it down to the number that he'll add, which, judging from last time, would probably be 5-10.

 

That is, of course, assuming that he does anything at all. But hey, we might as well be optimistic, right?

[The Creator]

That list looks pretty good to me. I'd probably add 8.4 as a priority as well, but otherwise, great.

[Kelandon]

Quote:

Originally written by The Creator:
I'd probably add 8.4 as a priority as well

I'll take that as a second vote for it (alongside mine) and upgrade it to TP.

[Donald Hebb]

My top priorities are:

1.1

2.1

3.1, 3.2, 3.4

4.2

5.3, 5.6

6.1, 6.4, 6.5

7.3, 7.4, 7.9

8.2, 8.3, 8.4

12.1, 12.3

 

I also REALLY think that the spell libraries are neat, but god knows it ain't happening.

[Fort]

If I am prodded enough, I can make a Javascript enhanced XTHML CSS page for creating spell libraries. No big problem.

 

Anyway, I slightly modified the list of things in my thread of bugs. * indicate bugs, + indicate suggestions.

 

I know there must be other bugs in a program as badly programmed as this one. Send 'em in!

[Fort]

This might be expecting too much out of Jeff, but he did say he vowed to give ongoing support for BoA. I think these calls would also be very useful:

 

TP 3.3

TP 13.1

TP 9.1

 

WBN 6.4, 6.5 (for documenting item locations)

WBN 14.1, 14.2 (Locs of waypoints)

 

NL 5.1

 

They are listed by:

1) From TP to NL.

2) My order of priority.

 

If 6.4 and 6.5 are implemented, this Would Be Nice:

short item_on_loc(short loc_x, short loc_y) - Returns the type of item found on {loc_x, loc_y}. Returns 0 (null / empty item) if nothing there.