Oolite Bulletins

Posted: **Tue Nov 26, 2013 2:47 pm**

I've decided to make my first foray over to the 'dark side' and just to be different, instead of starting with a custom ship OXP, I'd like to try my hand at altering some gameplay.

I'd like to change the nature of witchspace jumps by introducing an element of unreliability to jumping from system to system.

Ideally I'd like the reliability of a jump from System A to B to be affected by:

System tech level - lower tech levels are more unreliable
System government type - Anarchies are more unreliable than Corporate States
System GDP - Poor systems are more likely to cut corners on witchspace infrastructure maintenance = more unreliable
The system description - destinations that are 'beset by civil war' are more unreliable

Witchspace infrastructure unreliablility would manifest itself as a totally denied jump, a redirected jump (to a system different from that selected), a misjump or a redirected misjump (that in particular could be particularly disorientating for the player

)

I'd also like to be able to create a piece of purchable equipment that would display unreliable links on the long range chart (e.g. green for unreliable, red for blocked).

Another aspect to build in would be a mechanism for preventing NPC's from creating wormholes to blocked systems. (incidentally, can an NPC creaete a misjump wormhole without any intervention by the player?)

Obviously, this could have an adverse affect on mission OXPs so I'd also need to build in a way to disable unreliablility if a mission is in progress.

Unfortunately, I'm a noob at OXP authoring (although I have worked in IT for quite a few years and I've no problems with getting myself up to speed with JavaScript...).

I've walked through the tutorial for creating an uber version of the Cobra III (first time I've flown around at 1.000LM

), and I'm trawling through the OXP list to come up with a starting point for what I have in mind.

As a first draft, I'm envisioning the following:
I'm assuming that what I need is a script that fires when the player initiates a jump. The script would grab the current system and destination, and query an internal 'database' to calculate whether the destination is subject to unreliability. If the jump is deemed to be unreliable, then another function determines what type of unreliability is to be manifest, and the player jump is altered accordingly.

Any suggestion as to OXPs that could demonstrate something like what I want to achieve?

Cheers

Posted: **Tue Nov 26, 2013 3:32 pm**

And wouldn't you know it, about 20min after posting my cry for help I get a flash of inspiration - the Misjump Analyser looks to be a promising starting point for getting a look at how I can mechanically control the jump behaviour...

Even still, any other suggestions would be muchly appreciated

Posted: **Wed Nov 27, 2013 9:17 am**

To me, a blockade could also mean a guaranteed Thargoid ambush (misjump) going to a "blockaded" system.
Or it could mean a "warm welcome" by pirates at the blockaded system's witchspace beacon.

Galactic News might hint that certain systems have this problem and are best avoided for the faint-of-heart.

Posted: **Wed Nov 27, 2013 11:35 am**

Bugbear

This is a rather ambitious project! But / so: good luck! Also, my Interstellar Tweaks OXP (available from the wiki and directly here) might be of use to you.

Posted: **Wed Nov 27, 2013 11:38 am**

Switeck wrote:
To me, a blockade could also mean a guaranteed Thargoid ambush (misjump) going to a "blockaded" system.
Or it could mean a "warm welcome" by pirates at the blockaded system's witchspace beacon.

Oooh a "welcome party" - that's a good one. I'll add that to the wish list. Won't guarantee it for v1.0 but definitely worth planning for it.

Switeck wrote:
Galactic News might hint that certain systems have this problem and are best avoided for the faint-of-heart.

And another OXP tie-in - Snoopers...

Posted: **Wed Nov 27, 2013 12:52 pm**

Switeck wrote:
Or it could mean a "warm welcome" by pirates at the blockaded system's witchspace beacon.

This is already one of the features of the 'ExtraMayhem' plugin for my ToughGuys OXP. Around 1 in 10 systems will have a pirate blockade at the witchpoint. This will consist of at least five pirate ships, some of which could also have 'escorts', and there will also be a couple of Police ships on their way to the witchpoint which will liven things up a bit more when they arrive

Posted: **Wed Nov 27, 2013 1:51 pm**

My curse is that (sometimes) I read the instructions.

