Tinkerer's Workshop - OXP tweaking for fun and profit!

[Cody]

This is a testing tool, and not a cheat that should be used for normal gameplay.

<chortles> Once it's out in the wild, it will be used - for whatever reason.
For a long-range tester, I give that commander a few hundred ly of fuel - that too gets across the chart PDQ!

[Smivs]

This is a testing tool, and not a cheat that should be used for normal gameplay.

<chortles> Once it's out in the wild, it will be used - for whatever reason.

I know, I know. What have I done!

[Diziet Sma]

N.B. This is a testing tool, and not a cheat that should be used for normal gameplay.

That's odd.. I coulda swore I heard somebody say:

(And, NO! I won't be releasing the OXP anytime soon)

Well.. posting it here is very nearly the same thing..

Ah well.. it's "in the wild" now.. for good or ill.. (remember kiddies.. do as Daddy says, not as Daddy does.. )

Though seriously, thanks, Smivs.. I'm sure it will come in handy at some point.

[another_commander]

I have been chatting to Dizzie over at my 'OXPs and 1.80' thread and the subject of my test ship came up.
When you are testing it is sometimes helpful to be be to cover vast distances in a short time, so my Contractor test ship has Magic Fuel Tanks which re-fill after every witchjump, thus avoiding the need to waste time re-fuelling. This is accomplished with a simple script that some of you might find helpful.

Code: Select all

"use strict"

// Standard attributes 
this.name           = "fuelCheatScript.js"; 
this.author         = "Smivs"; 
this.copyright      = "This script is hereby placed in the public domain."; 
this.version        = "1.0"; 
this.description    = "Script for 'cheat' fuel refill.";

{
this.shipExitedWitchspace = function()
 {
  player.ship.fuel += 7.0;
 }
}

Simply name this 'script.js' (without the quote marks) and place it in your AddOns folder.
N.B. This is a testing tool, and not a cheat that should be used for normal gameplay.

Rather than filling up the AddOns folder with various script.js files for doing different things, would it not be easier to just have the debug console active and connected to Oolite when testing and simply do a

Code: Select all

PS.fuel=7

whenever you need a fill-up?

I believe every OXPer would make excellent use of their time familiarizing themselves with the debug console; it can do everything that can be done with a script, only faster and probably with better control when it comes to testing.

[Neelix]

Rather than filling up the AddOns folder with various script.js files for doing different things, would it not be easier to just have the debug console active and connected to Oolite when testing and simply do a

Code: Select all

PS.fuel=7

whenever you need a fill-up?

I believe every OXPer would make excellent use of their time familiarizing themselves with the debug console; it can do everything that can be done with a script, only faster and probably with better control when it comes to testing.

I have to agree with this. between the debug console and cim's build scripts, putting my first OXP together was a lot easier than I'd expected.

The debug console and the documentation in the wiki let me experiment with the Oolite's javascript interface, which let me quickly learn how the manifest object works. I then knew what my code needed to do, so actually writing the code was pretty straightforward.

Cim's build scripts made troubleshooting a breeze! Edit the files, run the script, start Oolite and test, repeat until it stops throwing exceptions... The debug console also turned out to be very useful here too, because every time an exception was thrown the console would tell me a line number, which provided a good pointer in terms of where to look for the issue.

- Neelix

[Tricky]

Positioning the message and communication log windows.

I use the following in a hud.plist file placed in AddOns/Config

The comments for x and y help to explain how to work out the values. If x_origin is negative then x is positive. If x_origin is positive then x is negative. This is the same for y_origin and y

border inset is the amout of padding from the edge of the screen to the edge of the message/comm log window.

Code: Select all

{
	/* Top left. */
	message_gui =
	{
		alpha = 0.75;
		width = 400;
		height = 80;
		x_origin = -1;
		y_origin = 1;
		x = 210;	// Half the width + border inset of 10
		y = -50;	// -(Half the height + border inset of 10)
		row_height = 10;
	};

	/* Top right. */
	comm_log_gui =
	{
		alpha = 0.75;
		width = 240;
		height = 120;
		x_origin = 1;
		y_origin = 1;
		x = -130;	// -(Half the width + border inset of 10)
		y = -70;	// -(Half the height + border inset of 10)
		row_height = 10;
		permanent = no;
		automatic = yes;
		background_rgba = "0.0 0.05 0.45 0.5";
	};

	multi_function_displays = ({
		/* Top left under message_gui. */
		width = 240;
		height = 132;
		x = 130;	// Half the width + border inset of 10
		y = -166;	// -(Half the height + border inset of 10 + message_gui.height + 10)
		x_origin = -1;
		y_origin = 1;
		row_height = 10;
	},
	{
		/* Top right under comm_log_gui. */
		width = 240;
		height = 132;
		x = -130;	// -(Half the width + border inset of 10)
		y = -206;	// -(Half the height + border inset of 10 + comm_log_gui.height + 10)
		x_origin = 1;
		y_origin = 1;
		row_height = 10;
	});
}

[Redspear]

Thanks Tricky, I think I'll be using that one

The nice, clear heading to your post makes me think that a thread like this one could really do with an index...

I've got a post on the first page of this thread that I'd be happy to turn into an index (if no one objects?)
The more postings there are here, the more good stuff is going to get buried... hopefully by even more good stuff

I'll see if I can set up an example of what I mean (with links to relevant posts) and then if there are objections (or if someone has a better idea) I can edit or remove it.

[Zireael]

Go ahead and make an index!

[Redspear]

Go ahead and make an index!

Beginnings of an index started on first page of this thread.

Rather than finish it all now, I thought I'd just make a start and then it could be open to criticism.
If folks are happy with it then I will continue.

[Diziet Sma]

Thanks very much for taking this project on, Redspear.. excellent idea!

[Redspear]

Very happy to help

[Twisp]

I have a request for a tweak, if anyone would like to take a look at it. It has to do with Pirate Coves. While I enjoy how the OXP implements them, I've always had a consistent issue with them appearing far too often and in far too great numbers in high-security, high-tl systems. Ideally, I'd like to limit their spawning to the lowest forms of government, namely Feudal and Anarchy systems.

I have a loose idea about how to do it, gained as I slowly learn my way around oolite scripting, but every attempt I've made at it so far has produced either inconsistent or nonfunctional results. So, if anyone would like to create a tweak which would limit the spawning of Coves to Feudal and Anarchy systems, I'd appreciate it greatly as both a benefit to my playing experience and as something I could learn from. Thanks in advance!

[DGill]

cim's system feature rings is excellent but prefer to have the rings on an additional planet rather the main one.

I changed in systemfeatures-ring.js and systemfeatures-rings.js all occurrences of system.mainPlanet. with system.planets[1].

and replaced in systemfeatures-rings.js (vrs 1.2) lines 7 - 22 with:

this.shipWillExitWitchspace = this.shipWillLaunchFromStation = function()
{
if (system.isInterstellarSpace || system.sun.hasGoneNova) {
return;
}
var j = 0;
j = system.planets.length
if (j > 3) {
this._addRing();
return;
}
}

[Redspear]

cim's system feature rings is excellent but prefer to have the rings on an additional planet rather the main one.

That sounds... AWESOME
I'm definately trying that one out. Thanks DGill

[mossfoot]

I'm curious to tweak this as well, but can the frequency be upped a bit? I'd like to assume 1 in 10 outer planets has a ring, for example