Scripting requests

An area for discussing new ideas and additions to Oolite.

Moderators: winston, another_commander

User avatar
Frame
---- E L I T E ----
---- E L I T E ----
Posts: 1474
Joined: Fri Mar 30, 2007 8:32 am
Location: Witchspace

system.WitchSpaceEntryCoordinates(vector)

Post by Frame » Sun Dec 21, 2008 5:19 pm

javascript
system.WitchSpaceEntryCoordinates(vector) read/write

The ability to move the Witch Space Entry Coordinates, could solve the precision problem, in fact it could be hard-coded.

Hard-coded or Java Scripted it would work like this....

When player distance to position 0,0,0 is greater than 7 million km.

Calculate a vector from the player to position 0,0,0...
Calculate the players position Along that vector some 6 milliom km towards the 0,0,0 position...

Take the difference between the players current position and the calculated position, and move everything that difference... Then everything should be relative correct...

Finally move the player

This way the player always stays within 7 million miles boundary to the 0,0,0 point...

A change in internal and external Coordinate system may be required when hardcoded... the boundary used should change between 7 and 8 million miles so that we do not get to much flickering / freezing.

so what do you think ?
Bounty Scanner
Number 935

User avatar
Cmd. Cheyd
---- E L I T E ----
---- E L I T E ----
Posts: 928
Joined: Tue Dec 16, 2008 2:52 pm
Location: Deep Horizon Industries Manufacturing & Research Site somewhere in G8...

Post by Cmd. Cheyd » Mon Dec 22, 2008 6:14 pm

Ability to texture the sun, similar to the method used to texture planets and moons?

-- I'm working on an OXP that will replace the "glowing white ball" with some heliospectragraphic images. I'm trying to "freehand" the textures currently, but if that fails miserably (I know my artistic talents :P), I was going to try and smooth / clean up some of the SOHO images that NASA and the ESU jointly publish. They are free for non-commercial use, so long as credit is given.

User avatar
Frame
---- E L I T E ----
---- E L I T E ----
Posts: 1474
Joined: Fri Mar 30, 2007 8:32 am
Location: Witchspace

Post by Frame » Mon Dec 22, 2008 6:38 pm

Cmd. Cheyd Vlos'Olplyn wrote:Ability to texture the sun, similar to the method used to texture planets and moons?

-- I'm working on an OXP that will replace the "glowing white ball" with some heliospectragraphic images. I'm trying to "freehand" the textures currently, but if that fails miserably (I know my artistic talents :P), I was going to try and smooth / clean up some of the SOHO images that NASA and the ESU jointly publish. They are free for non-commercial use, so long as credit is given.
While in every code reference the sun is treated like a planet, in graphical terms in regard to how it is drawn.. it is not...

The sun is a disc, rather than a 3 dimensional model, therefore its 2D, that means that a texture, if able to be set for the sun, would always be looking the same no mater what direction you are looking at it from.

It will mean Oolite would have to start using 3d models instead of the 2d disc that it is using now...
Bounty Scanner
Number 935

User avatar
Cmd. Cheyd
---- E L I T E ----
---- E L I T E ----
Posts: 928
Joined: Tue Dec 16, 2008 2:52 pm
Location: Deep Horizon Industries Manufacturing & Research Site somewhere in G8...

Post by Cmd. Cheyd » Mon Dec 22, 2008 8:45 pm

While in every code reference the sun is treated like a planet... It will mean Oolite would have to start using 3d models instead of the 2d disc that it is using now...
Please? If so, can we give it most of the same methods and properties? sun.RotationSpeed, sun.Diameter, sun.IsMain, system.AddSun... I can think of a whole slew...

Then I could really have some fun making binary or even trinary star systems. (Currest thinking says 60% of all systems are at least binary.. Not that that would hold true for systems that have planets in the habitable zone, hence why none appear in Oolite...)

Actually, might it be easiest to turn the sun into a planet (code wise) and add the property of .IsStar?

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch » Wed Dec 24, 2008 9:12 am