Having stumbled upon this, I see I have some bedtime reading

Seriously though, that's some great documentation guys

Posted: **Wed Nov 27, 2013 2:46 pm**

Bugbear wrote:
Having stumbled upon this, I see I have some bedtime reading

It gets worse

Posted: **Wed Nov 27, 2013 6:21 pm**

Hi Bugbear!

OXP making is very fun, I can encourage you to write a few line at a time then try it - you will stay motivated if you see your results often.

Please do not forget to put a license into your readme.txt, as Jens said here it is not optional. Imho CC-SA is the best, others more complicated, for example you can seal the fate of your work with a CC-ND when you missed.

Some consoleMessage will be helpful to inform the player why are so many attacker here. Use log("youroxp", "message"); to place debug messages into the Latest.log file - the capital Log() in the sample code of the wiki page you referred is drop an error and one parameter is not enough, need two to arrive into the log.

Please test your work with similar OXPs mentioned before and write some hint which is good to use in conjunction and declare conflicts if any - not only technical but logical also, for example if an ironed Cobra can not survive if ToughGuys installed.

You should make screenshots for your wiki page. I asked my wiki editor login from maik in PM, I guess you will get one also. Upload your zip file into a hosting service, edit the first post in the topic of your OXP to insert your screenshot, wiki and download links and send a new post to bring up the topic.

As you can see the additional work can be more than the programming part in a small OXP, but do not worry, it is worth to do for the many thanks what you can get in this forum.

Posted: **Mon Dec 02, 2013 1:36 pm**

Hey Norby, thanks for your pointers. Actually, we're thinking along the same track.

