Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
ryleyra

Registered:
Posts: 3,009
Reply with quote  #1 

Fish Evans' post on Mission Scripting Problems inspired me to move over here to the Mission Scripting forum for some more "wish fulfillment" ideas about additions to scripting. This isn't a thread for bugs like the inability to select Jump Drive in missions, or fundamental improvements to scripting, like being able to specify the player ship in a way other than by name. This is more long term, down the line, "gee whiz I'd like to see this" ideas.

If you want to post about the bigger issues, probably the original thread is the place. It is here: http://artemis.forumchitchat.com/post/rant-on-mission-scripting-problems-7356961

Anyway, to start with, I would like more ship properties than can be effected. Both to be read and to be set by a mission. Some examples:

- maxHoming, maxNuke, etc. That way if I want to reduce or increase the maximum torps I can, without having to check the count each time and reduce it if it goes over the max.
- sensorRange. See below. While sensor range is global at this time, I would like to be able to knock out sensors on an individual ship
- acceleration. Not top speed, the acceleration value added previously. I'd also like to see it in vesselData
- efficiency. While we're at it, why not? [smile]
- the ability to disable a specific weapon. Or, the ability to increase or decrease fire rate or damage on a per ship basis. (enemy or friendly) Also, see below.

Some global values that might be read or modifiable from within a script:

- sensorRange. At the very least, I would like to see what the sensor range is so I can advise the players that the mission is intended for a limited sensor range.
- difficulty settings. There are now factors like damage and shield strength that can be modified individually. And terrain features. These (and main difficulty) could be set as well as read.

Since communications between the players and a Game Master, or even each other, can be rather difficult, how about the ability to add Comms categories and options to the menu? For instance, the GM may add a "TSN Command" button to the Comms menu, which when pressed, calls up the options, "Yes, Admiral", "On our way", "Please clarify your orders", and "I'm kind of busy right now, Admiral". The same interface could also edit the default options for other players.

And how about this for an idea? Since keypresses are a problematic solution and can be hard for tablet users, how about a bank of buttons that can be added to a player's console? These buttons can just be appended to the buttons to the right, after the Zoom indicator, "Torp to Ene", the Engineer's 10 preset, the Red Alert button, or just where those buttons would normally be for Science.

The buttons could be created with a command, and given a short label. Then they could be tested for the same way as a client key. You could even assign a client key to the button, so when the player clicks on the button, it is treated as if the key was pressed. Depending on how client keypresses are sent back to the server, it may not necessarily fix the issue with some people not being able to make keypresses work, but it would make for a more intuitive interface.

While I'm at it, I would like to have a way to display a variable in a popup. There's been times I wanted to see the value of a variable or property, although now with <F7> that's not an issue any more. (I still can't see a property, but I can use a loop to "shadow" a property) However, if I have a supply of objects, like beacons the Artemis has to drop off, it would be nice to say how many are left. In fact, along the lines of the above, a command could create an "indicator" instead of a button which displays the current value of the variable. My carrier mission script would benefit from a count of fighters left on board.

Also, although I wasn't explicit about it above, it would be nice if the new Comms menu options could be responded to by the script, instead of the GM having to act as the middleman. Again as above, maybe a Comms menu option could be linked to a client key, and when the menu option is selected, the client key is sent. In fact, you could completely redefine client keys to instead send a defined client action across the network, (with a unique name, like a timer) which could then be activated by a client key, a menu option, or a custom button. That action would then trigger the event in the script, instead of a client key. The GM screen could also have on screen customizable buttons instead of having to use keypresses.

Working backwards, the event the action triggers would give it the name, say "<if_client_action name="Test1" keyText="T"/>. Then when you create a button or menu item you give it a property clientAction="Test1". You can leave off the keyText to have an action with no keyboard shortcut. You would still have to tell consoles to listen for actions, but it would be start_getting_actions_from instead of start_getting_keypresses_from. (Although for backward compatibility you could leave the old command, it just does the same thing)

ryleyra

Registered:
Posts: 3,009
Reply with quote  #2 
Here's another thought I had. When creating an enemy or neutral ship with no name, a random name is assigned. However, that ship can't be edited later to add AI or other changes. In my SoloMode_Siege script, while I was able to create the usual enemies with random names, I had to give the Skaraans names "S01" and so forth so I could make the elite abilities work.

I have a couple of ideas for a solution:

1) There is an attribute use_gm_selection that can be used in place of an object name, just provide an attribute use_last_created_object to specify that object.

