Scripters cove

[Smivs]

Hi Maik,
Eric is suggesting you add a 'FLEE' state to your AI so the ship flees if the energy is low.

So in the AI you have try

Code: Select all

  ENERGY_LOW = ( "setStateTo: FLEE");

and add something like

Code: Select all

	FLEE = 
	{
		ENTER = ("setDesiredRangeTo: 25600", performFlee); 
		ATTACKED = (fightOrFleeHostiles); 
		FIGHTING = (setTargetToPrimaryAggressor, "setStateTo: ATTACK_THARGOID");
		FLEEING = (setTargetToPrimaryAggressor, "setStateTo: FLEE");
		"TARGET_LOST" = (performIdle, setStateTo: LOOK_FOR_THARGOIDS); 
		"TARGET_DESTROYED" = (setStateTo: LOOK_FOR_THARGOIDS); 
		"INCOMING_MISSILE" = (fightOrFleeMissile); 
		"REACHED_SAFETY" = (performIdle, setStateTo: GLOBAL); 
      UPDATE = ();
	};

which is adapted from one of the core AIs.

[cim]

cim: I was thinking of removing the main station and replacing it with a station of my own. But I then need to add a station to my oxp. A lot of work when I was hoping for a line or two of JS code instead.

Well, there's nothing to say the replacement station can't be the same as the original - no need to put together a new model or even much in the way of new behaviour - just do a

Code: Select all

like_ship="dodecahedron_station"

in your shipdata.plist, and then all you need to add after that is a little bit of tweaking to set up markets and shipyard, and a modified roles entry so that you can add it instead of the original.

[Wildeblood]

cim: I was thinking of removing the main station and replacing it with a station of my own. But I then need to add a station to my oxp. A lot of work when I was hoping for a line or two of JS code instead.

Thanks for two good ideas. If there is no way to do it by script them removing the main station is the way to go as far as I can see. Unless someone has another idea!

I don't think that idea would work (that simply) anyway. Every normal system has a main station. My understanding is that if you destroy the default main station, an added station will automagically become the new main station (with an F2 screen). Is it really a good idea to try to discourage the player from saving the game? If you are determined to do so, you would need to destroy all stations, add a station where the player can't find it to be the main station, then add your customized station to the system after the hidden one.

[Wildeblood]

I want to create a group of asteroids which behave as one object when the player is trying to target them with the ident computer. One will be the core, and there will be several others around it. If the player targets one of the outlying ones, target should be immediately re-directed to the core one, so the player can't get a target lock on the outliers. Suggestions, please?

[Disembodied]

This may be a cripplingly stupid question, but do subentities have to be physically attached to their ... um ... overentity? If not, then maybe that might be a way of doing it.

[Smivs]

They don't...they can be 'remote', but this is unlikely to work as I suspect the 'bounding box' would encompass all the asteroids and any of them could still be shot.

[Wildeblood]

This may be a cripplingly stupid question, but do subentities have to be physically attached to their ... um ... overentity? If not, then maybe that might be a way of doing it.

In two of Simon B's shipsets he used a sub-entity for shuttle's wings. He called both simply "wings" or "shuttle-wings", but they are very different models. If you put both OXPs in together, biplane shuttles appear with the second, unconnected, wing about a ship's length away from the rest of the ship.

But I don't want these objects to move together, or anything fancy, I just want a ship script on most to re-direct a target lock to the core. So I need a filtered entities list to find the nearest object with role comet-nucleus, I'm guessing.

Smivs, I don't want to hold them in a single bounding box, or prevent them getting shot, I just want to re-direct target locks on the outliers. So if you target one of the outlying boulders, instead of seeing "Boulder" on screen, the target snaps to the central one, and you see "Comet Smivs", or whatever.

[Smivs]

Smivs, I don't want to hold them in a single bounding box, or prevent them getting shot, I just want to re-direct target locks on the outliers. So if you target one of the outlying boulders, instead of seeing "Boulder" on screen, the target snaps to the central one, and you see "Comet Smivs", or whatever.

Yeah, I'd figured that which is why I didn't suggest it in the first place.
I do like the idea of Comet Smivs though.

[Capt. Murphy]

Only came across this useful JS resource a few days ago...

https://developer.mozilla.org/en/JavaScript/Reference

[Zieman]

They don't...they can be 'remote', but this is unlikely to work as I suspect the 'bounding box' would encompass all the asteroids and any of them could still be shot.

If you set the main entity's frangible key to false, IIRC you cannot target or shoot off any subentities.

[Fatleaf]

Is there anyway to give them a military jamer. Then you cant get a lock on them but you can shoot them.

[Capt. Murphy]

In response to this post in Scripting Requests:

Expose the galaxy seed numbers as read-only, so that scripts can confirm they are actually dealing with the galaxy configuration the scripts' authors assume they are. (There is no Oresrati in my ooniverse.)

this code snippet should do the trick - not fully tested as yet....

Edit - having done some testing amended and working code snippet is below.

