-
These are things I feel could be done in the short term to add some spiffy abilities to scripts.
[list]
[*][b]BREAK[i] #[/i][/b]
Returns a non-negative value from a script execution. Negative numbers will be reserved for ERRORS that can be detected and checked. The [b]default[/b] return value if omitted, or no break statement is encountered, is [b]1[/b].
Pseudocode:
[area=script_execute][i]The function used to execute a SINGLE script.[/i]
int lastreturn=[b]1[/b]; // Checked by [b]if return[/b]
int script_execute([i]...parameters...[/i])
{
lastreturn=[b]1[/b]; // Reset in every script
...
if(command_is_break) return (!isnegative(argument)?atoi(argument):[b]1[/b]);
...
if(command_is_call) lastreturn = script_execute([i]new_script[/i]);
...
return [b]1[/b]; // Default return value
}[/area]
[area=execute_trigger_list][i]The function used to iterate through an entity's trigger list.[/i]
int execute_trigger_list([i]...parameters...[/i])
{
[i]Default value for returning for doing any list, meaning nothing supposedly executed.[/i]
int ret=,newret;
...
trigger_search_loop
[border]if(trigger_matched) {
newret = script_execute([i]trigger_script[/i]);
if((newret < 0 and (ret >= 0 or newret > ret)) or (newret > 0 and !ret)) ret = newret;
}[/border]
...
return ret;
}[/area]
Note: I have it here that the more negative an error, the less severe it is.
[area=do_trigger][i]The function used to iterate through all entities in the location that can match the trigger, such as an EXIT or GREET.[/i]
int do_trigger([i]...parameters...[/i])
{
[i]Default value for returning for doing any list, meaning nothing supposedly executed.[/i]
int ret=,newret;
...
entity_search_loop
[border]if(entity_can_do_triggers and entity_has_triggers) {
newret = execute_trigger_list([i]entity[/i]);
if((newret < 0 and (ret >= 0 or newret > ret)) or (newret > 0 and !ret)) ret = newret;
}[/border]
...
return ret;
}[/area]
Note: This function is much like the [i]execute_trigger_list[/i] in how it handles the return code.
The overall jist of this is that for a break 0 to get back to the originating
[hr][*][b]HALT[/b]
Set up a global flag that is reset to FALSE everytime a trigger list is looked at, and used to exit out of the entire function should the flag be set TRUE.
The reason for this? Simple: If a script does something that could cause problems with subsequent scripts, it could do the HALT command to tell the loops to stop searching/executing and to exit out.
[hr][*][b]NOT ifcheck[/b] or [b]!ifcheck[/b]
Simple negation of the ifcheck.
[area=Example]if carries $n 12345
and not wears $n 12345
say Please wear that!
endif
[hr]
if carries $n 12345
and !wears $n 12345 [i](Same as above, only showing other form)[/i]
say Please wear that!
endif[/area]
[hr][*][b]STATE[/b]
What is state? A state is nothing more than an indicator telling an entity what mode it is in so it can make decisions based upon what happens around it. Sound confusing? It's not really complicated. State for Sentience would simply be a number. This value is assignable, so you get to decide what numbers mean what. You would then use an ifcheck (oddly enough, the state ifcheck!) to determine if the entity is in the proper state. At load, the state would be 0 (have to start somewhere).
[area=Two ways you can set state][list=1]
[*][i]state <number>[/i] - assign a specific state.[*][i]state <min> <max>[/i] - pick a random state within the range (inclusive).
[/area]
[/list]
-
I'd like to be able to expand some of our variables, and have actual math expressions that make use of them. This is either out of Nib's BAL or inspired by it.
The following would be for turning in diamonds in the newbie area. In this example, there is a give script for the various gems. Token 3500 would track that, and value 3, specifically, would be for tracking diamons. When you wanted your reward, you would say 'redeem gems' which would fire this script.
The script would check for the player having token 3500, and if so, if value 3 of token 3500 was greater than 0\. If so, it would do some math, multiplying value 3 of the token by 1000, and awarding the total in experience to the player. It would then set value 3 to 0.
````
if hastoken $n 3500
and tokenvalue $n 3500 3 > 0
mob awardxp $n $[$[tokenvalue $n 3500 3] * 1000]
token adjust $n 3500 3 = 0
else
mob echoat $n {DYou haven't turned any diamonds in yet.{X
endif
````
This script would fire if the player said something like 'gem count' It checks each value, and returns the count of each gem in an echo (or tells the player that none of each type have been turned in). If the player has at least one unredeemed gem, it also displays a total count of gems, by adding values 0 - 3 together, and printing the total in an echo to the player.
````
if tokenvalue $n 3500 0 > 1
mob echoat $n {DYou can redeem $[tokenvalue $n 3500 0] rubies.{X
else
mob echoat $n {DYou haven't turned in any rubies.{X
endif
if tokenvalue $n 3500 1 > 1
mob echoat $n {DYou can redeem $[tokenvalue $n 3500 1] sapphires.{X
else
mob echoat $n {DYou haven't turned in any sapphires.{X
endif
if tokenvalue $n 3500 2 > 1
mob echoat $n {DYou can redeem $[tokenvalue $n 3500 2] opals.{X
else
mob echoat $n {DYou haven't turned in any opals.{X
endif
if tokenvalue $n 3500 3 > 1
mob echoat $n {DYou can redeem $[tokenvalue $n 3500 3] diamonds.{X
else
mob echoat $n {DYou haven't turned in any diamonds.{X
endif
if tokenvalue $n 3500 0 > 1
or tokenvalue $n 3500 1 > 1
or tokenvalue $n 3500 2 > 1
or tokenvalue $n 3500 3 > 1
mob echoat $n {DYou have a total of $[$[tokenvalue $n 3500 0] + $[tokenvalue $n 3500 1] + $[tokenvalue $n 3500 2] + $[tokenvalue $n 3500 3]] gems available for redemption.{X
endif
````
This can ideally be used for any checkable value, tokens are simply the big thing lately and it made sense to use them for the example.
