Oolite Bulletins

Hello!

I'd like to thank everybody for the help in learning how to 'tweak' to this point, and at this time I want to talk about some ideas I'd like to implement within Oolite. Obviously, I have no intention about just jumping in right away; I've got a lot of learning and practice before I'll be able to prepare anything that could be considered an OXP good enough to share with others. The idea is to create a long-range goal to shoot for: learn to write this kind of script, flowchart it out in this manner, etc.

I'm hampered by the fact that I have no knowledge about coding or JavaScript at all; the limit of my ability at this point is to look at a script's numbers and be able to make a rough guesstimate about what would happen if I changed it. Therefore, learning how to code is going to be on my list of things to do. Yikes.

So what I'd like to do here, if you'll permit me, is to describe the ideas I'd be interested in working on - one idea at a time. I'll give my thoughts on how I think it would go; you can let me know if it's doable, can be done within my ability (i.e. as a learning project) and if it's dumb.

Idea 1: Class-C Airspace
Admittedly, not many people would likely enjoy this one, I think most people probably just hold down 'I' upon launch and boom away, but given the way the Ooniverse is structured, it would make sense and as a real-life pilot, it would add the familiar feeling of control around airports. The main stations can basically be considered the analogue of modern-day international airports, and those are heavily regulated. My proposal is to add airspace restrictions around the main stations (additional stations would be unaffected), above and beyond the gravity restrictions they currently have. These are: hyperspeed and Witchspace prevention for a set distance around the station (I'm imagining 50Km), speed limits for spacecraft within the airspace (I'm thinking 300kps.), fines for speeding and other unlawful behaviour, and increased planning ability to account for the extra difficulty. I imagine this addon would be a good starting point for me, because parts of it seem to be quite easy to build, with increasing difficulty as each step is prepared. To wit:
Step 1: Hyperspeed and Witchspace restrictions: This is probably very easy; just a rewrite of the current masslock restrictions of the existing main stations. The Wildships stations have this already in effect; there is neither hyper nor jump within 25km. As such, it's a good place to start.

Step 2: Airspace speed limits: All spacecraft - NPC and player - are limited by law to a set speed (I'm thinking 300kms. @ 25kms radius) No probs for a Python unless he fires his injectors, a Planet Express might be surprised if he's not paying attention. I have no idea how to implement this; I imagine it will be a good project for coding practice, if it's not too difficult - I'm assuming it would involve creating and including an AI script. I hope you can tell me if it's possible, challenging or easy. I also imagine adding sound files: ATC broadcasts. ("Approaching ship; this is a station, not a racetrack. You've been fined.") Note: the speed limit extends to a smaller sphere than the hyperspeed restrictions, so the ship has time to slow from masslock before getting fined.

Step 3: Fines for unlawful behaviour. No application for NPC ships of course, but YOU can get nailed. I've no idea at all how that would work, so it'll be another good learning opportunity, if it's not too challenging - I've no idea at this stage. I'm imagining a fine of something like Fine=10*kts over speed limit. Stations have a fine if you dock without clearance, perhaps that script can be modified? I don't know yet. Edit: Since combat would be a strict no-no within station airspace, I think fines could be levied for popping bad guys as well, though that would limit a major source of idle amusement. I'm just having a mental image of an 'Offender'-status Python heading for uncontrolled space and sweating bullets while the player cruises right behind, lasers armed and an evil grin on his face...heh heh heh

Additional consideration: Increased planning: Of course, the first task upon launch is to look around for Witchspace wormholes, to see if anyone's heading your way. The restricted airspace would prevent that, so I imagine adding to the existing station's Traffic Control available on the F4 screen (available via OXP) information including a departing ship's destination. The idea would go like this: You've loaded up and are ready to head out. Look up the launching ships. The next two are going in the wrong direction, but the Python departing in 30 minutes shares your destination. So head on up to the bar, have a drink, maybe wander around the museum, then take off just before the Python and follow him out. Since TC is an OXP, this would require the creator of that mod to agree to make those changes - which is, of course, entirely up to him. Still, if he likes the idea, he might agree.

TheOldGamer wrote:

I think most people probably just hold down 'I' upon launch and boom away...

Perish the thought - every drop of fuel is precious!

TheOldGamer wrote:

Hyperspeed and Witchspace restrictions

Both are core features, need tricks to manipulate from an OXP.

Masslock is always happen within 25.6km from an entity except with scan_class buoy, cargo, mine, no draw or rock. (Planets and Sun is another story.) In my [wiki]VariableMasslock[/wiki] I change and restore the scan_class of all ships in player's scanner to avoid masslock a while, and also before asteroids to force masslock.

Your idea for extended masslock range around the station need to create and keep a mini entity somewhere in player's scanner range (with netural masslocking scan_class which is the default). For example check the player's distance from all system.stations in a frame callback function or in a 0.25s timer (checking only 4 times in a second instead of in every frame so 60 times can save much cpu power), like this: Hyperjump prevention is based on mass of entities in the scanner. Stations in Wildships are so large, this is the reason of large mass and radius of no jump zone.

The following lines in a Config/shipdata-overrides.plist file can deny the jump around coriolis stations by increasing the mass 1000 times: As you will see this is enough only to 25.6km and further increase is pointless due to jump is always enabled over this distance, regardless of the mass.
So you must use the same trick as above for masslock: create an entity with extreme density or at least enough high size/distance ratio, this will deny hyperjump also.

Speed limit can be fixed without chance to step over: Just set these back when step out of restricted zone.

This remind the player to do not waste fuel: Traffic Control interface is in phkb's [wiki]Station Dock Control[/wiki] OXP which is already display destinations if available using a well polished formula. Moreover if you press enter on a ship then you can select "Request launch before this ship".

For deeper immersion in your last idea install [wiki]Life In The Frontier[/wiki], where you can Disembark (in F4), go to the Local Bar, then to the Museum, meantime watch your wacth in your real-life arm and embark into your ship just before the time to launch.

Excellent - thanks! I hadn't actually started looking for the masslock parameters yet; I'd assumed there would be a line somewhere saying something to the effect of "Masslock range = 12" or something. So if I'm understanding you correctly, the idea is basically to create a hypermassive neutronium baseball floating somewhere around the player's ship? (Note to station manager: Zero-G mud-wrestling is cancelled for the duration of ship launching procedures...)

Norby wrote:

Traffic Control interface is in phkb's [wiki]Station Dock Control[/wiki] OXP which is already display destinations if available using a well polished formula. Moreover if you press enter on a ship then you can select "Request launch before this ship".

Oh! I have Station Dock Control, or at least I thought I did, that was the OXP I was referring to - I didn't see those functions you mentioned; I'll have to look again. If so, brilliant!

Norby wrote:

For deeper immersion in your last idea install [wiki]Life In The Frontier[/wiki], where you can Disembark (in F4), go to the Local Bar, then to the Museum, meantime watch your wacth in your real-life arm and embark into your ship just before the time to launch.

Yes; that was exactly the bar I was referring to; I've wobbled down to the hospital for a pre-launch detox many times after buying rounds in that dive.

Thanks for the help; I'm not really even at the flowcharting stage yet, there's a lot I need to learn how to do before I attempt it. I intend to take this slow, do it bit by bit, maybe try a few other alterations that require simple coding and learn as much as I can. To be honest, I've never given much thought to learning how to code but I'm curious to learn. This sounds like a terrific opportunity.

TheOldGamer wrote:

create a hypermassive neutronium baseball floating somewhere around the player's ship

The best if placed within the player's ship and disable collision check: To keep always within you must move with the player in every frame: Good luck and feel free to ask!

Norby wrote:

TheOldGamer wrote:

create a hypermassive neutronium baseball floating somewhere around the player's ship

The best if placed within the player's ship and disable collision check:

Code: Select all

var dataKey = "missile"; //or any small model
var this._blocker = system.addShips("["+dataKey+"]", 1, player.ship.position, 0)[0]; 
this._blocker.addCollisionException(player.ship);

To keep always within you must move with the player in every frame:

Code: Select all

this._blocker.position = player.ship.position;

Good luck and feel free to ask!

Thanks again; and just to let you know, my confusion regarding Station Dock Control was due to the fact I hadn't realized destinations are fairly rarely registered...and that there were multiple pages. Doh! That's very, very good - if I can actually build this thing it might, I hope, really enhance station operations.
Cheers!

I myself thought about 2). I'm not sure I like all of the rest. I mention it because sometimes OXPs implement too much things at a time. If it makes sense, please consider make each step a separate OXP.

