Scripting requests

[another_commander]

I am not sure it is really needed in oolite-global-prefix.js. This is a new method, not an inherited from previous versions one, so there is no need to make it compatible with the object classification of previous versions.

[Cmd. Cheyd]

I suggest expanding the following command: %Jxxx

Will display the system name of system with ID number "xxx". xxx must be a 3 digit number or no replacement takes place. e.g. %J007 is Lave (in Galaxy 1, that is)

... to a four-digit number %Jyxxx in which the y (0-7) stands for the galaxy or sector the system is in.

That way, trans-galactic missions can be displayed correctly by using the above command and use the new "1.73" trunk feature of also depicting oxp-altered planet/system names.

Unrelated project, but I second this one... It would be VERY, VERY helpful currently. That way, I can exclude Famous Planets, and other OXP modified systems from being altered without excluding all Planet#xxx in all 8 galaxies.

[Frame]

I have written a station.playerDock() javascript function

namely

Code: Select all

station.dockPlayer()

This would make OXP writers have more freedom, and certainly speed up testing...

function for OXPs.

I was PM'ed about the issue about Big Ships Docking(similar to save anywhere). But that would be problematic, because of the size of the ships, any part of the ship intersecting the the station model itself, will prevent a normal docking operation.. and then there is the matter about station rotating...

So I figured that a way to get around this was to force the ship to dock.. via a javascript command, we already do this with shift+d, and when using the escape pod...

The code taught me a thing or two about the Java script interface, I omitted checks for fines and offence dock denials, as I Thought, that this should be the OXP makers sole decision whether he want fines or denials to be dealt out..

We allready got player.ship.launch(), so we should really have the oppersite..

Using the station instead of the player.ship also eliminates checks by the hard code or the java script, whether or not the station exits, since if it does not, the following can never be executed.

anyway here is my suggestion, on a silver plate, as usual , i based this on SVN 2268

In file OOJSStation.m

First in the #import section

Code: Select all

#import "OOJSPlayer.h"

I have successfully build a version of Oolite with these changes... and been forced docked, by entering the command in the debug console...
and there has been no crashes.

There is also no range checks.. again, that should be handled by the OXP writer...

So we can handle the player


Then the prototype function

Code: Select all

static JSBool dockPlayer(JSContext *context, JSObject *this, uintN argc, jsval *argv, jsval *outResult);

The info for the method section , this would be the first method for a station

Code: Select all

// JS name					Function					min args
	{ "dockPlayer", dockPlayer, 0},

finally the function docking the player itsself

Code: Select all

//dockPlayer()
static JSBool dockPlayer(JSContext *context, JSObject *this, uintN argc, jsval *argv, jsval *outResult)
{
	PlayerEntity			*player = OOPlayerForScripting();	
	if ([player isDocked])
	{	
		return YES; //fail silently 
	}
	
	StationEntity *jsstationEntity = nil;
	
	JSStationGetStationEntity(context, this, &jsstationEntity);
	
#ifdef DOCKING_CLEARANCE_ENABLED

	[OOPlayerForScripting() setDockingClearanceStatus:DOCKING_CLEARANCE_STATUS_GRANTED];
#endif		

	[player safeAllMissiles];
	[UNIVERSE setViewDirection:VIEW_FORWARD];
	[player enterDock:jsstationEntity];	
	return YES;
}

I hope this can be included...

Cheers Frame..

[Commander McLane]

I always felt that Thargoids being auto present was a bit cheesy , especially since we can force mis-jumps by rolling the ship now.

We could do that in C64-Elite in 1984, and Thargoids were always there, so I don't see your point here. Thargoids are populating the interstellar space. Wether you arrive by an "accidental" or a "forced" witchjump doesn't matter.

[Frame]

I always felt that Thargoids being auto present was a bit cheesy , especially since we can force mis-jumps by rolling the ship now.

We could do that in C64-Elite in 1984, and Thargoids were always there, so I don't see your point here. Thargoids are populating the interstellar space. whether you arrive by an "accidental" or a "forced" witch jump doesn't matter.

I know now, but not then. although I have some faint memory of maybe have discovered it, and I bet so did'nt many other people who played it.

[Eric Walch]

I have successfully build a version of Oolite with these changes... and been forced docked, by entering the command in the debug console...
and there has been no crashes.