I like to see that the AI command checkForHoldFull generates 3 different messages: HOLLD_FULL, STILL_HUNGRY and NO_CARGO_BAY. This way you can write code that ensures that it always proceeds to an next state when using the command checkForHoldFull.

At the same time all other places that generate a HOLLD_FULL message should only do that when the ship actually has a bay. This to let them not react as if they had scooped something.

see also here

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5398
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander » Wed Dec 24, 2008 10:40 am

The checkForFullHold method has been modified as follows on SVN 1918:

Code: Select all

- (void) checkForFullHold
{
	if (!max_cargo)
	{
		[shipAI message:@"NO_CARGO_BAY"];
	}
	else if ([cargo count] >= max_cargo)
	{
		[shipAI message:@"HOLD_FULL"];
	}
	else
	{
		[shipAI message:@"HOLD_NOT_FULL"];
	}
}
Additionally, as of SVN 1919, HOLD_FULL is broadcasted only if ships actually have cargo carrying capability as per Eric's request.

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch » Wed Dec 24, 2008 11:23 am

Thanks Another_Commander,

but to be perfect the HOLD_FULL message must also be suppressed when there is no bay in the scanForLoot. Like:

Code: Select all

- (void) scanForLoot
{
	/*-- Locates the nearest debris in range --*/
	if (!isStation)
	{
		if (![self hasScoop])
		{
			[shipAI message:@"NOTHING_FOUND"];		//can't collect loot if you have no scoop!
			return;
		}
		if ([cargo count] >= max_cargo)
		{
			if (max_cargo > 0)
			{
				[shipAI message:@"HOLD_FULL"];		//can't collect loot if holds are full!
			}
			[shipAI message:@"NOTHING_FOUND"];		//can't collect loot if holds are full!
			return;
		}
	}
I see no reason why this could break existing AI code. Currently miners always have a bay so here is no difference. Pirates with no bay now already react on the NOTHING_FOUND first and get the HOLD_FULL message in the next state were it is not evaluated further. I think this also will be the case for existing AI's in OXP's: An oxp with ships that must react on a HOLD_FULL will most likely have a cargo bay.

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5398
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander » Wed Dec 24, 2008 12:00 pm

Eric, the change you have proposed is already included in SVN 1919. Check the ShipEntityAI.m file currently in the trunk.

User avatar
Lestradae
---- E L I T E ----
---- E L I T E ----
Posts: 3092
Joined: Tue Apr 17, 2007 10:30 pm
Location: Vienna, Austria

...

Post by Lestradae » Wed Dec 24, 2008 12:13 pm

As usual, I have no idea if my suggestion is practicable script-wise, but it would be a very convienient game feature for sure.

Would it be possible to add some sort of ...

<key>ShipScale</key>
<real>1.5</real>

... to the trunk?

It could have a default setting of 1.0 and have the effect of depicting the ship model, its exhaust port, missile positions, laser positions and all its subentities as bigger or smaller as the original model, i.e. with 0.5 you get a model half as small and with 2.0 a double model etc.

If that was customisable from the shipdata.plist, it would be very helpful to give ships from different oxps fitting scales in relation to each other.

If it's doable without a lot of problems, I'd request this as an X-mas present :twisted:

Cheers

L

User avatar
Commander McLane
Intergalactic Spam Assassin
Intergalactic Spam Assassin
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Post by Commander McLane » Tue Dec 30, 2008 2:03 pm

*

One (or probably two) new Ship properties: isMissile (and perhaps isMine).

Not the most urgent thing to have, but could be useful. Currently there is no quick and elegant check whether a ship is a missile or mine.

User avatar
Thargoid
Thargoid
Thargoid
Posts: 5510
Joined: Thu Jun 12, 2008 6:55 pm

Post by Thargoid » Tue Dec 30, 2008 9:01 pm

Via it's scanclass perhaps?

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton » Wed Dec 31, 2008 3:14 pm

Commander McLane wrote:One (or probably two) new Ship properties: isMissile (and perhaps isMine).
Done: isMissile, isMine, and isWeapon (currently equal to isMissile || isMine, other types could potentially be added).

(These already existed internally; not exposing them through JS was an oversight.)

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch » Thu Jan 01, 2009 3:27 pm

It could be that this is not reliable, even when used internal in the code. Missile and mine are defined as:

Code: Select all

- (BOOL)isMissile
{
	return [[self primaryRole] hasSuffix:@"MISSILE"];
}

- (BOOL)isMine
{
	return [[self primaryRole] hasSuffix:@"MINE"];
}
But when a NPC ship launches a missile there is a 10% chance of the primary role being missile and when it is launched by custom role it even does not needs a role with MISSILE suffix in its definitions, as the code is:

Code: Select all

- (BOOL) fireMissile
{
	// deletions
	// custom missiles
	missileRole = [shipinfoDictionary stringForKey:@"missile_role"];
	if (missileRole != nil)  missile = [UNIVERSE newShipWithRole:missileRole];
	if (missile == nil)	// no custom role
	{
		if (randf() < 0.90)	// choose a standard missile 90% of the time
		{
			missile = [UNIVERSE newShipWithRole:@"EQ_MISSILE"];	// retained
		}
		else				// otherwise choose any with the role 'missile' - which may include alternative weapons
		{
			missile = [UNIVERSE newShipWithRole:@"missile"];	// retained
		}
	}
   // deletions
	missile->isMissile = YES;
   // deletions
	if ([missile scanClass] == CLASS_MISSILE)
	{
		[target_ship setPrimaryAggressor:self];
		[target_ship doScriptEvent:@"shipAttackedWithMissile" withArgument:missile andArgument:self];
		[target_ship reactToAIMessage:@"INCOMING_MISSILE"];
	}
When scan-class is missile, the target ship gets a warning so it does know it is a missile but isMissile will not always be true for that missile! Or do I miss something because in the fireMissile it does set the isMissile property to YES. But in that case the targlets also have a isMissile set.

Than I looked in the routine where the Q-bomb is dropped by a NPC ship:

Code: Select all

- (BOOL) launchEnergyBomb
{
	if (![self hasEnergyBomb])  return NO;
	[self setSpeed: maxFlightSpeed + 300];
	ShipEntity*	bomb = [UNIVERSE newShipWithRole:@"energy-bomb"];
This is actually a mine that is dropped and in the primary role of "energy-bomb" (one of the roles of the q-bomb). But in these routine nowhere the isMine property is set. I think a check for isMine will fail here.

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch » Thu Jan 08, 2009 8:49 am

While working on a station script I missed a few things that are easy to add.

1) A handler on a ships launch. That way the script can do some final adjustments to a ship on launch.

2) A handler on a docking request. With this a script can possible refuse or alter dockings based on role.

3) The primary role of pirated launched with launchPirateShip should be altered to defense_ship (not pirate). Only with a defense_ship role the docked ships are added again to the available defence ships of the station.

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5398
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander » Thu Jan 08, 2009 1:18 pm

Eric Walch wrote:While working on a station script I missed a few things that are easy to add.

1) A handler on a ships launch. That way the script can do some final adjustments to a ship on launch.

2) A handler on a docking request. With this a script can possible refuse or alter dockings based on role.

3) The primary role of pirated launched with launchPirateShip should be altered to defense_ship (not pirate). Only with a defense_ship role the docked ships are added again to the available defence ships of the station.
1) The station script event handler NPCShipLaunchedFromStation has been added. It takes as parameter the entity that was launched. Use it like this:

Code: Select all

this.NPCShipLaunchedFromStation = function(aShip)
{
    log("test", "Ship "" + aShip.name + "" with role "" + aShip.primaryRole + "" launched from station.");
} 
2) If you are referring to docking clearance, then there is already in the code the handler playerRequestedDockingClearance which takes as parameter the resulting clearance status from the station.

3) The primary role of pirates launched from stations has been changed to defense_ship for the launchPirateShip method.
Last edited by another_commander on Thu Jan 08, 2009 3:25 pm, edited 1 time in total.

Post Reply