// uses the known position of systemID 255 in each galaxy to check if player is using non standard galaxy_seed.
switch (galaxyNumber)
{
case 0:
{
if (System.infoForSystem(0, 255).coordinates.distanceTo([4.8,40.6,0]) > 0.00001)
{this.alternateOoniverse = true;}
}break;
case 1:
{
if (System.infoForSystem(1, 255).coordinates.distanceTo([9.6,30.4,0]) > 0.00001)
{this.alternateOoniverse = true;}
}break;
case 2:
{
if (System.infoForSystem(2, 255).coordinates.distanceTo([31.2,42.4,0]) > 0.00001)
{this.alternateOoniverse = true;}
}break;
case 3:
{
if (System.infoForSystem(3, 255).coordinates.distanceTo([62.4,34.2,0]) > 0.00001)
{this.alternateOoniverse = true;}
}break;
case 4:
{
if (System.infoForSystem(4, 255).coordinates.distanceTo([51.2,28.8,0]) > 0.00001)
{this.alternateOoniverse = true;}
}break;
case 5:
{
if (System.infoForSystem(5, 255).coordinates.distanceTo([86.4,27.6,0]) > 0.00001)
{this.alternateOoniverse = true;}
}break;
case 6:
{
if (System.infoForSystem(6, 255).coordinates.distanceTo([70.8,4.6,0]) > 0.00001)
{this.alternateOoniverse = true;}
}break;
case 7:
{
if (System.infoForSystem(7, 255).coordinates.distanceTo([90.8,39.8,0]) > 0.00001)
{this.alternateOoniverse = true;}
}break;
default: // if galaxyNumber less than 0 or more than 7 it is definitely not the Ooniverse as we know it.
{this.alternateOoniverse = true;}break;
}

[Wildeblood]

In response to this post in Scripting Requests:

Expose the galaxy seed numbers as read-only, so that scripts can confirm they are actually dealing with the galaxy configuration the scripts' authors assume they are. (There is no Oresrati in my ooniverse.)

this code snippet should do the trick - not fully tested as yet....

if (System.infoForSystem(galaxyNumber, 0).coordinates.distanceTo([0.8,18,0]) !== 0)
{this.alternateOoniverse = true;}

Thank you for your interest in the Galaxy Nine/Multiverse Explorers' Club, Capt. Murphy. (Club motto: 2048 non sufficit, Mr Bond.) If I'm reading it correctly, your suggestion is to check that system number 0 is in it's "correct" position. I had thought of that approach long ago, and discarded the idea because: the player may have merely shifted the galaxy number, not the seed values, and even accounting for this simple exception leads to code bloat; it only allows to check for a particular ooniverse, selecting among several leads to extreme code bloat; and I doubt the co-ordinate positions are sufficiently granular - sooner or later a completely different galaxy will have the same position for system 0.

Since I needed to address this problem to make the GalDrive Programmers, I settled on the simpler solution of adding a mission variable that explicitly states ooniverse = "elite". That is, this saved game is assumed to use the traditional galaxy seeds from Elite (with their traditional numbers*).

You can make OXPs like Explorers' Club multiverse compatible by checking for this mission variable at start-up and affixing its contents into the names of any relevant mission variables. So, for example, missionVariables.explorerClub_record could become missionVariables.explorerClub_elite_record or missionVariables.explorerClub_murphiverse_record. (If only changing phone companies were as easy.)

* Now that I think about it, including a shift number from 0-7 probably would have been a good idea, and I should have used "elite-0". Good one, that's solved another problem. Now you can start mapping your personal ooniverse and not cause too much drama if you haven't decided which galaxy to use as the starting point.

[cim]

Is there a way to set a ship's lasers from script? I have:

Code: Select all

assassins = system.addShips("hunter", ...);

to add a few hired guns to attack the player with. I would like to give at least some of them an aft laser to make them a little more dangerous in a dogfight.

This is straightforwardly possible by using "like_ship" in shipdata.plist, of course, and giving them a new "vicious_hunter" role, but I'd like the script to be able to use hunters from other ship OXPs without having to have a separate "like_ship" entry (most with "is_external_dependency") for every ship I've heard of, which then needs updating every time there's a new ship OXP released.

I can't find anything from the documentation and experimentation, but I thought I'd better ask before I started massively expanding shipdata.plist.

[Capt. Murphy]

Thank you for your interest in the Galaxy Nine/Multiverse Explorers' Club, Capt. Murphy. (Club motto: 2048 non sufficit, Mr Bond.) If I'm reading it correctly, your suggestion is to check that system number 0 is in it's "correct" position. I had thought of that approach long ago, and discarded the idea because: the player may have merely shifted the galaxy number, not the seed values, and even accounting for this simple exception leads to code bloat; it only allows to check for a particular ooniverse, selecting among several leads to extreme code bloat; and I doubt the co-ordinate positions are sufficiently granular - sooner or later a completely different galaxy will have the same position for system 0.

I could well be missing something because I have not looked into this at all closely, but....

If the player had shifted galaxy number only (and I must admit to being unsure how the player would accomplish that) then surely the script as it stands would work as it looks for whatever the current galaxy number is when it runs and then checks to see of systemID 0 is in the expected location for that galaxy number in the default Ooniverse. If the galaxy numbers are different then systemID 0 will be in a different location and the script will correctly detect an alternateOoniverse.

True it is possible that a different galaxy_seed value could potentially put system 0 in galaxy 0, or in any other galaxy in the same position as in the default Ooniverse, but I would have thought that that would be very, very, very unlikely. Perhaps a dev. with a knowledge of the maths could comment on probability of this happening? If it's not vanishingly small it's no hardship to add a check for systemID's 1 as-well. It's five minutes work with the debug console to check the locations in the default Ooniverse.