One thing is missing in your code and that is a size check. When manually docking that occurs automatic by collision detection, but now you should compare docksize with player ship. If it does not fit: kaboom! (Or just a beep that this station can't occupy the player)
Without the check you can get the unrealistic situation that you dock somewhere were the player physically does not fit.

When an oxp does something unrealistic you can always blame that oxp, but the core game should keep physics in mind.

[Lestradae]

One thing is missing in your code and that is a size check. When manually docking that occurs automatic by collision detection, but now you should compare docksize with player ship. If it does not fit: kaboom! (Or just a beep that this station can't occupy the player)
Without the check you can get the unrealistic situation that you dock somewhere were the player physically does not fit.

The size check wouldn't make a lot of sense if you i.e. attempted to give player bigships a way of docking.

The OSE solution would be that these ships have a Transfer Shuttle as equipment item on board (which could perhaps be made buyable for other big ships too, like Anacondas etc.) so that the player is supposed to dock (and launch to his bigship) via the Transfer Shuttle.

As the player basically is his ship in Oolite, this would be a viable workaround imho.



L

[Eric Walch]

As of SVN2267, we have scriptable misjumps. The new read/write JavaScript boolean property player.ship.scriptedMisjump has been added. As long as this is set to true the player ship will be executing misjumps, so handle with care and make sure to reset it after having finished with it.

All these misjumps will make live difficult. So I thought: offer a solution simultaneously: the Witchspace analyser It is just a preliminary version now. Ill think about the details for a real release when 1.73 comes available.

[Frame]

I'm not so sure about the size check, why should it bother testing the size, when the code is told to dock the ship. this should be exactly like shift+d auto dock...

Sure it would look odd, but nobody is watching, and i'm only suggesting this so that we can write a javascript OXP thingi that make the illusion that we are docking via some shuttle or the like...

like this:When the ship is close a shuttle is launched/spawned whatever, at the player/ship, when it docks, the ship docks, sure the trigger of this shuttle would have to be worked upon, and triggerd somehow.. maybe with the ring entity, where the ship has to "park" and then the shuttle is spawned.. if the shuttle dies, then no dock, and the ship has to "repark" in order to spawn a new shuttle..

Once the ship leaves, its orientation and position is restored to where it was, when the shuttle ship docked. only oddity would be that the ship would have the launch speed...

I admit I have not tested with a really large ship, because as far as I can tell, the code shouldn't bother about sizes, but just dock the damn thing.. . of course i can be wrong

But i am going to test with an ixian battle thingi cruiser mesh... make a player ship of it,

and will then post with my findings... here...

EDIT 1

I made a player version of the Ixian BattleCruiser.. not a nice thing to launch in as it is 3-4 times the size of a coriolis station..

However with a energy supply of 1050, it survived the launch, after that i wrote a script that moved it away from the station, immideatly after launch, so that collision, would never be an issue... it least for the build in stations...

After that I docked it, using

system.mainStation.dockPlayer()
Using my custom 1.73 build, and there was no size issues for the next 10 docks.

So i'm not sure what Eric means about size check. since there would be no collision detection necessary in a forced dock.. , it just docks disregarding physical sizes...

Edit 2..

I just reread Erics post..

i must have been tired... I read it as it would go BOOM if i used the method i had written

Anyway, i got it confirmed, that a really large ship can dock using my method...

Shift+d would work too I suppose...(but deny dockage and auto fine), btw i never get fined anyway despite smashing up countless vipers just outside the station

[Cmd. Cheyd]

An array of random numbers between 0 and 99 that are always the same for a given system. Similar to system.pseudoRandom100 or system.pseudoRandom256, but instead of a single value, it's an array of 50-100 values from 0-99.

So you would have:
Lave: [78,12,3,87,2,58,38,...]
Diso: [69,85,0,9,42,...]

PLEASE?!?????? If I had this, it would solve the last hurdle I have for the code-portion of SysRedux 2.0.

(Edit: I'm at home now, and re-read what I wrote. It wasn't making complete sense. Hope it does now. Did I mention - Please??????)

[Eric Walch]

An array of random numbers between 0 and 99 that are always the same for a given system. Similar to system.pseudoRandom100 or system.pseudoRandom256, but instead of a single value, it's an array of 50-100 values from 0-99.

I don't know exactly why you need it, but I assume you could write a small random generator yourself and use oolites pseudoRandom100 as seed. That way you generate your own repeatable "random" numbers. redux is written in js so that addition should be no real problem.
e.g.:

Code: Select all

this.resetMyRandom = function() {this.seed = system.pseudoRandom100}

this.myRandom = function()
{
   this.seed = this.seed #(do some calculation with this.seed to change it)
  return this.seed
}

Every time you use this.myRandom() it will have a new repeatable value.

[Svengali]

Similar to system.pseudoRandom100 or system.pseudoRandom256, but instead of a single value, it's an array of 50-100 values from 0-99.

Why do you need this? Probably there's a easier (and not so ressource hungry) way.

I think progging games and plugIns/addOns is always the 'search for simplifications' - a wanted ignoring of things that are not obvious to the player to speed up the whole execution. Keeping an array in memory with 204800 elements is for sure not that category :-)

[Cmd. Cheyd]

I think I found code this morning that will work to create this. SysRedux 1.0 did things through sorting the systems into an array based on the ID. So every time you visited planet #57, no matter WHAT galaxy you were in, you'd get exactly the same results. I want it to work so that that visiting planet #57 will give you consistent results for G1, but different yet consistent results for G2, and again for G3, etc...

Didn't realize the array proposal would be THAT big. Not sure if I explained it wrong, or just didn't realize how huge it would be once implemented. As I've said before, I'm an infrastructure guy. This development stuff is NOT my forte.

Anyways, I found some code I can adulterate to my purpose, I think. I'll get to mess with it later today, and will let you know how it goes.

[Svengali]

So every time you visited planet #57, no matter WHAT galaxy you were in, you'd get exactly the same results. I want it to work so that that visiting planet #57 will give you consistent results for G1, but different yet consistent results for G2, and again for G3, etc...

Why not using an offset, or shifting the bits around based on galaxy number? Bitshifting is probably the fastest way (>> and <<).

Hope this helps :-)

[Cmd. Cheyd]

So every time you visited planet #57, no matter WHAT galaxy you were in, you'd get exactly the same results. I want it to work so that that visiting planet #57 will give you consistent results for G1, but different yet consistent results for G2, and again for G3, etc...

Why not using an offset, or shifting the bits around based on galaxy number? Bitshifting is probably the fastest way (>> and <<).

Hope this helps

Was that developer-speak, or a low-flying airplane?
You just went over my head. But again, I think I found something I can adulterate to my purposes. If you'd like to see the code, I can send it to ya... Just PM me an email address. Hell, I'd love it if someone who understands this stuff would take a look-see at it and see if I'm doing things the monstrously hard or Going-to-be-slower-than-Hell way.