Page 27 of 56
Posted: Fri Aug 20, 2010 4:35 pm
by Cmd. Cheyd
Okay. That was my fallback idea. I was going to do it with a 1px x 2px image.
Posted: Mon Sep 06, 2010 7:36 am
by Thargoid
Can I request a this.gameWillSave(type) world script function that triggers just before a save-game (type = auto, quick or standard for the different types of save-game).
For use to refresh mission variables etc just before a save-game to ensure that they are up to date, especially when the MV is used to encode something else like an array to make it persistent.
Posted: Mon Sep 06, 2010 8:45 am
by Ragged
Can we have a way to set an absolute colour of the sun, please, without the 50% white admixture.
Mainly because a black sun with a red corona will make a passable black hole.
Posted: Mon Sep 06, 2010 6:27 pm
by another_commander
Thargoid wrote:Can I request a this.gameWillSave(type) world script function that triggers just before a save-game (type = auto, quick or standard for the different types of save-game).
For use to refresh mission variables etc just before a save-game to ensure that they are up to date, especially when the MV is used to encode something else like an array to make it persistent.
Done. Taken from the commit comments of r3746:
Added the playerWillSaveGame script event handler, taking as parameter the type of savegame, which can be standardSave, autoSave or quickSave.
Posted: Mon Sep 06, 2010 6:31 pm
by Thargoid
Thank you 
Whilst I'm in this thread, would it be possible for this.shipFiredMissile to trigger for mines (_MINE) as well as missiles? At the moment I can't see a way to reliably detect a ship launching a mine (or in the case I'm trying to do to detect when they have nothing left on their pylons) without using a timer and a check on player.ship.missiles.length.
And as I'm in a demanding mood tonight, how about a this.shipAwardedEquipment(equipment) triggered when a ship is script-awarded a piece of equipment (as opposed to the player buying it triggering this.playerBoughtEquipment which doesn't get triggered by a script-award).
Posted: Wed Sep 08, 2010 7:10 am
by Thargoid
another_commander wrote:Done. Taken from the commit comments of r3746:
Added the playerWillSaveGame script event handler, taking as parameter the type of savegame, which can be standardSave, autoSave or quickSave.
Berlios still seems to be on 3745 (from 3rd Sept)? Has something gone wrong with the distribution or update?
Posted: Wed Sep 08, 2010 8:15 am
by another_commander
Thargoid wrote:Berlios still seems to be on 3745 (from 3rd Sept)? Has something gone wrong with the distribution or update?
Actually, Berlios is on 3747 at the moment. The problem seems to be the server distributing the nightly builds. Hopefully Getafix will take care of it soon.
Posted: Sun Nov 07, 2010 10:08 am
by Thargoid
A thought leading on from this discussion. Would it be possible to have a new event function (e.g. this.scriptsLoaded or something nicer) that is executed once all scripts have been loaded. To be used for example to check whether a particular script (and so OXP) is loaded, for either dependency or incompatibility checking.
We can use a timer run from this.startUp to check for dependencies etc, but having the function above would be nicer and cleaner as you wouldn't have to guess what length the timer would need to be.
Posted: Sun Nov 07, 2010 11:15 am
by Eric Walch
Thargoid wrote:.....as you wouldn't have to guess what length the timer would need to be.
The internal clock is not updated during handler execution, so a time of 0 seconds should be enough to load last. Or use 0.1 when in doubt of equality, that last value always worked for me.
Posted: Tue Nov 09, 2010 10:29 pm
by Thargoid
One semi-oddity.
By script we can set position for entities, but seemingly not sub-entities attached to one (ie you can't move a sub-ent around relative to its main mother entity). Orientation/rotation works, but position seems fixed?
Is there a specific reason for that, or could such functionality be added? That would open up some interesting ideas for ships and OXPs...
Posted: Wed Nov 10, 2010 7:56 am
by Kaks
Err, I don't seem to have any problems moving the position of subentities, at least in trunk...
Posted: Wed Nov 10, 2010 9:19 am
by Thargoid
Didn't seem to work for me in 1.74.2 last night.
Maybe I did something wrong - will check again tonight with that and also with a trunk set-up.
Posted: Wed Nov 10, 2010 9:30 am
by Eric Walch
Thargoid wrote:Didn't seem to work for me in 1.74.2 last night.
Maybe I did something wrong - will check again tonight with that and also with a trunk set-up.
It should have worked in 1.74. I used it in the past sometimes to quickly find a nice position to put my subentities on ships. That suitable position found I added to shipdata. (Works much faster than restarting Oolite everytime after changing shipdata)
Posted: Wed Nov 10, 2010 10:36 am
by Thargoid
I think I see where I went wrong in the scripting. Will test tonight and then begin to ponder what else can be done with this functionality 
Posted: Sat Nov 13, 2010 12:12 pm
by Commander McLane
An AI method to attach a script to a ship.
Reason: As we know, the full possibilities of AI scripting are only open in combination with ship scripts. However, it is a little tricky to attach a ship script to a ship if you have no access to its shipdata. For instance, if you want to create a modified version of route1traderAI which sends script messages. It is impractical or plainly impossible to insert a script-key into the shipdata of all ships which may get route1traderAI. Even if you would create and maintain a monstrous shipdata-overrides.plist, what if someone else would want to attach a different script snippet to the ships? The overrides would override each other.
But what if the AI itself, in the very moment it starts, could amend the ship script itself? I have no idea if that's even possible, but it would be extremely useful. I could imagine a method with a js-file as parameter. The content of that JS file would then be added to the ship script.
Alternatively, and more indirect, an AI message that triggers a new world script event. In this case the actual attaching could be done in the world script. The event should then have the triggering entity as a parameter.
I hope I am making myself clear. The request was triggered by
this post and my addition to it.