Oolite Bulletins

Dizzy,
The download link doesn't seem to have any of the "6" mass-lock decel versions. And the js32ECMAv5dbg.dll isn't present either. Have I missed something?

Oops...

I accidentally re-uploaded an older zip, instead of the correct one.. that'll teach me to get rid of older junk as I go..

VERY sorry about that.. fixed now.

Tricky wrote:

Diziet Sma wrote:

Tricky wrote:

At extremely high speeds there should be some danger of "burning up" from smashing into any tiny elements in space.

But not at what is still just a paltry fraction of C, surely.. and it wasn't "some" danger.. it was practically guaranteed, once the condition was triggered.

I know, I was suggesting a new mechanic because of the higher speeds now available.

Thinking some more about that, I'm not in favour of it..

Random sudden-death events, completely outside of the control of the player, are generally frowned upon in games.. and with good reason. Whilst this may not quite come into that category, even a 0.1% chance that engaging the Torus drive would lead to a sudden "Boom! - you're dead" moment wouldn't really be acceptable for most players.

Redspear wrote:

Dizzy: ok, I can halve the beacon size and update the oxp (probably tomorrow).

Did you do this yet, Redspear?

Diziet Sma wrote:

Tricky wrote:

At extremely high speeds there should be some danger of "burning up" from smashing into any tiny elements in space.
...
I was suggesting a new mechanic because of the higher speeds now available.

Thinking some more about that, I'm not in favour of it..

Random sudden-death events, completely outside of the control of the player, are generally frowned upon in games.. and with good reason. Whilst this may not quite come into that category, even a 0.1% chance that engaging the Torus drive would lead to a sudden "Boom! - you're dead" moment wouldn't really be acceptable for most players.

OTOH, the torus drive isn't really acceptable to some players, and anything that would discourage the devs from their current path of insinuating it deeper into the game might be welcome.

Someone explain why the technology that makes you go 7x faster uses fuel, but the technology that makes you go 32x faster doesn't use fuel. It's ridiculous.

Wildeblood wrote:

Someone explain why the technology that makes you go 7x faster uses fuel, but the technology that makes you go 32x faster doesn't use fuel. It's ridiculous.

Totally different technologies, of course..

One uses a rather strange massless drive system that can be pushed into an overdrive condition by pumping an equally strange fuel into it, in some way.. the fact that it happens to be the same fuel that powers the wormhole generator is merely a happy coincidence. The other warps local space/time in such a way that one can rapidly fall towards one's destination, and requires energy, most likely electrical, to work, but not fuel. As such, it is negatively affected by other local space/time distortions, which is why it 'mass-locks'..

No doubt others can expand on the handwavium, if required..

I've only just noticed that another_commander created a new branch "rescaling_experiment" on Github a few days ago..

Would have been nice if he'd told us, of course..

Many thanks, a_c.. that simplifies things considerably.

I note that it says "This branch is 3 commits ahead, 2 commits behind master". Presumably the "2 commits behind" refers to cim's friction fix, and a_c's sun-glare fix..

I've already merged those 2 commits into my own local copy.. how can I push them to the rescale branch?

Diziet Sma wrote:

...the fact that it happens to be the same fuel that powers the wormhole generator is merely a happy coincidence.

I saw some guy on TV once, pointing out that reinforced concrete is a miracle. If not for the happy coincidence that steel and concrete have the same thermal expansion our cities could not exist. Meanwhile Richard Dawkins gets about the world demanding that Christians show him a miracle or else.

Lest this look like gratuitous thread-jacking, this is the first time I've posted in this thread but I've read along from the start and congratulate you on your effort, Redspear.

I've only just noticed that another_commander created a new branch "rescaling_experiment" on Github a few days ago..

Would have been nice if he'd told us, of course..

Many thanks, a_c.. that simplifies things considerably.

That's brilliant news!

Diziet Sma wrote:

I've only just noticed that another_commander created a new branch "rescaling_experiment" on Github a few days ago..

Would have been nice if he'd told us, of course..

Many thanks, a_c.. that simplifies things considerably.

I meant to mention this here once I had made some further changes regarding making rescaling a compile-time option, but didn't manage to get around to it due to some RL overdrive. I hope to be able to do something with it during the weekend, but the RL fun isn't over yet...

Ahh.. that makes sense.. I look forward to it.

Diziet Sma wrote:

Redspear wrote:

Dizzy: ok, I can halve the beacon size and update the oxp (probably tomorrow).

Did you do this yet, Redspear?

Box doesn't seem to want to let me upload it at the moment but otherwise it's done. I won't say when lest I curse it again but as soon as I can...
Of course a half size buoy at half the range from the station gives a familiar view upon launching but this won't apply to stations for extra planets. I haven't moved the lights on the withpoint beacon, so they appear at a little distance from the buoy; I quite like the effect but see what you think.

The new scaling has given me the excuse to make a new type of laser to include with the oxp: a sniper laser.
Given that laser ranges are a third of what they were and scanner range is a half, it is now possible to be on scanner but out of the military laser's range. So, the sniper laser has the full reach of the scanner, and considerable power, but a much, much lower fire rate. It's suited to picking off enemies but not so much for dog-fighting (although it can still be deadly with careful aim). As before, you'll need to edit equipment.plist to remove all of the "//" if you want to enable it.

Wildeblood wrote:

Lest this look like gratuitous thread-jacking, this is the first time I've posted in this thread but I've read along from the start and congratulate you on your effort, Redspear.

Thanks Wildeblood. Your Altimeter.oxp was very handy in getting those surface shots (and distant suns compliments the rescaling very nicely )

another_commander wrote:

Diziet Sma wrote:

I've only just noticed that another_commander created a new branch "rescaling_experiment" on Github a few days ago..

Would have been nice if he'd told us, of course..

Many thanks, a_c.. that simplifies things considerably.

I meant to mention this here once I had made some further changes regarding making rescaling a compile-time option, but didn't manage to get around to it due to some RL overdrive. I hope to be able to do something with it during the weekend, but the RL fun isn't over yet...

Thank you!
Hope it's fun of the good variety...

Ah ha... working again

Updated oxp compponent as described above:

https://app.box.com/s/3l8rv595s6bj01digdh7

32-bit versions of the 6 Windows executables now available as well:
https://app.box.com/s/by5q9ryi8g5ru4we4k39

Thanks Dizzy.

I'm going to be busy for a little while and so will be even less responsive than usual.

Meanwhile, in case I somehow messed something up with that oxp, the older version is still available (further up the thread).