Back to 2). I think the main problem is that players don't know their exact speed unless they are using something like numeric HUD. To solve this problem, I think one can do something like this:
- define two zones: inner Aegis space and outer Aegis space. Inner Aegis space should correspond to when the station is in beam laser range, for instance.
- when in the outer Aegis space and over the speed limit, the ATC emits a reminder about speed limits
- when in the inner Aegis space and over the speed limit, the ATC takes action (fines the player for instance)
Speed should be checked every about ten seconds, so that the player doesn't get spammed with warning or fines.

I might give a try at implementing it myself.

For a bit more challenge you can try to make a popup message like [wiki]Snoopers[/wiki] near the station:
use a function call of [wiki]Cabal Common Library Doc Overlay[/wiki] to display this in the top right corner:



Spoiler:[/size]

Hi Norby, thanks so much for the great response. I'd forgotten that a standard HUD doesn't have a ship's speed on it; I have Combat MFD up all the time which does. That would be a problem for a Jameson until he can earn enough to buy Combat MFD. I think you're spot on regarding the separate headings as separate OXP's; would that be easier to implement than my original idea (Release...say...the speed limits first, then other factors in later releases)? It looks at this point like a 50km masslock restriction is impossible, which kind of renders the rest of it pointless - but this can still serve as a learning exercise.

Also, you said you liked #2 as a possibility, but not the others. Would you mind saying why you don't like the other possibilities? I would appreciate the viewpoint from an experienced designer's perspective - i.e. too difficult to implement, too weird, etc.
Love the speed limit sign; I hadn't thought that would be possible, you've shown otherwise, thanks!

Thanks for all the help and suggestions folks; this is almost as much fun as playing the bloody thing.

TheOldGamer wrote:

...this is almost as much fun as playing the bloody thing.

Thankfully this sounds like a relatively mild case of Darkside Syndrome. It isn't fully established yet so with treatment there is a good chance the patient could still go into remission and make a full recovery.

TheOldGamer wrote:

Hi Norby [...]

Also, you said you liked #2 as a possibility, but not the others. Would you mind saying why you don't like the other possibilities? I would appreciate the viewpoint from an experienced designer's perspective - i.e. too difficult to implement, too weird, etc.

Unfortunately that was just Astrobe talking, not Norby .

You can mostly ignore this remark though, because I mostly misread your 1) and 3). However currently NPCs can jump near the station; sometimes I find 2 or 3 wormholes near the buoy. So the implementation of 1) should also prevent NPCs from jumping.

One radical way to solve this would be to allow jumps only near the witchpoint, but it would require to alter NPC AIs globally, and more importantly, it has significantly alters the gameplay.

Astrobe wrote:

Unfortunately that was just Astrobe talking, not Norby

Whoops, sorry! I misread the names! (Facepalm)