Scripters cove

Discussion and information relevant to creating special missions, new ships, skins etc.

Moderators: another_commander, winston

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 »

docwild wrote:Is there a way to switch which dictionary entry applies to an existing object on the fly?
No.
docwild wrote:If not, what is the effect of removing and replacing an entity which the player is docked at?
Probably quite messy.
docwild wrote:Finally, I'm sure I read somewhere that it's possible, using the debug OXP and jScript console, to reload a worldscript on the fly. I can call the startup method which restarts the script already in memory, but is it possible to edit the script, and reload from within the game using the python debug console on linux?
Nope. You can, however, change the script’s handlers in memory:

Code: Select all

worldScripts["foo"].doSomething = function() { new code; }
Obviously you’d need to make corresponding changes in the file as well if you want them to stick.

User avatar
Arexack_Heretic
Dangerous Subversive Element
Dangerous Subversive Element
Posts: 1878
Joined: Tue Jun 07, 2005 7:32 pm
Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
Contact:

Post by Arexack_Heretic »

Ahruman wrote:No, no, no!
Ah, I see. One needs to use this:

Code: Select all

<key>script_info</key>
<dict>
   <key>myCustomProperty</key>
   <string>0</string>
</dict>
Riding the Rocket!

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

Post by Thargoid »

docwild wrote:Is there a way to switch which dictionary entry applies to an existing object on the fly? If not, what is the effect of removing and replacing an entity which the player is docked at? I could use the shipWillDockWithStation () handler to switch before the ship docks or is it possible to create a station, switch the player to it before removing the original? Can it be switched during the shipWillLaunchFromStation() handler. I know there is a dockPlayer method (or something like that) but does it immediately dock the player or does it engage autopilot docking to said station?
If a station is destroyed whilst a player is docked in it then the player is automatically launched iirc. So presumably if it is script-removed the same would apply. Hence as soon as you try you'd possibly end up sat outside the new version of your station.

dockPlayer does just that - displays the docking rings and then the status screen. Basically the same as insta-docking (shift-D by standard keyboard mapping) when within the main station aegis (but can be used with any dockable entity). So probably not quite what you're looking for (a few extra ring sequences).

Looking at the trunk logs there may be a way to do this in 1.75 (something I plan to check when I get chance), but as a follow-up question, is there any reason the beacon code has to be read-only and not read-write settable (and removable) from script?

Editted to add - scratch the 1.75 thing, didn't work (beacons on sub-entites don't show up on the ASC).

User avatar
Svengali
---- E L I T E ----
---- E L I T E ----
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

Post by Svengali »

Why not simply launching a buoy with beacon code then?

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 »

Svengali wrote:Why not simply launching a buoy with beacon code then?
Yes, the GRC company faces bankruptcy because of the few buoys we can replace since introduction of 1.73. :lol: We need other sources to sell our buoys.

Look at the rock hermit locator. That one replaces buoys on the fly when the equipment gets damaged. That way all beacons are removed.

User avatar
docwild
Dangerous
Dangerous
Posts: 64
Joined: Thu Mar 29, 2007 1:36 pm

Post by docwild »

You know, I hadn't considered buoys. Doh.

I'm sure there is a lot I'm doing which is misguided, but that's how you learn I guess.

User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

Thargoid wrote:as a follow-up question, is there any reason the beacon code has to be read-only and not read-write settable (and removable) from script?
As far as I know, it's the same reason that you cannot select/deselect specific missiles, or change player speed from script: the player needs to be - at least nominally - in control of its ship. If you play around with these things via script, the feeling of being in control tends to disappear fairly quickly... I wasn't around at the time, but I've got the feeling it probably was a bit touch and go for a while over making player.ship position & orientation modifiable by script...
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)

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

Post by Thargoid »

Eh? How does being able to turn the broadcast beacon on and off on an NPC entity affect the player ship? Especially given it can be worked around by removing and replacing an entity to do it in a rather messy fashion?

User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

Maybe I misunderstood the question, but the beacon can be used (and I personally use it) in combat, and being able to switch it off at will does personally feel a step too far scriptwise... if the targeted entity is destroyed, and a similar one is put in its place, fair enough I suppose...
Not that I'm too confortable with the concept, mind.

