Oolite Bulletins

Eric Walch wrote:

Why not? I think the subentities mass still could do with fixing

I thought subentities aready took density into account. Thanks for highlighting this 'feature'!

_ds_ wrote:

Right… some ships' densities are just going to have to be set suitably

Precisely! We can't be expected to second guess any and all OXP ships' statistics!

Dizet Sma wrote:

I was thinking to myself that this implied sun skimming in a big cargo hauler should take proportionately longer to accomplish..

Eric Walch wrote:

When I would build a fuelscoop for a big ship, I would design the collection entrance bigger so it fills up in the same time as with a small ship.

Give us a few days, I might be able to find a compromise...

Shouldn't a bigger fuel scoop cost more?

Problem is oolite doesnt make much logical sense. Pricing generally is insane. Heat shielding should cost much more on larger ships, escape pods come with insurance for your ship, and should threfor have an ongoing annual charge and should cost more for more expensive ships.

There is an argument that prices are only canon for Cobra 3, as we never saw a shipyard for anything else in elite. Right now I think we should keep out of that hornets nest and attack one thing at a time.

Cmdr James wrote:

Problem is oolite doesnt make much logical sense. Pricing generally is insane. Heat shielding should cost much more on larger ships, escape pods come with insurance for your ship, and should threfor have an ongoing annual charge and should cost more for more expensive ships.

There is an argument that prices are only canon for Cobra 3, as we never saw a shipyard for anything else in elite. Right now I think we should keep out of that hornets nest and attack one thing at a time.

Ooh! Maybe though this is something that could be solved by one .plist entry – an "equipment price multiplier" or something, which would increase (or decrease) the cost of fuel, missiles, docking computers, scoops, repairs, services etc. etc. by a set factor for each ship.

