Oolite Bulletins

@Disembodied: This is already happening. Try installing Norby's Coluber HUD CH01 (or any HUD with a digital gauge readout for that matter) and try going on Torus towards empty space. The speed increases continuously as long as there are no obstacles ahead and drops back to standard Torus speeds on approach to planets, suns etc.

another_commander wrote:

@Disembodied: This is already happening. Try installing Norby's Coluber HUD CH01 (or any HUD with a digital gauge readout for that matter) and try going on Torus towards empty space. The speed increases continuously as long as there are no obstacles ahead and drops back to standard Torus speeds on approach to planets, suns etc.

See, I knew it was a good idea ...

<sniggers>

Thanks, very interesting larger re-scaling , the big distance does not increase the time of flight. When long-distance flights with TorusDrive rarely met other ships, so you can fly for a long time without meeting with other ships.

This is for testing special, then will be increased more populated ships or more radius of masslock in the future?

Hi Rustem.

If you're flying from withpoint to planet then the encounter rates should be very similar to the normal game.
The reach of the scanner has been halved, so we might expect 50% of the normal encounter rate, however the proportional distance of withpoint to planet has been doubled (only approximately in this version), so we are effectively travelling down two spacelanes, 50% *2 = 100%.

In earlier versions the doubling was exact but now it's an approximation. If you're flying some other route than WP to main planet/station or main planet/station to sun, then encounter rates may be much, much less (as in the standatd game).

Adjusting the width of the spacelane is one way to alter encounter rates. With a halved scanner range, it is effectively twice as wide (as well as twice as long) as before.

another_commander wrote:

Here is a proposal for laser range adjustments for the next test build:
Pulse: 4125 (original value 12500)
Beam: 4950 (original value 15000)
Military: 7500 (original value 30000)
Mining: 3000 (original value 12500)
}[/code]

a bit late, but here is a crazy idea. More power = less Range, but still more expensive. It could even expand it into classes like this.
Class D Lasers

• Pulse Laser 10000 range 400 Credits Damage factor 1.0, Tech:3
  Beam Laser 8750 range 1000 Credits Damage factor 3.0 Tech:4
  Military Laser 7500 range 6000 Credits Damage factor 6.0 Tech:5

Class C Lasers

• Pulse Laser 12500 Range 800 Credits Damage Factor 1.0 Tech:4
  Beam Laser 10000 Range 2000 Credits Damage Factor 3.5:Tech:5
  Military Laser 8750 Range 12000 Credits Damage Factor 7.0 Tech:7

Class B Lasers

• Pulse Laser 15000 Range 1600 Credits Damage Factor 1.2 Tech:5
  Beam Laser 12500 Range 4000 Credits Damage Factor 4.0 Tech:6
  Military Laser 10000 Range 24000 Credits Damage Factor 8.0 Tech:9

Class A Lasers

• Pulse Laser 20000 Range 4000 Credits Damage Factor 1.5 Tech:6
  Beam Laser 15000 Range 20000 Credits Damage Factor 5.0 Tech:7
  Military Laser 12500 Range 48000 Credits. Damage Factor 8.0 Tech:10

It could be easily implemented via config files only and the Equipment would have a name like

Pulse Laser Class D and so on, but to prevent clutter in high tech systems the Equipment section the Weapons should really have a separate section dividing each class of lasers in the different classes.

Mining Lasers could range from "just" generating minerals to generate Radioactives, gold,gems & platinum.

ofcouse it could be done in an OXP/Z too. Apart from the sectioning in Equipment buy screen and "true" Mining laser behaviour

Cheers

All this looks extremely interesting! Is there a chance that it will be merged in official oolite someday?

Tichy wrote:

All this looks extremely interesting! Is there a chance that it will be merged in official oolite someday?

