Oolite Bulletins

Posted: **Fri Mar 30, 2007 11:06 am**

SetTargetAsMother

Makes the current target of the entity its Mother. (or Leader for that matter)

It would be usefull for non-standard escorting, guarding, etcetera.

Posted: **Fri Mar 30, 2007 11:13 am**

Again, much too specific and tied to the current scripting model.

Once the JavaScript object model is fleshed out, that’ll be something like “ship.target = ship.leader”. Specific methods for every possible combination of properties will no longer be needed.

Posted: **Fri Mar 30, 2007 11:21 am**

I understood you wanted specific requests...

We can only reason from past experience.
I can't know how the Java-scripting is going to handle things.

But if as you say, methods can be specified on the fly, then many things will be possible.

Posted: **Fri Mar 30, 2007 11:28 am**

I understood Ahruman in the same way as you did, A_H, so you're not the only one.

Anyway, a method for making an entity the mother of other entities (called by the respective daughter-entities) is exactly what I need for my sentinel asteroids-problem, I guess.

So I second the request.

And (as I don't know if that is self-evident) all entities tying themselves to the same mother via this method should also become a group and therefore get able to reply to groupAttackTarget etc.

Posted: **Fri Mar 30, 2007 11:36 am**

Interesting. I intended to write “Post a description rather than desired method name” where it currently says “ Post a description of the desired method name”. I also vividly remember fixing this typo several days ago. Bah.

Anyway… a useful request discusses capabilities, rather than explicit code (in either the existing model or JS).

Posted: **Fri Mar 30, 2007 1:21 pm**

I always post requests as a

proposedMethodName
+
description of function in the game engine ( +subject and object ) as I percieve it to work.

Posted: **Sat Mar 31, 2007 11:57 pm**

Wouldn't an 'ignore friendly fire' method be useful? For instance, if it could be tied to scan-class, it would prevent protracted Galcop-on-Galcop firefights developing, and if scan-class could be user-defined it would allow factional OXPs to be developed.

Let me know if you want me to ellucidate further, and feel free to contribute any of you own suggestions (if you've understood, this far, that is).

Posted: **Sun Apr 01, 2007 2:23 pm**

Timers. Something like:

Code: Select all

RegisterTimer("Stuff I need to do", myCallback, 42.0);

where "Stuff I need to do" is a unique (to the script) identifier, myCallback is a JavaScript function, and 42.0 is a time in seconds (in play time; also need a clear discussion of real time vs. play time vs. clock time). Not in 1.68. (Motivation: this is both more efficient and more precise than running stuff off the tickle timer.)

Posted: **Mon Apr 02, 2007 3:19 pm**

Ability to play “cabin sounds” (sounds with no spacial localization – not a meaningful distinction, yet) and music. Events for various things that make noise (weapons fire). Standard sound effects for these events being moved out into scripts, which can be overridden.

Posted: **Mon Apr 02, 2007 3:35 pm**

JavaScript for non-player ships. This will take over the responsibilities of AIs, but also other stuff; for instance, spawn_actions and death_actions will be replaced with ship script events. I’m not sure how to replicate the ability to change AIs that’s currently in place, or whether that will be needed. Possibly ships will have a script and an AI as separate entities.

Ship scripts will look quite a lot like world scripts, only receiving events for their respective ships rather than the player.

Scripts should be able to send commands directly to any entity.

Posted: **Mon Apr 09, 2007 7:45 am**

Good job on updating Oolite.

Things I'd like to be able to control with an OXP:

Current system (to have a ship the player is docked with travel to a chosen system or interplanetary space between two chosen systems).

Player ship (I'd like to be able to control which ship and which equipment a player has and to be able to 'store' a ship and it's configuration in the save file for later retrieval).

Both would be necessary for Sidewinder Commander

Sidewinder Commander.

The commander is hired by the navy as a Sidewinder pilot. They store his ship while he works his way up in the navy ranks by completing missions from millitary bases and carriers in ever cooler naval ships.

Mostly very short intensely battle oriented missions like carrier defense or interstellar raid. The pay is lousy but there's lots of action and zero expenses.

Instead of paying for gear you are given equipment according to the mission and of course matching your expendability (rank) with the expendability of your gear to the navy.

I.e. you will only get a beam laser equipped sidewinder with nothing else to begin with and have to balance your play between letting others with better equipment take more of the heat in large battles, while still trying to grap some glory in order to advance in rank and get better equipped.

And there would probably be a lot of other cool uses for such features.

Posted: **Mon Apr 09, 2007 9:50 am**

A death_by_player_action (as an alternative to death_actions) would be handy.

Oolite presumabley knows that the player rather than an NPC was responsible for a ships death as it awards a kill, but a way for the script to act on this would be useful in combat / escort missions.

EG: Death_actions can be used to advance a counter in a "defend the trade fleet" type mission where a certain number of deaths gives a "tried but failed" briefing. However, carless use of an e-bomb by the player could give a "what did you think you were doing, you were meant to be defending them!" briefing, possibley earning the employer's wrath!

Friendly Fire can be done with an AI that does not go to "Attack Ship" just because the ship has been attacked. EG:-

Code: Select all

"LOOK_FOR_TARGETS" = {
ENTER = (switchLightsOff, "scanForNearestShipWithRole: victim9");
        "ATTACKED" = ("setStateTo: LOOK_FOR_TARGETS"); 
        "INCOMING_MISSILE" = (fightOrFleeMissile, "setStateTo: LOOK_FOR_TARGETS"); 
		"TARGET_FOUND" = (setTargetToFoundTarget, "setStateTo: ATTACK_SHIP"); 
        	"NOTHING_FOUND" = ("setStateTo: LOOK_FOR_TARGETS2"); 
EXIT = ();
	UPDATE = ("scanForNearestShipWithRole: victim9");
	};

"LOOK_FOR_TARGETS2" = {
ENTER = (switchLightsOff, "scanForNearestShipWithRole: warfrigate");
        "ATTACKED" = ("setStateTo: LOOK_FOR_TARGETS"); 
        "INCOMING_MISSILE" = (fightOrFleeMissile, "setStateTo: LOOK_FOR_TARGETS"); 
		"TARGET_FOUND" = (setTargetToFoundTarget, "setStateTo: ATTACK_SHIP"); 
        	"NOTHING_FOUND" = ("setStateTo: LOOK_FOR_TARGETS"); 
EXIT = ();
	UPDATE = ("scanForNearestShipWithRole: warfrigate");
	};

If the Gobal sets the state to look for targets, then this ship will only fire on or return fire to ships with the role victim9 or warfrigate. If a ship from its own side hits it, rather than switching to attack ship it attacks the nearest enemy ship.

Posted: **Mon Apr 09, 2007 10:28 am**

yoink

Posted: **Mon Apr 09, 2007 11:32 am**

LittleBear wrote:
A death_by_player_action (as an alternative to death_actions) would be handy.

Hopefully it will be possible for ship-attached JavaScript scripts to get a “who killed me” parameter to their didBecomeDead() handler.

Posted: **Mon Apr 09, 2007 4:46 pm**

Ahruman wrote:
Hopefully it will be possible for ship-attached JavaScript scripts to get a “who killed me” parameter to their didBecomeDead() handler.

Update on this: the world script event for player deaths now has two paramaters, “whodunnit” and “context”, as in:

Code: Select all

this.didBecomeDead = function(whodunnit, context)
{
    Log("Gadzooks! Player was killed by " + whodunnit + " through " + context + ".");
}

Context can (currently) be one of:

“energy damage” (whodunnit is a ship)
“scrape damage” (whodunnit is a ship)
“heat damage” (whodunnit is null)
“hit a planet” (whodunnit is a planet)

There will be a similar takeDamage() event for energy, scrape, and possibly heat damage.

My intention is (still) to have NPC scripts look similar to world scripts, so the same principle will apply.

Oh, it’ll also be possible for NPC scripts to suppress explosions in their death handlers.

Oolite Bulletins

Scripting requests

code request: