Scripting requests

[Thargoid]

One more small AI request. Can we have a command broadcastAIMessage, to send an AI message to all other ship AIs in range? Some of the commands already do this (e.g. police getting sent OFFENCE_COMMITTED at suitable points) so I guess most of the code should already be in there.

Also if that is available, some method of having the player ship do such a broadcast (as they don't have an AI to put it in) might be nice too (playerBroadcastAIMessage for example) that something like a missile/bomb or other entity linked to the player may use in lieu of the player ship sending the message.

Finally did my other AI request get overlooked?

[Eric Walch]

One more small AI request. Can we have a command broadcastAIMessage, to send an AI message to all other ship AIs in range? Some of the commands already do this (e.g. police getting sent OFFENCE_COMMITTED at suitable points) so I guess most of the code should already be in there.

What is wrong with using the following ship script:

Code: Select all

function allShips(entity) {return entity.isShip && entity.scanClass !== "CLASS_ROCK" && entity.scanClass !== "CLASS_CARGO"}; 
var anyShips = system.filteredEntities(this, allShips, this.ship, this.ship.scannerRange);
for (var i=0; i<anyShips.length; i++) anyShips[i].reactToAIMessage("YOUR_AI_MESSAGE");

It even gives you full control to which ships the message is send by filtering the wanted ships.

[Kaks]

Finally did my other AI request get overlooked?

In the sense I looked it over, definitely!
As far as I can tell, getting that 'simple' functionality might well need some major code rewriting, so it's unlikely to be added any time soon.

[Thargoid]

One more small AI request. Can we have a command broadcastAIMessage, to send an AI message to all other ship AIs in range? Some of the commands already do this (e.g. police getting sent OFFENCE_COMMITTED at suitable points) so I guess most of the code should already be in there.

What is wrong with using the following ship script:

Code: Select all

function allShips(entity) {return entity.isShip && entity.scanClass !== "CLASS_ROCK" && entity.scanClass !== "CLASS_CARGO"}; 
var anyShips = system.filteredEntities(this, allShips, this.ship, this.ship.scannerRange);
for (var i=0; i<anyShips.length; i++) anyShips[i].reactToAIMessage("YOUR_AI_MESSAGE");

It even gives you full control to which ships the message is send by filtering the wanted ships.

So it can be used for ships without having to give them a script where they don't currently have one. Plus I was trying to save having to do a scan and such when as I said much of the code must already be in trunk for things like police and offences committed.

Also it's awkward to use for the player. For example if I want to have an "illegal" weapon that is an offense to fire, the weapon's script has to then communicate with a separate world script so that the correct ship is sending the offense message (ie that it comes from the player and not the weapon, which by nature will be temporary and not what the police should be hunting down).

[docwild]

Not sure if it has been mentioned before but a push() and pop() method for missionVariables would be most handy, allowing you to treat indexed variables as arrays with dynamic assignment for cross referencing and such like.

Not sure if that was clear, this is how I remove a variable after popping from an array to which it refers:

Code: Select all

this.removedClaimedString = function ()
{
	//blank and refill from array, because we dont have a push() method for missionVariables
	for(var i = 0; i < missionVariable.miningPlayerClaimedNumber; i ++)
	{
		missionVariables["miningPlayerClaimedID" + i] = this.playerClaimedMines[i];
	}
	missionVariables["miningPlayerClaimedID" + missionVariable.miningPlayerClaimedNumber] = ""; //set popped one to ""
}

Adding is trivial but popping from or pushing to the middle is a little more cumbersome but still doable.

It just seems like the kind of thing which is going to be recoded a lot by different OXP authors, with varying results and so might be worth doing in the future.

[Kaks]

It's computationally expensive to use missionVariables this way, and it'll rapidly increase the size of your savegames too.

Using mission variables is akin to using hard disk space rather than RAM. There might well be another way to achieve what you need to do... maybe using a real js array, and only serialise it to one missionVariable once you're docked, thus presumably both able to save your game, and not needing ultra fast frame rates...

[docwild]

There are limits on how many I allow and they aren't used "ingame" as that would be foolish.

building javascript arrays, as you suggest, is easier with array = missionVariables["string" + i] than it is slicing fifteen strings out of one variable, storing their indices and then generating them.

I think my way is faster and it adds less than a kilobyte to the save.

[Kaks]

Err, may I suggest:

Code: Select all

myarray= missionVariables.myarray.split(' ');

That - for me at least - is a cleaner, simpler and faster way to extract arrays from missionVariables.

When saving the array you do:

Code: Select all

missionVariables.myarray=myarray.join(' ');

Of course, this only works well if you're using numbers, of if you haven't got spaces inside the myarray items. A more robust implementation could be

Code: Select all

myarray= missionVariables.myarray.split('@@');

and

Code: Select all

missionVariables.myarray=myarray.join('@@');

EDIT: don't know why, but for a little while there I had forgotten the existence of the .join() method!

[Thargoid]

In shipdata.plist we can define the specific role for a station's defense ships (defense_ship_role), but not for the other ships associated with the station (scavengers for example).

Could we have scavenger_ship_role and perhaps police_ship_role please?

[Thargoid]

And as I seem to be taking over this thread, another one (to replicate the feature request on Berlios).

Can a new function this.playerTakenDamage(damage, where) be added please? To be triggered when the player ship entity takes damage (laser/missile/scrape/heat etc) with damage being the amount of damage and where being where on the ship it was done (forward or aft).

At the moment there's no easy way of tracking and reacting to such damage, given the player has shields as well as energy, that both of those recharge and also other things cause energy drain too. Also whilst there is a function triggered when the player takes energy weapon hits, there isn't anything for when they take missile damage (as opposed to having one fired at them).

[Cmd. Cheyd]

Can we (you wonderful, creative, talented gentlemen) make infoForSystem.planets read/write via JS? So we can specify an planet object prior to entry into a system?

We could specify position, type (STELLAR_TYPE_MOON for example), radius, and texture. Maybe specify a planetinfo.plist entry by name. Then, when we jump in, the core-code could walk the array and build the system?

[Arexack_Heretic]

Can we (you wonderful, creative, talented gentlemen) make infoForSystem.planets read/write via JS? So we can specify an planet object prior to entry into a system?

We could specify position, type (STELLAR_TYPE_MOON for example), radius, and texture. Maybe specify a planetinfo.plist entry by name. Then, when we jump in, the core-code could walk the array and build the system?

I think this is very much already possible.
For instance by setting a missionVariable at event willExitWichspace, then at ExitingWitchspace if MV == set, define system population, including extra planets etc... not sure about multiple suns. The seventh sun will definately be a fireball.

Oh. I think I misread your request. You want system info to be altered.
So for instance, while docked at Zaonce, you want the system info of Lave displayed as a poor agricultural dictatorship?

edit: no I did not misinterpret. Defining the system before getting there is in vain: it does not exist before you get there. Schrodinger reality.

[Kaks]

Err, you can already put condiditons inside planetinfo.plist, and you can define main planet textures both inside planetinfo.plist and js. And you can already add all sorts of planets via js/planetinfo... And again, you can change a system name/techlevel/economy/etc via either planetinfo or js (if via js all system info changes need to be recorded on the savegame, if in planetinfo.plist, no need to record system info changes inside saved games)

As A_H said already, no extra planets are ever generated/accessible before exiting witchspace.

[Cmd. Cheyd]

As A_H said already, no extra planets are ever generated/accessible before exiting witchspace.

That's what why I'm asking for this. Right now, one of the slow points in DH-Systems is caused by the actual spawning of the planets/moons. This is further slowed because textures are chosen AFTER spawning of the added planet/moon (we'll call it a body from here out).

As it is, I spawn a body in-system. The body is created, and since there is no texture assigned via the planetinfo.plist, a procedural texture is generated. Then, a texture is randomly chosen by JS, and applied. This is needlessly slowed by the procedural generation and then re-application of a texture.

Now, I could fix this by specifying a texture in the plist. This would mean my planetinfo.plist would need to be 30x larger at a minimum (20 planet textures x 20 positions + 10 Moon Textures x 10 Positions). Not really an elegant solution.

But, if prior to jump, I could do something like the following:

Code: Select all

var newPlanet;
newPlanet.radius = 3934;
newPlanet.position = [10000, -10000, 0];
newPlanet.type = "STELLAR_TYPE_MOON";
infoForSytem(galaxyNumber,player.ship.targetSystem).planets.push(newPlanet);

this.some_later_function/event/whatever
infoForSystem(galaxyNumber,player.ship.targetSystem).planets[1].texture = "resultFromMyRandomTextureSelectorFunction.png";

Then, after the player jumps, this list could be "walked" and the corresponding entity spawned. A procedural texture isn't needlessly generated, the plist isn't 30-times larger than necessary, and the whole kit and kabootle runs faster.

[Kaks]

The best solution to this problem is to have the same (& tiny) blank texture assigned to all the additional planetary bodies from inside planetinfo.plist.

That should speed up the body's creation quite considerably. Once the blank planet/moon is created you can retexture it to its 'final' & random texture!

No need to create 30x longer plists! Use exactly the same plist & js you're using now, just add a small (64x64 pixels) texture called 'blank.png' to the textures directory and add texture ="blank.png"; to each of the present planet/moon definition.

I almost forgot: it might be best to give that png a slightly different name: 'blank.png' is a bit too generic!