2) Provide a means to randomize an object's name. Thus you can create an object with a name, set its properties and AI, and then change its name to something random. For example, <set_object_property name=[object name] />, with no value attribute, could assign a random name. Or, create a new command that randomizes the name.

3) Add a way for variables to be used in a string substitution, they way they can in a literal number expression. For instance, "@MyName" could substitute the value of the variable MyName, while "A@num" where the variable num is 3 would produce A03.
ryleyra

Registered:
Posts: 3,009
Reply with quote  #3 
There was another post that suggested this, and I've thought it was needed for a while myself. So I'm adding it.

Add the ability to detect what a ship's power settings are.

For that matter, why can't we detect red alert in a script?
Arrew

Avatar / Picture

Registered:
Posts: 2,737
Reply with quote  #4 
You can detect shields raised or not if that makes any difference?
ryleyra

Registered:
Posts: 3,009
Reply with quote  #5 
Quote:
Originally Posted by Arrew
You can detect shields raised or not if that makes any difference?


Well, yes, but there are only so many things you can trigger on raise shields.

During one of the canonical missions at Armada, one of the players turned and asked Mike, "They can't detect whether or not we've got missiles in the tubes, can they?" He just smiled. I think he was being cryptic, but the ability to detect if the ship has torpedoes loaded or power to weapons could be useful for effecting enemy AI.

I'll note that soon after they loaded torpedoes, the enemy's behavior changed. [biggrin]

Of course, you can detect if the player is targeting an enemy...

Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,404
Reply with quote  #6 
A lot of these have been suggested many times, some go back to the beginning of Artemis. The most common may be the "Add a Custom Button to a Console Screen" or "Add a Custom Outgoing Message to Communications."

If your script knows how many missiles the ship had in storage then it is easy to tell when one is loaded into the tubes. It's the only way the players can make the count to go down.

Because your script can detect when the players achieve a weapons lock on a specific target, which almost does the job of detecting whether there is power to the weapons.

You can detect Warp State and Actual Speed. If the ship is moving this helps your script know approximately how much power is in the engines.

__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
ryleyra

Registered:
Posts: 3,009
Reply with quote  #7 
Quote:
Originally Posted by Mike Substelny

If your script knows how many missiles the ship had in storage then it is easy to tell when one is loaded into the tubes. It's the only way the players can make the count to go down.


I figured that's what you did. Either that or they targeted the enemy ship. [biggrin]

Quote:
You can detect Warp State and Actual Speed. If the ship is moving this helps your script know approximately how much power is in the engines.


Okay, that's a cute workaround. I'll have to remember that one.

There could be a lot more interaction with the script, however. In my case, I would have liked to launch fighters on my fighter script when Red Alert was sounded. Shields isn't really sufficient for that purpose; a carrier may wish to launch fighters before getting close enough to raise shields, and may want to drop shields for Warp. (Of course, if the carrier is warping out, the fighters should dock first, but not the point. [biggrin])

Likewise, the TSN Roleplay Script tried to come up with a number of ways to activate the "fuel scoop" and Jump Gates, without having to deal with the buggy if_client_key interface. Reading power levels would be a way. (For instance, weapons may have to be offline to activate a Jump Gate)

I was also thinking in the new post in this forum about Non-Weapon missions that Comms could interace more with missions if we could detect when certain messages are sent. For instance, when a base is hailed or asked to produce a particularly kind of torp, it could trigger a mission event. When an enemy is asked to surrender, that could trigger an event.

This is a "Wishlist" thread, after all. Sure, some of these things can be accomplished with a workaround, but it would be easier to check for it directly. [biggrin]

ryleyra

Registered:
Posts: 3,009
Reply with quote  #8 
Adding on some ideas brought up in another thread. Note also that the buttons/Event idea above has been implemented now, as GM buttons in 2.4. The first post is quite old. (It can't even be edited any more) [biggrin]

This idea has also been posted elsewhere, but I'm consolidating it here in this thread.

1) Add the ability to load scripts or script modules from a second script file. This could be as simple as a command like "execute_script" which loads the new file and executes it as a completely new mission, erasing the one currently running. Or, it could be a command like "load_script" which adds the events in a second script file to the events already defined. In this case you could treat the file like a "subroutine" which can be called. It would be helpful to be able to clear events, maybe "clear_loaded_scripts" would clear all events but those that were the original script.

2) Add the ability to save and load variables to a file. The variables could be saved in XML format, for instance <variable name="test" value="100"/>, or even <set_variable name="test" value="100"/> which could be read back in with the "load_script" command above. You would just need to enclose it in an event tag and set a condition to only execute it once.
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.