I would like to think that yes, there is. But it is not going to be without very detailed and thorough prior testing. So far the test builds that went live got some initial attention and generated a few comments and proposals but I don't think that sufficient testing on them was done. For example, we've had feedback that it seemed to be all good so far, then we've found out that the attack AI in the test builds was not functioning as it should, yet nobody had noticed. This is why lengthy testing is important. Merging it to the official game means that we are satisfied that it works fully and doesn't break existing gameplay elements and I think we are not quite there with that yet.

Until then, the experiment continues to live under a separate branch of the official repository and everyone is welcome to further contribute to it by means of github pull requests or proposals and discussion here.

I think this project will be finished ever only if arrive into the trunk as a selectable option. No chance to get enough testing without this imho. So I suggest that our admiral make a requirement from contributors to put all changes into something like if(rescale) condition blocks, and create a new key into .GNUstepDefaults which is false by default, or an item in F2 options screen if possible.

Personally I think many hidden settings could be listed in an advanced options subpage, to reduce the "press shift", "how to turn on antialiasing" and similar posts. (Well, antialiasing was as much hidden that was not listed in the wiki page, now I added it.)

So I think to replace the whole game to the new sizes is a big change and if ever happen then should not close out from the future releases those who would like to keep the original sizes. Much better if it is arrive first as an option, then after enough tests this could be on by default and easy to turn off if somebody do not like it, or use an OXP which not updated yet and do odd things for example due to the new scanner range.

This need "if"s everywhere in the changed code first (imho), and any new changes should be optional also, but programmers will add it only if an admiral suggest it in concrete form.

Norby wrote:

... and if ever happen then should not close out from the future releases those who would like to keep the original sizes.

<nods> I suspect there would be quite a few in that category - and I may even be one of them.

Yeah, why not adding it as an "experimental mode" that the player could choose to enable? Maybe with different saves and a sublist of OXPs that have been tested as compatible.

Tichy wrote:

Yeah, why not adding it as an "experimental mode" that the player could choose to enable? Maybe with different saves and a sublist of OXPs that have been tested as compatible.

Because it is more difficult than it looks and, at least I, cannot put the time it needs in order to do it. It is not just a matter of stuffing options in the executable either, there are also core resource files that are changed for this to work.

Plus, what is so difficult about downloading an already built stand-alone binary that can be copied anywhere on the disk and then uninstalled by simply deleting its folder? If there is no interest to test despite the ready-made binaries then fine, it will just have to take longer until we find some time to complete testing ourselves. But I very much doubt that, even if we did put the time and work to make everything one big option, there would be people willing to test it, if they are not willing to test what is already out there now.

It's a shame that it all took me so long for what is, essentially, a small number of changes to the source code. That's not to disagree with a_c's point re difficulty, rather to point out if I'd been experienced enough I could have done a 'bare bones' version in a week or two. Taking 6 months off didn't help of course but the whole thing went pretty much to plan despite some pretty frank (and on occasion, possibly derisive) criticism from some against what appeared to be a rather emotive idea.

While the argument was still relatively fresh I expect it would have gotten a lot more testing - even if only by those looking to fault it. That kind of feedback is often very useful and of course the forum was more active in those days...

In the end we got a bit of a rush job at completing it; I knew I'd be busy for a few months again but I also knew I had something playable and functional as a proof of concept. I spent bloody ages testing sun skimming until I gave up being logical and just chucked some numbers in there - an approach that worked much better

IIRC several AI behaviors set in ship entity were based around beam laser range. I'd missed that link at the time and was just concerned that they all stayed within the new scanner range so I left them, not having noticed any obvious problems whilst play testing.

Ifs buts and maybes... I am glad that it has attracted interest and appreciation from some and would encourage folks to try it and indeed find fault with it. I haven't walked away from it I'm just really busy lately. Besides, some of the necessary adjustment are probably better made by people who actually know how to code

I can't seem to get the 64-bit Dizzy's Build™ to download. I click on download and it refreshes the page but does not download.

Dizzy's builds are way too old. You want to try the build from this post: https://bb.oolite.space/viewtopic.ph ... 95#p248295