Oolite 2.0 or II

[Smivs]

...should the torus be disabled during red alerts?

Yes, definitely.

[Cody]

And within the aegis? Docking on torus is fun!

[tsoj]

Would it be useful maybe if we had a JS read/write property like player.ship.massLockable (accompanied by its sister shipdata.plist property mass_lockable, valid only for player ships) that just hands masslock control over fully to scripts?

Yes, i think that would make it easier to script these kind of things.

[another_commander]

...should the torus be disabled during red alerts?

Yes, definitely.

I've set up something very experimental based on the earlier description of the "massLockable" property and it seems to work, although of course more testing is needed. I understand that this is where the scalpel goes deep (a bit too deep maybe). I can make it so that mass lock is forced when in red alert, but I am thinking that if we were to hand over control to scripting for this, might as well do it fully and let scripts handle however they wish the red alert case.

I will commit the experiment in a while and hopefully it should be in tomorrow's nightly for (a lot of) testing.

And within the aegis? Docking on torus is fun!

Yup, that too. Just did it for kicks.

[Cody]

Docking at a Torus on Torus? Way to go!

[tsoj]

The solution is simple. Add a key press time accelerator. A core feature that accelerates game engine time while pushing a single key. The major benefits of which follow:

1. Speeds you through uneventful mass locks
2. Speeds you through docking delays
3. Benefits all players since you do not need an OXP or equipment to use it.
4. Doesn't affect any core mechanics or NPC interactions. The game is basically the same except you can speed up the boring parts.
5. Should be easy to implement. I noticed a time control OXP that requires developer version, so I assume mechanics are currently available in developer version.
6. Would make the game way more FUN.

You need the Trunk-version ( v1.85 ):
https://app.box.com/s/dw1fd8jourbgbphvt2z0zxveuft2lahz

You need to buy the equipment "Timewarp Machine", you have to make it the primable equipment ( "N" ) and then you can activate and deavtivate it with "n". Note that if youre timewarping you cant steer your ship ( it would have to high sensitivity to control your vehicle savely ).

EDIT:
It only provides a simplier access to the TAF ( TimeAccelerationFactor ). You can edit it manually ingame if you pause the game and now you can increase or decrease gametime-speed with your arrow keys ( if you want to know at which gametime-speed your currently are you can press "F" to see the information ).

[LSD 425]

With all due respect tsoj. I believe you missed the point. Which is that the stock game is currently frustrating for new players. Right now my character is well off and as such has docking computers, military injectors etc, I've added some dockalbes for extra fuel ups etc... and I know enough to skip the lane if I want. Hence I will check out your oxp when I get around to installing the developer version.

My point was that the game as is, in a vanilla install can be frustrating for NEW players. Maybe this could be a focus if the developers want to make an over haul for a version 2.



In regards to adjustable contracts/bounties.
The fact is that for a new player it is quickly obvious that it makes way more sense to load up a COBRA III and bounce back and forth between two good planets until you can afford a few upgrades to make any other kind of runs. In fact my current character is getting offered 90% of passenger contracts and it is barely even close to what i could make trading per jump.

Making these values adjustable (or just higher to start) would allow a player to start right off the bat on to a career path of choosing. Rather than be forced into being a full time trader to make some profit.

As for bounties. Combat can be expensive, particularly for a new player. Damaged gear, Escape pods and maintenance overhauls can eat into any profit quite quickly. Increasing them allows a player to buy a fighter craft and focus on a combat style game right from the beginning.


Again these ideas are not suggestions for me. I can hack or install what ever I want at this point. These are suggestions to make the game more pallet-able and friendly for other NEW players. And the suggestions would not ruin the core experience for anyone else.

BTW I love how modable and extendible the game already is. I'm off to tweak the alpha ratings on the Xenon HUD I installed as well as bump those fugitive bounties even higher. Bring on the offenders... Wee....

[Cody]

425 µg?

[Cody]

I will commit the experiment in a while and hopefully it should be in tomorrow's nightly for (a lot of) testing.

Instructions for a dumb pilot, por favor? Something to do with mass_lockable = no; is it?

