What has become clear in the Iron Ass OXP thread, and here, is that there are several limitations in the current implementation of BCC. It's all very well for the author to generate JS code in abundance, but it's not necessarily everyone's cup of tea. The complexities in the current methods create a huge barrier to entry.
Also, there are limits based on the assumptions I made when developing the tool. I wanted it to be a general purpose tool, but I've ended up locking in the general purpose to the point where it's quite hard to override with custom responses and settings.
In it's current state, BCC is "okay" for a single transmission and single response. That is, you send a message to a ship, and you get a response from that ship. But, coding up a full conversation tree is a daunting prospect with the current toolset.
So, here's what I'm planning.
1. No change to the existing interfaces. We don't want to break anything already in play.
2. Start using "script_info" in the shipdata.plist entry for a ship, to allow at least these things to be overridden:
(a) Disabling of default messages
(b) Simple customisation of default messages.
Thinking on the fly, here's what I imaging it would look like:
Code: Select all
{
"myship" = {
...
... various shipdata entries
...
script_info = {
"bcc_disable_defaults = (2,3,4); // this will disable message types 2, 3 and 4 for this ship type.
"bcc_custom_defaults = {
"1" = "[my_custom_greeting]"; // instead of using the default greeting descriptions.plist lookup, use "[my_custom_greeting]"
};
};
};
}
That should make it easier to override the current messages with your own responses, and disable existing ones that don't make sense for your ship.
There are still limitations here: if your ship can be spawned in multiple different roles (eg if "roles" has multiple roles defined like "trader(0.5) pirate(0.2)") it might result in some confusing scenarios. However, those limits could be worked around by separating the shipdata entries in those scenarios.
The next thing I'd like to address is how to better implement conversation trees, with as little JS as possible. Here's my first pass at this:
Code: Select all
script_info = {
"bcc_custom_messages = {
"seek_advice" = {
initial_state = "visible"; // whether the player will be offered this option immediately;
display = "Seek advice"; // what to display in the MFD
delete_on_transmit = yes; // indicates whether message option should be removed from MFD after use
transmit = "Do you know where there are good prices available?"; // what to transmit when the option is activated
post_transmit_function = "worldScripts.MyWorldScriptName.$transmit"; // function to call after transmitting the message (optional)
delay = 2; // how long to delay after transmission
reply = "Anywhere."; // the message that will be sent back to the player.
post_reply_function = "worldScripts.MyWorldScriptName.$reply" // function to call after sending the reply (optional)
post_reply_show_messages = ("complain", "thanks"); // messages to make visible after the reply is received
};
"complain" = {
initial_state = "hidden";
... message specs similar to "seek_advice"
};
"thanks" = {
initial_state = "hidden";
... message specs similar to "seek_advice"
};
};
};
"seek_advice", "complain" and "thanks" would act as identifiers. Initially, the "seek_advice" message would be the only one available. After it's transmitted, and the reply is received, the "complain" and "thanks" messages would become available. They could have additional messages to display, allowing for deep conversations to be built. They could even be made circular, if a message chose to re-display a previous message. The messages could also in the form of "[my_transmit_message]", that would be a lookup in descriptions.plist, and so allow for a number of variations with one entry.
There are also hooks in place, with the "post_transmit_function" and "post_reply_function" properties, that allow for JS functions to be called, which could be useful for tracking state. The ship object would be passed to these functions as a property, along with the ID of the message (ie "seek_advice"), so the function could know where in the tree the player is up to.
I think that covers the basics, of providing a non-JS method of controlling message trees, while still allowing for some deep and complex scenarios. And the benefit of using shipdata.plist is that some ship types can be updated with a secondary OXP that adds these things to it, without needing to change the original OXP, using "shipdata-overrides.plist".
Let me know what you think.