Oolite Bulletins

Posted: **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 ?

Posted: **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

), 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.

Posted: **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 ), 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...

Posted: **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?

Posted: **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

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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

Cheers

L

Posted: **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.

Posted: **Tue Dec 30, 2008 9:01 pm**

Via it's scanclass perhaps?

Posted: **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.)

Posted: **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.

Posted: **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.

Posted: **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.

Oolite Bulletins

Scripting requests

system.WitchSpaceEntryCoordinates(vector)

...