Oolite Bulletins

I agree about the boys to match the basic current look. But I think part of the appeal of the game is its customization so it should be careful about adding too much. But for noobs there really needs to be a Build Your Own Dream Game push, so they know the core game is just updating the classic as it was, while the OXPs take it to the next level--your way

This shouldn't have to be mentioned, but wth I'll call it to your attention anyway.

There's many players that run oolite on not-so powerful computers; old machines getting a bit long in the tooth, laptops, net-tops, Pandora et al, and a broad range of graphics, from crappy onboard chipsets to the cutting edge geforces.

My point? One of the beauts of oolite is that it doesn't have extreme hardware requirements, you can run it on almost anything straight out of the box. Stuff too much into the core game, and the abovementioned low end hardware is gonna choke.

ED has prob'ly already lost those ppl; it's requirements are starting to look kinda heavy. Eyecandy don't make a game; playability does!

Zireael wrote:

9) Integrate [wiki]Distant Suns[/wiki] it's universally acknowledged that default suns are too close

No it isn't.

It's true suns are unrealistically close in core, but I find using Distant Suns or other oxps which place them further away makes sunskimming impossibly tedious.

earl sleek wrote:

Zireael wrote:

9) Integrate [wiki]Distant Suns[/wiki] it's universally acknowledged that default suns are too close

No it isn't.

It's true suns are unrealistically close in core, but I find using Distant Suns or other oxps which place them further away makes sunskimming impossibly tedious.

While I admit the suns are too close astronomy-wise, gameplay-wise and balance-wise they are painfully far to go sun-skimming. Even assuming no interruptions while using the torus, going to the sun can take 2-10 times longer than docking at the main station and buying fuel. The risk vs reward is too high to me to justify doing it much even without moving the sun further from the planet.

yes, a BIG thanks to all who have kept Oolite going for all these years. I tend to agree that core should be just that core. KISS.
anything else you may want is easily added by OXZ/OXP and if it is not already done then YOU can write it yourself...

Cmdr Wyvern wrote:

This shouldn't have to be mentioned, but wth I'll call it to your attention anyway.

There's many players that run oolite on not-so powerful computers; old machines getting a bit long in the tooth, laptops, net-tops, Pandora et al, and a broad range of graphics, from crappy onboard chipsets to the cutting edge geforces.

My point? One of the beauts of oolite is that it doesn't have extreme hardware requirements, you can run it on almost anything straight out of the box. Stuff too much into the core game, and the abovementioned low end hardware is gonna choke.

ED has prob'ly already lost those ppl; it's requirements are starting to look kinda heavy. Eyecandy don't make a game; playability does!

I know and I paid attention to that fact, too.
Speaking of playability, there was a neat bit of code which printed the free space left upon every scooped pod, this would be a good addition too. Can't remember where I saw it. Also, some code was floating around which made the Vipers use their landing lights ...

I think a "no" from me as well. I'll explain a few of them, since I think there's some important but not necessarily obvious points to look at on the differences between implementing functionality as an OXP and implementing it in the core (which could be summarised as "OXPers can get away with a lot of shortcuts").

Zireael wrote:

1) Integrate [wiki]Randomshipnames_OXP[/wiki] with the core game better immersion

RSN is a really nice OXP, but the problem with incorporating something like that into core is the sheer amount of data it needs to hold to work well - which then gives a big problem for translation OXPs. There are some things which just work better as an OXP.

If there was apparent interest in making multiple ship naming OXPs, then it might be worth developing a framework for core that made them easier to write and interoperate, but there doesn't appear to be any call for that at the moment.

Similarly for 7: Famous Planets - it's a lot of potentially translatable text, and FP only does less than a tenth of the systems in the game. It'd be too large to include if it was "finished" and it's too piecemeal to include now.

Zireael wrote:

2) Take out the basic shields code from [wiki]Custom Shields[/wiki]; minus the things that generate more fuel and debris get rid of the FIXME:Add shields note in code

