Scripting requests

[Chrisfs]

The Missles oxp has a piece of equipment that does this. It's called a distress beacon and is fired like a missle and 'contacts the nearest base for help'

I haven't actually tried it, you could look at the code and see what it does.

[Commander McLane]

The Missles oxp has a piece of equipment that does this. It's called a distress beacon and is fired like a missle and 'contacts the nearest base for help'

I haven't actually tried it, you could look at the code and see what it does.

It only adds some additional police ships. It doesn't make any existing ship react to what happens to the player.

[Kaks]

A system-property that contains all systems in jumprange, depending on the player's current fuel, perhaps in an array.

Yep. In 1.74

Code: Select all

if (system.isInterstellarSpace && SystemInfo.systemsInRange(player.fuel).length == 0)

will tell you if you're stranded in interstellar space...

[Commander McLane]

Thanks. Eric beat you to it. I already stroke it from my post.

What about the second thing? Having the player exit the tunnel somewhere else than halfway through?

[Commander McLane]

Can we get some new identifying properties in the Ship class?

Something like isRock for asteroids and isCargo for everything else with a white lollipop? Perhaps isDerelict for diabled ships?

And one for all ships which are none of the above, and no mines/missiles, or buoys? Basically anything with a yellow, purple or green/red lollipop? Anything which may fire back if fired at, regardless of its role. I hope you know what I mean.

[Commander McLane]

Apologies if this exists already, but at least it isn't documented.

Make the launchFoo AI-methods available as methods of the Station class. And while you're at it, expose also the counters for the different ship types on a station to JS. And while you're at that, why not some other flags and properties as well? Like these:

Code: Select all

  [dumpState.stationEntity]: Alert level: green
  [dumpState.stationEntity]: Max police: 8
  [dumpState.stationEntity]: Max defense ships: 3
  [dumpState.stationEntity]: Police launched: 1
  [dumpState.stationEntity]: Max scavengers: 3
  [dumpState.stationEntity]: Scavengers launched: 0
  [dumpState.stationEntity]: Docked shuttles: 0
  [dumpState.stationEntity]: Docked traders: 4
  [dumpState.stationEntity]: Equivalent tech level: 4
  [dumpState.stationEntity]: Equipment price factor: 1

[another_commander]

Added the StationEntity JS method launchShipWithRole, which takes as parameter the role of the ship you want launched. Example:

Code: Select all

system.mainStation.launchShipWithRole("thargoid")

if you are feeling adventurous

Right now the ship is added at the end of the launch queue, which means that if the station is launching an Anaconda with six escorts at the time of the execution of the function you may have to wait a bit before seeing your requested ship launched. Whenever I get the opportunity, I will see how feasible it could be to specify immediate launch, by adding the ship at the first position in the launch queue.

[Eric Walch]

Whenever I get the opportunity, I will see how feasible it could be to specify immediate launch, by adding the ship at the first position in the launch queue.

I never saw that as a problem. When launching starts even the last in the queue starts soon enough. Problem is more that launches are postponed till all ships have docked. For 1.73 the AI command "abortAllDockings" is added, maybe this should also available to JS also. In my opinion more important than queue position.
Probably as an optional second parameter?

Code: Select all

system.mainStation.launchShipWithRole("thargoid", true)

Since 1.73 I use this AI command in buoyRepair before launching the tugger with a replacement station-buoy. It now always launches soon enough, even when not as first in the queue or when it is crowded outside of the station.

[JensAyton]

Added the StationEntity JS method launchShipWithRole, which takes as parameter the role of the ship you want launched.

This actually doesn’t fulfil the request, since launchPolice, launchDefenseShip, launchScavenger, launchMiner, launchPirateShip and launchPatrol are limited by internal counters (defenders_launched/max_police and scavengers_launched/max_scavengers). Some of them also select roles based on system govt and tech level.

Ideally, these special behaviours would be implemented in JS and overrideable, but that’s an EMMSTRAN-type feature.

[another_commander]