[Redspear]

I think the greatest thing about Oolite is that each individual can create and play the game any way they choose rather than playing a game someone else chooses for them.

Yes indeed...

The thing is, Masslock makes sense. Mostly to avoid collisions. So there is a case to say everything should Masslock you. But yes it can get tedious, so why not just be able to re-engage torus Drive if you want to once you've been Masslocked. Have it as an automatic safety system that can be manually cancelled after activation.

Again, I agree. Norby's variable masslock and my aforementioned tweak include this feature (in case anyone was unaware...)

I've set up something very experimental based on the earlier description of the "massLockable" property and it seems to work, although of course more testing is needed. I understand that this is where the scalpel goes deep (a bit too deep maybe). I can make it so that mass lock is forced when in red alert, but I am thinking that if we were to hand over control to scripting for this, might as well do it fully and let scripts handle however they wish the red alert case.

I will commit the experiment in a while and hopefully it should be in tomorrow's nightly for (a lot of) testing.

Thanks!

Personally, I think combining ship role with target heading as discriminating factors could create a mass-lock model with a flavour very much like the original elite and yet without sacrificing any of oolite's non-player centric elements.
The former reduces the effect of the most tedious masslocks (already tested in my tweak) and the latter would remove the need to avoid/overtake peaceful ships headed in the same direction (and the whole issue of slow player ships being less playable).

[Stormrider]

I've set up something very experimental based on the earlier description of the "massLockable" property and it seems to work, although of course more testing is needed. I understand that this is where the scalpel goes deep (a bit too deep maybe). I can make it so that mass lock is forced when in red alert, but I am thinking that if we were to hand over control to scripting for this, might as well do it fully and let scripts handle however they wish the red alert case.

Thanks A_C, I would like to see mass lock fully controllable even under red alert this would allow authors to experiment with other methods of handling mass lock with disruptors and whatnot.

425 µg?

I believe Ken recommended 500.

[another_commander]

Instructions for a dumb pilot, por favor? Something to do with mass_lockable = no; is it?

Yes, that is correct. You want to have this line somewhere in your player ship's shipdata entry, although I believe it is much more efficient to test with the debug console and player.ship.massLockable = true/false; so that you can change masslockable status on the fly. In the absense of console, the above line will be fine but to change the property you will need to exit the game, edit the line and restart it.

When massLockable is false, yellow alert is to all intents and purposes removed from the game (yellow alert is basically the presence of mass lock as far as the game logic is concerned). You can move wherever you want in full torus speeds, without restricitions and, if attacked or approach planet/sun etc., the alert status goes straight to red. Switching massLockable to true again will re-instate the standard gameplay mechanic and if you are in the presence of mass-locking entities, you will go straight to at least yellow alert and torus, if active, will cut-off as expected.

Personally, I think combining ship role with target heading as discriminating factors could create a mass-lock model with a flavour very much like the original elite and yet without sacrificing any of oolite's non-player centric elements.

Theoretically, you should now be able to create any preferred mass lock model from within Javascript.

I would like to see mass lock fully controllable even under red alert this would allow authors to experiment with other methods of handling mass lock with disruptors and whatnot.

As per above, this is indeed the case. Mass lock (and responsibility of its use) is completely under script control, if so desired. There are no core restrictions whenever a script proceeds to cancel masslocking. And, of course, if no scripts touch the mass lock model as set up by default, there should be no changes to the current gameplay at all.

[Cody]

You want to have this line somewhere in your player ship's shipdata entry...

Having mass_lockable = no; in my player-ship's shipdata.plist doesn't seem to work (nightly 98f6ceb).
Tried it in the core shipdata.plist too (with a virgin Jameson) - no joy. Is it me again?

[Stormrider]

Tried it in the core shipdata.plist too (with a virgin Jameson) - no joy. Is it me again?

I'm not having any luck with it either. same nightly.

[another_commander]

Tried it in the core shipdata.plist too (with a virgin Jameson) - no joy. Is it me again?

I'm not having any luck with it either. same nightly.

Nope, it was me. But hopefully now fixed for the next nightly.