Shields is on my list of things to look at - but note, only to look at: no promises at all when or even if I do anything about it. This is really a case where an OXP can do a quick hack (which I don't mean in a disrespectful sense or to minimise the significant effort needed to do what CSOTB did with that OXP, or Commander McLane with the earlier NPC Shields one) but implementing it in core requires more effort, possibly even an impractically large amount.
- visual effects for shield impacts (we can do quite a bit better than the OXP ones, by creating custom shield glow effects fully integrated into core).
- rebalancing to deal with all NPCs having ~128-256 extra energy (this is huge just for core, and an OXP compatibility nightmare)
-- a big part of this is making NPCs suffer equipment damage like the player does, so that it isn't just giving them more energy banks
--- which means that more of the equipment needs to do something when fitted to an NPC
---- which means more thought and rebalancing about what equipment the populator should be giving them
----- which might open up other cans of worms...
- redoing combat AIs at both tactical and strategic levels to make sensible (or at least intentionally silly) decisions based on their shield strength
- implementing it in ObjC (fast, memory efficient) rather than JS (slow, inefficient) ... which isn't difficult, but means none of the OXP code is actually reusable.

Zireael wrote:

3) Integrate [wiki]Display_reputation_OXP[/wiki] ease-of-use addon which has no effect on gameplay

With 1.80 redoing parcel/passenger contracts so that you can actually see the ones you don't have the reputation for, this probably isn't so useful (and as-is, it gives a bit too much visibility of the odd way reputation is implemented internally). The other thing is that as there's no central body - unlike Elite Rating, or the various OXP organisational ranks/reputations - which coordinates these contracts, an actual display of your reputation seems a bit odd.

Zireael wrote:

4) Integrate [wiki]Delightful Docking[/wiki] or [wiki]NeoDockLights[/wiki] or [wiki]Dock_Assist_System_OXP[/wiki] make docking easier for newbies

If between the slower station rotation and the "docking" lesson in the tutorial beginners still can't figure it out, then they're probably not going to do very well with any of the game. I did test the tutorial with a complete beginner - and even the first bit of the combat section (shoot down a weakened, unarmed, but dodging Krait) was considerably tougher than the docking for them.

Zireael wrote:

6) Integrate a better buoy texture - I suggest Smivs' Better Buoys DH are even better, but use shaders IIRC

As an aside here, using shaders is not necessarily a bar to inclusion in core. Requiring shaders for essential functionality is a problem, but shader use - especially if it uses the existing standard diffuse/emission/specular/normal maps shader in the core - is fine.

Zireael wrote:

8 ) Integrate Sunskimmers OXP better immersion

Somewhat similar functionality is already in 1.80 (and even in earlier versions, though not in quite the same way).

Zireael wrote:

9) Integrate [wiki]Distant Suns[/wiki] it's universally acknowledged that default suns are too close

Visually, yes. On the other hand the travel time to them is currently better balanced than having them 2/3/5/10 times further away would be. Moving the suns further away in core means adjusting how the torus drive works, which is a huge job (and, remembering previous discussions on the subject, may not even be possible or desirable to do in the necessary way)

There's also a subtler issue which is that the further away the sun is, the more ships get generated to fill the SP and SW lanes, which increases processor load.

cim wrote:

Zireael wrote:

9) Integrate [wiki]Distant Suns[/wiki] it's universally acknowledged that default suns are too close

Visually, yes. On the other hand the travel time to them is currently better balanced than having them 2/3/5/10 times further away would be. Moving the suns further away in core means adjusting how the torus drive works, which is a huge job (and, remembering previous discussions on the subject, may not even be possible or desirable to do in the necessary way)

There's also a subtler issue which is that the further away the sun is, the more ships get generated to fill the SP and SW lanes, which increases processor load.

Would it be possible to use some optical/visual/perspective trick that draws far away things smaller than they really are? That kind of solution would keep the balance as it is and would a give realistic looking space.

spara wrote:

Would it be possible to use some optical/visual/perspective trick that draws far away things smaller than they really are? That kind of solution would keep the balance as it is and would a give realistic looking space.

Yes and no. I played around with that a bit a while back - starting here and reading on until you get to the peppers. It worked pretty well for ships but can't be used on planets/suns until they're far enough away that it doesn't matter anyway.

Zireael wrote:

9) Integrate [wiki]Distant Suns[/wiki] it's universally acknowledged that default suns are too close.

I quote this as an example of why more thought is need before making requests of this type. it is not universally acknowledged at all. Some people think so, others don't.
And this is my point. The core game is fairly basic, but can be augnmented by OXP. And this is right - the way it should be. A basic game is going to give everybody a good (if simple) experience, but those who want more/better/different can grab an OXP to do this, or make one themselves.
So you really do get the best of all worlds. This would cease to be the case if everything everybody likes or wants was added to the core game. The additions you want might be hated by others. So let's leave things alone and give up on these silly wish-lists please.
As cim has eloquently explained above, to implement half of these would be more work than is worthwhile, and to implement the other half would just ruin the game for many players.
And a final thought - if the core game contained everything, what the hell would us OXP authors have to do with our lives? I suppose we'd have to get one!

