Thanks, Ahruman, for this thread, and for taking on the task of giving us new methods for scripting! Also thanks for the informations about [commander_shipname], [commander_rank] and [commander_legal_status]! Didn't know those before. And especially the last one comes in quite handy for Anarchies.oxp.
Occasionally in various threads I have already posted a couple of my wishes, just as they occured to me and I would have liked to script. I try to recall them all. So here comes an extended cargo bay full of requests (I apologize for the sheer amount, but I have had quite some wishes indeed):
1.
removeCargo: <amount> <Commodity name> as an inverse of awardCargo. If the amount of cargo becomes negative by this method it should be set to 0. That's the same method Arexack_Heretic already mentioned in his post above, but I suggest the syntax with the capital C instead of the underscore, because of the similarity to other methods of this kind (like awardCargo).
2. I am in total agreement to A_H's request for a method of querying the cargo in hold.
cargoInHold: with all the possible return-values would be cool.
3. If that shouldn't be possible I at least would like to have three querying states:
cargo_number as the amount of cargo currently carried by the player ship,
cargoFreespace_number as the amount of cargospace not yet filled and
cargoCapacity_number as the total amount of cargo that can be carried by the player ship in its current configuration. Even two of these would be sufficient, because
cargo_number +
cargoFreespace_number =
cargoCapacity_number, but to have all three would be more comfortable. With these methods it would be possible to script a bulk-transport.oxp: if cargoCapacity_number < 100 then missionscreen: "Sorry, Commander. If you want to get this mission you first have to get yourself a bigger ship."
4. A method for in- and decrementing the ship's clock. Like
adjustClock: <amount> <interval>. <amount> would be an integer, positive for moving the clock forward, negative for moving it backward, <interval> is one of the following: "seconds", "minutes", "hours" or "days". Example:
adjustClock: 20 minutes would do the same that is happening every time you are docking by hitting shift-D, and it could create the illusion that something you did according to a mission screen actually took some time.
adjustClock: -4 hours could reverse the effect that installing any piece of equipment makes the clock advance (the installation of a Q-mine takes quite some time!). For scripted equipments this period can not yet be adjusted in the script (at least I wouldn't know how), so it can very likely be much too long.
5. More mathematical operators, namely for multiplication and division.
multiply: <mission_variable> <value> would set mission_variable to mission_variable * value.
divide: <mission_variable> <value> would do the opposite. Example:
divide: mission_legal_status 2 would divide mission_legal_status by 2. The results could be rounded to an integer (like Oolite does to determine the number of energy bars from a ship's max_energy, through a division by 64 and killing everything after the point). If it's not rounded automatically, then also add
round: <mission_variable>.
6. A method to determine where the player is witchspacing to,
before he has arrived there, so that scripted changes can be made to the target system on STATUS_ENTERING_WITCHSPACE already. This is the only way to replace the main station and perhaps to change some other values as well in the system the player is jumping to.
selectedPlanet_number could return the number of the planet currently selected on the galaxy chart and would do the trick.
7. Another new status_string:
STATUS_IN_HYPERSPEED instead of STATUS_IN_FLIGHT as long as "J"-speed is activated. The engine must already be able to determine that, but we can't query it.
8. Another new method of creating ships relative to the calling entity:
spawnWithinRadius: <role> <number> <radius in metres> should be available as AI-method and as a scripted action (like setup_actions or death_actions) in shipdata. So a station with
spawnWithinRadius: asteroid 25 10000 in its setup_actions would sit in a small asteroid field, regardless where it would be spawned itself.
9. And another method for shipdata.plist:
scavenger_role would work like defense_ship_role. And why not
miner_role as well? These are the basic ship types that can be launched by a station's AI. We can control which ships are used as its defense. Why not the others as well?
After this wishlist of methods I would like to add the request for a new way of handling methods in a script and a new class of variables:
10. A loop structure. I don't know if that is possible, but sometimes I would have found it very useful. I can imagine a "while"-syntax:
Code: Select all
{
while = (
"mission_legal_status greaterthan 0"
);
do = (
"awardCredits: -10",
"decrement: mission_legal_status"
);
},
The catch is that the loop would have to halt the script. It would be of no use if the engine would run the loop only once every ten seconds, like the rest of the script. So the loop would have to be completed before the next condition is checked.
11. Together with a loop it would be very nice to have arrays as a new kind of variables. Example: A_H proposed a complete redo of the in-game legal system in the course of the Anarchies.oxp-thread (see especially
this post). He wanted to implement a local legal rating in each planet of the galaxy the player is currently in. For that he needed 256 different variables of the type: mission_variable_localrep_
n, where
n is a number from 0..255. Obviously an array would be the elegant solution to the problem of having to deal with 256 variables all the time. So my request is for
<mission_variable> (<index>) as a new type of variable. <index> could be a value, another mission_variable or a querying state like planet_number.
The array-variable and the loop together would form a powerful team.
And I have got a last request in this round, which is not for a new method, but for correcting what I see as a bug in the engine:
12. Allow escorts to have custom AIs. As for now every entity that is called as an escort--be it by the engine itself or be it by assigning a shiptype or a specific ship to another entity as an escort in shipdata and setting it up in the caller's AI--will have escortAI and only escortAI, regardless of the ai_type method in its shipdata-entry. That shouldn't be so. The engine should prefer the AI specified in shipdata, and only resort to escortAI as a default if no other AI is specified in shipdata.