This would be best if the factor was set individually for each ship, by design, rather than automatically, to give the player a greater variety of decisions when choosing a ship (although I'm sure we could work out rough guidelines for designers to follow). Something like the Python, say: I would make that much cheaper to run than the PCC, because – in-game justification – it's old and common and built around a solid core of robust and interchangeable parts; and because – gameplay justification – it's relatively slow and clumsy and pilots who choose to fly one need a bit of a break.

This would be a way of allowing designers to build in a bit of an excuse for überness. Sure, ship X might be fast and strong and carry a buttload of cargo, but the running costs are five times that of the Cobra III ... you might have a hot ship but you've got to work like a dog to kit it out and to keep it flying.

James, words of wisdom there!

Before anyone asks, I'm pretty sure we won't add yearly insurance premiums to the core game!

For a start, how would we define an actual year - or a month, even? ( this probably deserves its own thread in Discussion already )


And I'm soo not starting either 'heat shielding cost proportional to mass?' or 'escape pods proportional to sale value?', the fuel thread is already more than enough for the time being!

Edit: Disembodied, let's see how things work out - if at all - for fuel first.

The thing is, my preference is that we should have a multiplier that's affected by a specific ship factor, one that makes 'almost sense' given that Oolite has got its own not-quite-specified non-RL physics. That multiplier could be then affected to quite a large extent - but not completely disregarded - by individual ship settings.

That way we have both native & oxp ships being affected by the changes in a fairly consistent manner to begin with, even if no-one bothered to upgrade oxps with the new settings.

The 'not completely disregard' bit is - again just for my own benefit, really - to altogether avoid the mentally jarring concept of having a behemoth running on a thimble of fuel ( or - by extension - using a fig-leaf for heat shield, etc. etc. )

Kaks wrote:

The thing is, my preference is that we should have a multiplier that's affected by a specific ship factor, one that makes 'almost sense' given that Oolite has got its own not-quite-specified non-RL physics. That multiplier could be then affected to quite a large extent - but not completely disregarded - by individual ship settings.

That way we have both native & oxp ships being affected by the changes in a fairly consistent manner to begin with, even if no-one bothered to upgrade oxps with the new settings.

The 'not completely disregard' bit is - again just for my own benefit, really - to altogether avoid the mentally jarring concept of having a behemoth running on a thimble of fuel ( or - by extension - using a fig-leaf for heat shield, etc. etc. )

Makes sense! You'd also want people to be able to make luxury-end ships, which might have reasonable performance levels but which cost great lumps of cash to equip and maintain ... in a game where, after a certain point, money stops mattering so much, we should have opportunities for conspicuous consumption! A bit like the Fer-de-Lance was supposed to be in the original game. Some sort of combination of mass, cargo capacity, top speed and (when it comes to equipment and servicing, anyway) TL availability and rarity would probably be a good basis for a cost multiplier.

Disembodied wrote:

Ooh! Maybe though this is something that could be solved by one .plist entry – an "equipment price multiplier" or something, which would increase (or decrease) the cost of fuel, missiles, docking computers, scoops, repairs, services etc. etc. by a set factor for each ship.

I don’t see why missile and docking computer prices would vary by ship.

Kaks wrote:

Before anyone asks, I'm pretty sure we won't add yearly insurance premiums to the core game!

For a start, how would we define an actual year - or a month, even?

This one’s easy: in terms of game clock time days, of course.

Ahruman wrote:

I don’t see why missile and docking computer prices would vary by ship.

Well, in a Fer-de-Lance, there's the walnut veneer and brushed-steel controls on the docking computer, and the missile bays get valet cleaned to remove all scorchmarks from the launch plates ...

Missiles are a bit tricky to explain, I'll admit, but docking computers – all pieces of equipment, really – have to be meshed in with existing ship systems and circuits. If we assume that there are dozens, even hundreds of different brands of docking computer, manufactured at varying tech levels on numerous worlds across the galaxy, then fitting one to a common-or-garden ship will probably be easier, and therefore cheaper, than it would be with some rare and high-tech specialist vehicle. Cobra IIIs and Pythons will be regular customers in pretty much every shipyard in the galaxy, but you'll need specialist tools and custom parts when you take your Wolf II SE in for its 1,000 light-year service.

I'm not sure why a Python's docking computer should be cheaper than, say, a Boa's, mind you. Maybe that's just a result of Pythons being older, practically ubiquitous, and more likely to get knocked about in their daily lives – so they're built to be easy and cheap to maintain, with generous service ducts and no bulkheads that can't be taken down with a standard OO-gauge hyperspanner and a bit of elbow grease. The Boa, though, you've got those awkward crawlways running at odd angles, and you need half a dozen different hex keys just to get the main flight console open ...

Following the announcement on the Progress thread, 'new, improved' fuel calculations are in abeyance until MNSR.

For the impatient & the curious, the ground work is done and in trunk, and can be enabled by changing found inside universe.h to

oo, I didn't know we could dig about in these .h files and see such interesting stuff, what's do?

edit: gah! i keep getting the slogan wrong

You see, coding stuff is really easy, we just make it appear complicated to look cool. You can do things like changing to and KAZZAAM! Oolite is now multiplayer and you can play with your friends.

Disclaimer: The above statement is absolutely ridiculous and has nothing to do with reality. You are fully responsible for whatever happens to you after having read and believed it.

@Griff: sshhh, that's the secret Cadbury mode.....

soon to be updated to the secret Kraft mode:

lfnfan wrote:

soon to be updated to the secret Kraft mode:

Code: Select all

#define THE_LADY_LOVES_DAIRYLEA_LUNCHABLES     0

All your craft are belong to Kraft?

another_commander wrote:

You see, coding stuff is really easy, we just make it appear complicated to look cool. You can do things like changing

Code: Select all

 #define OOLITE_MULTIPLAYER 0

to

Code: Select all

#define OOLITE_MULTIPLAYER  1

and KAZZAAM! Oolite is now multiplayer and you can play with your friends.

Disclaimer: The above statement is absolutely ridiculous and has nothing to do with reality. You are fully responsible for whatever happens to you after having read and believed it.

hehe actually I had an insane idea the other day of making a server side and a client side, then I remembered ""Object C", not C++ which what that I was going to use...

The basic idea was that the server accepted incoming connections , and if two players happened to be in the same system, The player that first arrived in the system, that players settings was transmitted to the last player arrivals.. so the client became pseudo client-server when the client arrived in a system before the client-server..

in case of missing OXPs, the client would be refused to connect, and informed of the missing OXP names incl. version numbers. Download from client-server could be a possibility, if where it not for security reasons...

In case of additional OXPs the client's additional OXPs would be ignored, since data of ships spawning is generated by the client-server.

Some sort of md5 hash check(or whatever the correct term is) would be required to make sure the OXPs are identical. but that would be ignored to start with.

And Instead of entering IP, a sort of torrent file could/would be used to connect server-clients and clients...

now that was the big idea..

The small idea:

Was to create a server and a client, and connect them on my home LAN, pretty useless because the miss is never going to Play Oolite, and my freinds would only do it, if I told them too.. .

anyway, i think my thoughts should be up, if anybody could use them...