Added the StationEntity JS method launchShipWithRole, which takes as parameter the role of the ship you want launched.

This actually doesn’t fulfil the request, since launchPolice, launchDefenseShip, launchScavenger, launchMiner, launchPirateShip and launchPatrol are limited by internal counters (defenders_launched/max_police and scavengers_launched/max_scavengers). Some of them also select roles based on system govt and tech level.

The above JS implementation uses Eric's launchIndependentShip:shipRole, which does not check for any internal counters. I was actually able to order the launch of 15 Vipers, when max_police is hardcoded to 8. I also set max_scavengers to 1 for Lave, then launched, spawned a few tenths of cargopods, then ordered 10 scavengers out. The max_scavengers setting did not cause any problems.

[Eric Walch]

This actually doesn’t fulfil the request, since launchPolice, launchDefenseShip, launchScavenger, launchMiner, launchPirateShip and launchPatrol are limited by internal counters (defenders_launched/max_police and scavengers_launched/max_scavengers). Some of them also select roles based on system govt and tech level.

One could add a js equivalent for each of those different cases, or define exceptions for special roles like:

Code: Select all

	if ([shipRole isEqualToString:@"miner"]) [station launchMiner];
	else if ([shipRole isEqualToString:@"scavenger"]) [station launchScavenger];
	else if ([shipRole isEqualToString:@"pirate"]) [station launchPirateShip];
	else if ([shipRole isEqualToString:@"police"]) [station launchPolice];
	else if ([shipRole isEqualToString:@"patrol"]) [station launchPatrol];
	else if ([shipRole isEqualToString:@"defenseShip"]) [station launchDefenseShip];
	else if ([shipRole isEqualToString:@"shuttle"]) [station launchShuttle];
	else [station launchIndependentShip:shipRole];

- Advantage of this is that a script can not cheat anymore by launching a scavenger by its role when max_scavengers is reached.
- Disadvantage is that a script can not cheat anymore like I do with the dredgers. launchMiner is programmed to launch nothing if there is still a miner around. I wanted several miners so I used "launchShipWithRole: miner" and bypassed the check.

[JensAyton]

Added the StationEntity JS method launchShipWithRole, which takes as parameter the role of the ship you want launched.

This actually doesn’t fulfil the request, since launchPolice, launchDefenseShip, launchScavenger, launchMiner, launchPirateShip and launchPatrol are limited by internal counters (defenders_launched/max_police and scavengers_launched/max_scavengers). Some of them also select roles based on system govt and tech level.

The above JS implementation uses Eric's launchIndependentShip:shipRole, which does not check for any internal counters. I was actually able to order the launch of 15 Vipers, when max_police is hardcoded to 8. I also set max_scavengers to 1 for Lave, then launched, spawned a few tenths of cargopods, then ordered 10 scavengers out. The max_scavengers setting did not cause any problems.

That’s kinda the point; it doesn’t have any of the limitations of those methods, limitations that were added with care and attention to detail for good reasons. You still can’t do what those methods do from JS (except by manipulating the station’s AI).

One could add a js equivalent for each of those different cases, or define exceptions for special roles like:

That would be a bad idea, because a) you don’t always want to use the limitations of the limited methods and b) if you call launchShipWithRole("police"), you may be surprised to find you sometimes get something with the "interceptor" role instead.

The specialized methods and the general method serve different purposes, and both should be exposed.

(Oh, and the JS methods should return the launched ship, if any.)

[Eric Walch]

[(Oh, and the JS methods should return the launched ship, if any.)

launchShipWithRole() does now return the ship that is put in the launchQueue. This enables the script to do some final adjustments on the chosen ship before it definitely will launch.

[dumpState.stationEntity]: Alert level: green

Updated the wiki as this property was already part of station with 1.72

[Cmd. Cheyd]

Extension of the SoundSource object to include a method for controlling volume of the sound being played relative to the current max. i.e. - play at 50% of the current volume, play at 100%, etc....

[PhantorGorth]

Request:
Either
a) Modification to the position of the call to guiScreenChange when entering the Equipment Screen to before the calculation of the available equipment.
or
b) New event of guiBeforeScreenChange that occurs before any calculations for the target screen.