If we consider the beacon display as a gps, changing the 'address' you want to go to under the player's feet does - again - feel like quite an underhand move too.

Physically destroying the 'address' and creating a new 'identical' one does at least reset the target, alerting the player that something is amiss... Anyway, these are my own personal opinions, don't really know what other devs think about it, etc... :)
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)

User avatar
docwild
Dangerous
Dangerous
Posts: 64
Joined: Thu Mar 29, 2007 1:36 pm

Post by docwild »

I tend to think of a beacon as a broadcast on a specific frequency, I can imagine that turning off the main station beacon via script would be a pain but perhaps a separate class of OXP beacons could be script controllable. At the moment it is fairly clunky, having to remove and replace entities on the fly to achieve the proper effect, making sure to store their stats (rotation, position, energy) before doing so. It isn't a vital thing nor is it particularly difficult to overcome, but it is one of those idiosyncrasies.

Code: Select all

this.updateBeacons = function ()
{
	if(this.playerClaimedMines.length > 0)
	{
		
		log(this.name, "UPDATEBEACONS");
		var mineEntity = system.shipsWithRole("slaveMine");
		//asteroids have been placed, now the owned ones need replacing
		for(var i = 0; i < mineEntity.length; i ++)
		{
			
			log(this.name, "updateBeacons: i = " + i);
			for(var n = 0; n < this.playerClaimedMines.length; n++)
			{
				var displayName = this.playerClaimedName[n];
				var position = Vector3D(this.playerClaimedPositions[n]);
				if(position.distanceTo(mineEntity[i].position) < 5)
				{
						//this is likely the one :P
						mineEntity[i].remove();
						var mineEntity2 = system.addShips("slaveMineOwned", 1, position, 1);
						if(mineEntity2)
						{
							mineEntity2[0].displayName = displayName;
							log(this.name, "replaced station n = " + n + " mineEntity2 = " + mineEntity2);
						}
						break;
				}
			}
		}
	}
}
Suggestions for improvement are welcomed. :D

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 »

A potential problem that’s been bothering me for some time is that there’s no distinction between custom properties/methods on scripts and ones used by Oolite. This means that any new event handlers might conflict with some OXP’s private methods.

I’d like to suggest a convention (not an enforced rule) to get around this: custom properties on script objects intended for internal use or as APIs for other scripts should be prefixed with dollar signs. For instance, in the built-in Nova mission script, this.endTheMission would become this.$endTheMission and this.cleanUp would become this.$cleanUp.

custom properties added to anything other than your own script objects should still have an OXP-specific prefix.

Unless someone has a particular objection against this, I’ll be updating the built-in scripts accordingly soon.

User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

Hmm, I'd use _ instead of $ as the suggested prefix for custom properties/methods myself.

The _ prefix is already fairly common for internal properties/methods, and the $ prefix is already fairly common - as far as js namespaces are concerned - to identify properties & methods from external libraries (jquery & prototype spring to mind).

Using $ for internal properties might well cause unnecessary confusion for any OXP maker already used to js... :)
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)

User avatar
docwild
Dangerous
Dangerous
Posts: 64
Joined: Thu Mar 29, 2007 1:36 pm

Post by docwild »

Plus: It would give me speccy BASIC flashbacks.

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 »

Underscores are used for a variety of identifiers with special meanings to the interpreter. Well, OK, double underscores. But single underscores lead to double underscores, and eventually someone will think __count__ is a good name for a private property, and then the universe will explode in their face.

OK, so I’m a bit paranoid about namespaces. Somebody has to be.

User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

Wait, if I understand the gist of what you're saying you'd rather confuse experienced js programmers because there's the remote possibility that non-js programmers could get confused by 'one _ at the front' and decide it actually means 'two _ at the front and two _ at the back', and - by pure chance - they come up with a name identical to an internal js property?

I'm happy to agree that someone confusing '_name' with '__name__' is a tiny bit more likely than confusing '$name' with '__name__', but either case is very, very unlikely, and would be 'a bit' of a stretch for them to say 'but Ahruman told me to write this property this way'.

And if the universe explodes because they use __count__ instead of the perfectly acceptable _count, well, they need to to take responsibility for their own actions.

I do think going against estabilished namespace practices is very counterintuitive, rather than paranoid, but hey, what do I know! :D
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)

Post Reply