Oolite Bulletins

Khem, @cim, @a_c, @kanthoney: Maybe start working on the things? I suggest starting with those:

[*]Make all equipment sellable, including a configurable sale price, at stations which have the TL to repair it. Pylon weapons continue to be sellable almost everywhere. Need to be a little careful here that selling the initial pulse laser becomes an interesting decision rather than an automatic one.
[*]Adjust the install/repair/removal times for core equipment items to be more interesting.
[*]Breakable standard equipment might still be worth considering even if you can't remove it to save space
[*]Introduce 'disrupted' equipment state.
[*]ECM graphics improvements
[*]Increase NPC equipment usage and damage
[*]Halve beam laser damage/heat to make it not quite as big a jump over the pulse laser and make fights last a bit longer.

Further lasers/masslocking/equipment discussion could go on while we could see and test what impact the suggested changes have on Oolite.

Zireael wrote:

Khem, @cim, @a_c, @kanthoney: Maybe start working on the things? I suggest starting with those: [snip] Further lasers/masslocking/equipment discussion could go on while we could see and test what impact the suggested changes have on Oolite.

Enjoying handing out the orders, are you?

Cody wrote:

Zireael wrote:

Khem, @cim, @a_c, @kanthoney: Maybe start working on the things? I suggest starting with those: [snip] Further lasers/masslocking/equipment discussion could go on while we could see and test what impact the suggested changes have on Oolite.

Enjoying handing out the orders, are you?

No, just thinking it's easier to discuss and provide feedback when we can see what happens and not just imagine things while typing away on the BB. I mean when we have something tangible to refer to.

And apologies if I came across as demanding.

FWIW my handwavium for the torus drive's mass locking was that within a certain range the technology involved in torus drives (which is also found in some space stations) interacts with any other similar technology in an unpredictable and dangerous way, possibly involving a cumulative acceleration effect. It's also affected (or bent) by the closevicinity of huge masses, and who wants to be barreling at an uncontrolled speed into a star when your drive decides that's where it wants to be? Technically the drive is only 'mass locked' by such huge masses, but the phrase is also used for times when you want to avoid nearby ships' drives from affecting your own.

Potentially this also explains how the (now-banned) 'energy bomb' might have functioned. </handwavium>

Zireael wrote:

No, just thinking it's easier to discuss and provide feedback when we can see what happens and not just imagine things while typing away on the BB. I mean when we have something tangible to refer to.

The problem there is one of human nature. Once such changes were in they would stay in, because who would be game to be the first one to say, "Thanks for all the effort, guys, now take them out again, they aren't as good as they sounded."

Better to reach a definite understanding of exactly what is trying to be achieved, why, and how, before making changes. Myself, I'm struggling to see why. A lot of the ideas discussed here seem to be adding complexity for its own sake.

When I visit the equipment broker I don't want to make interesting decisions about balancing energy drain, space aboard ship, increased maintenance costs, etc. against the anticipated usefulness of a piece of kit that is only vaguely described. It's GalCop certified gear, it should just work.

Wildeblood wrote:

When I visit the equipment broker I don't want to make interesting decisions about balancing energy drain, space aboard ship, increased maintenance costs, etc. against the anticipated usefulness of a piece of kit that is only vaguely described. It's GalCop certified gear, it should just work.

Whilst others do or would like to option.
My opinion is that if the core was updated to allow OXPers to create such things would be better. As creating personal Ooniverses is the great strength of Oolite. If someone doesn't like it then they are not forced to have it. The core should remain a framework to hang OXPs on. That doesn't mean we shouldn't try to make the framework better.

Wildeblood wrote:

Better to reach a definite understanding of exactly what is trying to be achieved, why, and how, before making changes.

I think this is wise. I would hope for oolite to appeal to as many people as possible so if core changes are made, I think we should consider the opinions of those who may disagree very carefully.

Venator Dha wrote:

My opinion is that if the core was updated to allow OXPers to create such things would be better. As creating personal Ooniverses is the great strength of Oolite. If someone doesn't like it then they are not forced to have it.

I agree that Implementing these ideas through OXPs may be the best course of action, although I do believe that beam laser could stand to be addressed within the core. No one seemed to disapprove of it.

Venator Dha wrote:

The core should remain a framework to hang OXPs on. That doesn't mean we shouldn't try to make the framework better.

While I use oolite for this too, I believe, it can be a framework for OXPs and continue to evolve as a game true to the spirit of its original inspiration. I played 1.76.0 for a long time without any OXPs and still thought it was a pretty cool game.
But then, well the pull of the dark side is strong, while I,...am weak

I'd also like to say that after using the new map scroll function in trunk I am happy to let the devs work on whatever they like because they come up with awesome stuff.

Better to reach a definite understanding of exactly what is trying to be achieved, why, and how, before making changes. Myself, I'm struggling to see why. A lot of the ideas discussed here seem to be adding complexity for its own sake.

I know we have not reached an understanding on some things. However, I suggested starting with those things we all have an understanding of. (or at least no one has yet said otherwise)

Zireael wrote:

However, I suggested starting with those things we all have an understanding of. (or at least no one has yet said otherwise)

'No-one has yet said otherwise' ain't the same as 'we all have an understanding of'!

I agree that Implementing these ideas through OXPs may be the best course of action,

Some of the ideas are not OXP-able (disrupted equipment, laser tweaks, writable/readable ship data). As for the rest, when possible, a proof-of-concept OXP would be a great thing!

This reminds me of one or two Agile discussions I've been in...

Can someone look at the list and clarify what could be done in an OXP? As OXP volunteers could take the load off the devs then...

Zireael wrote:

I agree that Implementing these ideas through OXPs may be the best course of action,

Some of the ideas are not OXP-able (disrupted equipment, laser tweaks, writable/readable ship data). As for the rest, when possible, a proof-of-concept OXP would be a great thing!

But trunk could be changed to make them OXP-able, which would be my preferred way forward with these suggestions.

maik wrote:

Zireael wrote:

I agree that Implementing these ideas through OXPs may be the best course of action,

Some of the ideas are not OXP-able (disrupted equipment, laser tweaks, writable/readable ship data). As for the rest, when possible, a proof-of-concept OXP would be a great thing!

But trunk could be changed to make them OXP-able, which would be my preferred way forward with these suggestions.

I believe that's the idea for most of the equipment related badassery discussed here, except lasers which are hardcoded

Another idea of dubious merit...

Besides cargo space, the other areas for equipment that are currently in game are the laser mountings and the missile pylons.

I'm aware that some oxps already employ equipment that use missile slots but I believe they are all limited 'shot' devices.

If, instead of just, "requires_cargo", we had, "requires_missile", or (perhaps more problematical), "requires_weapon", then we would have a crude system of both equipment space (potentially 2 different kinds) and cargo space. Equipment could be assigned to occupy space in one of 3 different ways, or not at all.

A drawback of this approach is that it might be necessary to consider adjusting core ship data for missile capacities and lasers. If a MkIII should have 4 missiles then should it be granted an extra one (or two) so that it can still accomodate all the equipment it is used to, or should that be at the cost of less missiles than the standard 4?

Not perfect of course but it would be using values that already exist within the game and might make some nice options for oxp writers.

Why do you say the idea is dubious? I like it. The more possibilities for core or OXPs, the better.