i actually have quite a lot of scripting experience (primarily VBScript but recently I've been getting up to speed with Powershell - pick the Windows Admin...). I don't see Javascript being much of a problem.

I'm breaking this whole process into manageable steps. Firstly, given the fact that the Linux file system is case sensitive, I figure it will be more 'strict' for me to develop on Linux rather than Windows (even though I do most of my piloting on Windows....)

Second, I need to work out how to log arbitrary messages to the log file (and this is where your advice has been most timely) - just getting my head around that function now.

<edit> Ahhhh, so I altered the script to say log( this.name, "My message..." ); then wondered why the Latest.log was still saying that the line commencing with Log... (note capitalisation) was throwing an error.

Now I understand why it's important to hold down <shift> when relaunching the game.

And so it begins...

Posted: **Mon Dec 02, 2013 3:04 pm**

Bugbear wrote:
Now I understand why it's important to hold down <shift> when relaunching the game.

First step on the road to becoming an OXPer: enable the

always-flush-cache setting.

Posted: **Mon Dec 02, 2013 3:28 pm**

Incidentally, is there a reason why the demo code I grabbed from here didn't work?

Code: Select all

this.name           = "My OXP Script"
this.author         = "Your Name Here"
this.copyright      = "(C) 2009 Me."
this.licence        = "CC-NC-by-SA 2.0"
this.description    = "This OXP doesn't do very much yet.";
this.version        = "1.0 alpha 1"

"use strict";

/*  You can copy and paste this function and just change the "startUp"
    to another event name to handle other OXP events (eg "STATUS_DOCKED",
    "alertConditionChanged", etc).
*/
this.startUp = function()
{
    Log("Initialising OXP " + name)
}

Here's the code that worked for me:

Code: Select all

this.name           = "Oolite Logging POC"
this.author         = "Bugbear"
this.copyright      = "(C) 2013 Bugbear."
this.licence        = "CC-NC-by-SA 2.0"
this.description    = "Proof of concept - testing out Oolite logging techniques.";
this.version        = "1.0 alpha 1"

"use strict";

/*  You can copy and paste this function and just change the "startUp"
    to another event name to handle other OXP events (eg "STATUS_DOCKED",
    "alertConditionChanged", etc).
*/
this.startUp = function()
{
    log( this.name, "Initialising OXP " + name);
}

Worth updaing the wiki?

Posted: **Mon Dec 02, 2013 3:39 pm**

Bugbear wrote:
Incidentally, is there a reason why the demo code I grabbed from here didn't work?

Your old friend, case-sensitivity (and deprecated syntax).

Code: Select all

    Log("Initialising OXP " + name)

is not the same as

Code: Select all

    log( this.name, "Initialising OXP " + name);

There was a time when Log(string) used to be a shortcut for log(identifier, string). But this was several Oolite versions ago, and this shortcut does no longer exist.

So yes, that one needs to be updated.

EDIT: Done.

Also, Bugbear: when looking up the syntax of JS-properties and -methods, you should always do it on the reference pages. That's everything listed in the

Category:Oolite_JavaScript_Reference. In this case, log is a method of the global object, thus http://wiki.alioth.net/index.php/Oolite ... ce:_Global is where you have to look.

Posted: **Wed Dec 04, 2013 12:30 pm**

Commander McLane wrote:
Bugbear wrote:
Now I understand why it's important to hold down <shift> when relaunching the game.
First step on the road to becoming an OXPer: enable the always-flush-cache setting.

Thanks for the tip. Always Flush Cache is now a permanent addition to my .GNUstepDefaults file on my dev Oolite instance.

Posted: **Wed Dec 11, 2013 1:10 pm**

OK so this project of mine is still active, I can only work on it for a handful of hours a week.

I'm still at a very early stage in my development plan - basically I'm exploring the Oolite Java Script API and attempting to write properties to the latest.log.

Something I'm looking at right now is the systemsInRange function. All I want to do is output some info on each system in range.

Here's the code that I'm using:

Code: Select all

// I've included my LogMsg function for completeness...
function LogMsg( strMsg )
{
	var blnDebug = true;
	if ( blnDebug )
	{
		log( this.name, strMsg );
	}
}

this.playerStartedJumpCountdown = function(type, seconds)
{
     var aSysInRange = system.info.systemsInRange();
     for ( oSys in aSysInRange )
     {
		 LogMsg( "========================================" );
		 LogMsg( "oSys: " + oSys );
		 LogMsg( "System ID: " + oSys.systemID );
		 LogMsg( "System coords: " + oSys.coordinates );
		 LogMsg( "System government: " + oSys.government );
		 
	 }
}

When I run this code against a fresh Jameson in Lave, I see the following written to the log:

Code: Select all

21:45:08.912 [undefined]: ========================================
21:45:08.912 [undefined]: oSys: 0
21:45:08.912 [undefined]: System ID: undefined
21:45:08.912 [undefined]: System coords: undefined
21:45:08.912 [undefined]: System government: undefined
21:45:08.912 [undefined]: ========================================
21:45:08.912 [undefined]: oSys: 1
21:45:08.912 [undefined]: System ID: undefined
21:45:08.912 [undefined]: System coords: undefined
21:45:08.913 [undefined]: System government: undefined
21:45:08.913 [undefined]: ========================================
21:45:08.913 [undefined]: oSys: 2
21:45:08.913 [undefined]: System ID: undefined
21:45:08.913 [undefined]: System coords: undefined
21:45:08.913 [undefined]: System government: undefined
21:45:08.913 [undefined]: ========================================
21:45:08.913 [undefined]: oSys: 3
21:45:08.913 [undefined]: System ID: undefined
21:45:08.913 [undefined]: System coords: undefined
21:45:08.913 [undefined]: System government: undefined
21:45:08.913 [undefined]: ========================================
21:45:08.914 [undefined]: oSys: 4
21:45:08.914 [undefined]: System ID: undefined
21:45:08.914 [undefined]: System coords: undefined
21:45:08.914 [undefined]: System government: undefined
21:45:08.914 [undefined]: ========================================
21:45:08.914 [undefined]: oSys: 5
21:45:08.914 [undefined]: System ID: undefined
21:45:08.914 [undefined]: System coords: undefined
21:45:08.914 [undefined]: System government: undefined

So the count of the systems is correct - there are 6 systems within 7LY of Lave but I'm obviously doing something wrong when connecting to the SystemInfo instances.

So what beginner error am I making here?

Oolite Bulletins

[WIP] Witchspace blockades

[WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades

Re: [WIP] Witchspace blockades