cim wrote:

spara wrote:

Would it be possible to use some optical/visual/perspective trick that draws far away things smaller than they really are? That kind of solution would keep the balance as it is and would a give realistic looking space.

Yes and no. I played around with that a bit a while back - starting here and reading on until you get to the peppers. It worked pretty well for ships but can't be used on planets/suns until they're far enough away that it doesn't matter anyway.

Got it, interesting read. To make it work, instead of just making entities smaller in comparison with the distance, you would need to make them smaller in comparison to distance and the central point of player's view. That would probably cause some sort of fish-eye effect though, but it would work.

cim, thanks a lot for taking the time to respond to this thread! Your replies cleared up a lot of things...

EDIT:

Got it, interesting read. To make it work, instead of just making entities smaller in comparison with the distance, you would need to make them smaller in comparison to distance and the central point of player's view. That would probably cause some sort of fish-eye effect though, but it would work.

Pretty much. There's already work being done on re-scaling by Redspear, and combined with this, it could be excellent!

cim wrote:

Zireael wrote:

9) Integrate [wiki]Distant Suns[/wiki] it's universally acknowledged that default suns are too close

Visually, yes. On the other hand the travel time to them is currently better balanced than having them 2/3/5/10 times further away would be. Moving the suns further away in core means adjusting how the torus drive works, which is a huge job (and, remembering previous discussions on the subject, may not even be possible or desirable to do in the necessary way)

There's also a subtler issue which is that the further away the sun is, the more ships get generated to fill the SP and SW lanes, which increases processor load.

This is very speculative, but what if there was a way to make intra-system hyperspace jumps? Costing small amounts of fuel, perhaps. If each stellar system was modelled to have multiple planets in their own orbits (and here is where it all gets even more speculative), perhaps an intra-system jump could be made, electron-like, from one "orbital shell" to the next, inwards or outwards. Each intra-system jump (witchhops? witchskips?) would require plotting, a countdown, etc., and would take you to a new witchpoint near to the next planet in or out - roughly as near as the main system WP is to the main planet. Handwavium could be that a planetary mass drags around a couple of hyperspatial distortions, which is why a microjump would take you there even if the actual planet was in opposition around the sun.

Not all planets in a system would be inhabited, of course: only those further up the TL ladder would have offworld colonies (although there might be all sorts of non-regulation things to be found ...). But we could have a big close-up sun, suitable for torusing towards and skimming, from a planet in a Mercury-style orbit. To get there from a planet in an Earth-style orbit, in an Earth-style solar system, would take two microjumps: one inwards to the Venus orbit, and another one in to the Mercury orbit.

spara wrote:

That would probably cause some sort of fish-eye effect though, but it would work.

I'm not quite sure what you're suggesting - any chance of a diagram?

I found the problem was that if you apply the extra shrinking to anything more than a degree or so in size, you get visible oddities (e.g. flying past a planet turns into flying straight at it as you get closer).

Disembodied wrote:

This is very speculative, but what if there was a way to make intra-system hyperspace jumps? Costing small amounts of fuel, perhaps.

A fuel cost makes it rather easy to get stranded somewhere unpleasantly far from anywhere, though if the intra-system jumps were hitchhikable (consistency with current witchspace physics would suggest not in practice) I suppose there could be some distress call mechanism. It also potentially increases the entity count quite a bit because each sub-witchpoint then needs appropriate traffic generating to nearby points of interest, and potentially also jumps between the points need tracking for NPCs.

I think your idea from that previous thread about making torus drive go faster the further away from massive objects you are is perhaps more practical, if pretty much anything counts as "massive" - so you'd go at 32x if there was an asteroid or a ship just off the scanner edge, but could get up to maybe 160x or even faster if there was nothing (not even a cargo pod) within hundreds of kilometres. The catch is that a larger system really requires NPC torus including something like Escort Contract's hitchhikable torus, or you basically rule out any activity where the player isn't solo.

(Ultimately the problem is that getting from Oolite 1.80 to Oolite with bigger systems and any form of redone fast travel is likely extremely tricky to do safely)

As you noted, Escort Contracts already has a NPC torus, and I like the speeds idea. Easier to implement than varying the display.

(Ultimately the problem is that getting from Oolite 1.80 to Oolite with bigger systems and any form of redone fast travel is likely extremely tricky to do safely)

Step-by-step First make the travel speed depend on distances (it shouldn't affect the current situation because the size of the system and distances involved wouldn't be changed) and then bigger systems could be made