Reason:
Currently I am developing an OXP (Visas) that allows for complex criteria for the "Visa" equipment. I was intending to update the appropriate mission variables used by the equipment as the player enters the equipment screen. Example scenario: a visa has as one of it's requirements of the player having to have a minimum amount of credits in their account. If you buy or sell goods, etc, I need to update the mission variables. This idea could also apply to requirements based on contracts accepted or other equipment bought or ship bought, etc. As these things can change whilst the player is still in the station being able to update the mission variable before the equipment calculation is crucial.

Current work around is to go to another screen and back. This works but is very inelegant.

Additional Benefits:
Other OXP developers can also have complex requirements for their equipment.

Comments:
Solution a) would be the simplest but might make the equipment screen become an oddity depending if the other screens do all their calculations before calling the guiScreenChange event. Solution b) is more work but might be more elegant and consistent a solution.

Suggested Code Change (solution a)):

current code in PlayerEntityControls in trunk:
function: - (void) pollGuiScreenControlsWithFKeyAlias:(BOOL)fKeyAlias

Code: Select all

if (([gameView isDown:gvFunctionKey3])||(fKeyAlias && [gameView isDown:gvNumberKey3]))
		{
			if (!switching_equipship_screens)
			{
				if (!dockedStation)  dockedStation = [UNIVERSE station];
				OOGUIScreenID oldScreen = gui_screen;
				
				if ((gui_screen == GUI_SCREEN_EQUIP_SHIP)&&[dockedStation hasShipyard])
				{
					[gameView clearKeys];
					[self setGuiToShipyardScreen:0];
					[gui setSelectedRow:GUI_ROW_SHIPYARD_START];
					[self showShipyardInfoForSelection];
				}
				else
				{
					[gameView clearKeys];
					[self setGuiToEquipShipScreen:0];
					[gui setSelectedRow:GUI_ROW_EQUIPMENT_START];
				}
				
				[self noteGuiChangeFrom:oldScreen to:gui_screen];
			}
			switching_equipship_screens = YES;
		}
		else
		{
			switching_equipship_screens = NO;
		}

modified to:

Code: Select all

if (([gameView isDown:gvFunctionKey3])||(fKeyAlias && [gameView isDown:gvNumberKey3]))
		{
			if (!switching_equipship_screens)
			{
				if (!dockedStation)  dockedStation = [UNIVERSE station];
				OOGUIScreenID oldScreen = gui_screen;
				
				if ((gui_screen == GUI_SCREEN_EQUIP_SHIP)&&[dockedStation hasShipyard])
				{
					[gameView clearKeys];
					[self noteGuiChangeFrom:oldScreen to:GUI_SCREEN_SHIPYARD]; //Changes by PhantorGorth 22-02-2010
					[self setGuiToShipyardScreen:0];
					[gui setSelectedRow:GUI_ROW_SHIPYARD_START];
					[self showShipyardInfoForSelection];
				}
				else
				{
					[gameView clearKeys];
					[self noteGuiChangeFrom:oldScreen to:GUI_SCREEN_EQUIP_SHIP]; //Changes by PhantorGorth 22-02-2010
					[self setGuiToEquipShipScreen:0];
					[gui setSelectedRow:GUI_ROW_EQUIPMENT_START];
				}
				
				//[self noteGuiChangeFrom:oldScreen to:gui_screen]; //Changes by PhantorGorth 22-02-2010
			}
			switching_equipship_screens = YES;
		}
		else
		{
			switching_equipship_screens = NO;
		}

I have given this change a quick test and it appears to work. What I am unsure of, although I have done a search, is that there may be other related parts of the code where changes would need to be made.

Edit: I have had a further look at Oolite's code and they isn't anything more than needs doing.

Is this a go-er for 1.74 or for post-MNSR or am wasting my time here?

I don't have rights to update the svn so I need one of the "proper" developers to comment.