Oolite Bulletins

Posted: **Thu Mar 30, 2017 9:39 pm**

I missed that part too. I'll point out that once the error happened, you'll have to restart from scratch (that is clone again, then the three lines).

Posted: **Thu Mar 30, 2017 10:20 pm**

Note to self: read the file called "readme"

[Edit] And successfully built! Thanks a_c!

Posted: **Fri Mar 31, 2017 11:05 am**

Pulling the code is now working. Always the fine print... I guess.

Posted: **Fri Mar 31, 2017 4:58 pm**

I tried it with some OXPs. Of course, most of them "broke" (that is, not working as intended) in various ways, that's to be expected.

However, I have a question: I see that part of the modifications are in the plist config files; is it final or is it planned to change the interpretation of the parameters instead (that is, rescale them internally)?

Posted: **Fri Mar 31, 2017 7:22 pm**

Astrobe wrote:
However, I have a question: I see that part of the modifications are in the plist config files; is it final or is it planned to change the interpretation of the parameters instead (that is, rescale them internally)?

If I understand your question correctly then the plist modifications are there simply because that is where those elements are set.

There are complications with regards to weapon ranges for example with some of the corresponding behaviours set more 'internally'.

As for things like model_scale_factor, before that feature was available (in version 1 of the experiment) I did calculate all the exhausts and laser positions, then shrunk the models myself. That work still exists in the oxp if I'm not mistaken.

Ships could be rescaled 'internally' but as they are not all scaled by the same factor then I would need a means for calculating which ones should be scaled by which factor. I've done this already for other ship elements in the equipment by ship class oxp for both core and oxp ships but when someone's oxp ship gets scaled automatically in a way they didn't wish then that is undesirable behaviour.

I can't think of another game or 'universe' where all of the core ship sizes are so similar. The Krait for example, a "one man fighter", is wider than an Anaconda, "the largest known freighter".
What the...? So I shrunk some ships and not others as illustrated here. It's been tweaked a bit since then but not by much.

Shifting stuff away from the plists tends to set it in stone with regards to oxps and that's not really what I want. I only started dipping into the core becase I couldn't do it by oxp.

I don't think anything is final yet, it's just the best I can manage so far.

Does that answer your question, Astrobe?

Posted: **Fri Mar 31, 2017 8:53 pm**

I have finally been able to pull the code, built the code, and run it with all my expansions. Griff's retextures also work now.

I'll either place the code in a GitHub, or upload it to the server I got for my Oolite experiments.

One more question: how can I compile with debugging symbols removed?

Posted: **Fri Mar 31, 2017 8:56 pm**

pleiadian wrote: ↑Fri Mar 31, 2017 8:53 pm
One more question: how can I compile with debugging symbols removed?

After the build has been completed, cd to the directory where the executable is and do a strip -s oolite.exe.

Posted: **Sat Apr 01, 2017 9:45 am**

Redspear wrote: ↑Fri Mar 31, 2017 7:22 pm
Does that answer your question, Astrobe?

Yes.

I think that "internal rescaling" may be needed in some places. For instance, OXPs that "move the sun" will break - and judging by their number I think this modification is somewhat common. Ship speeds are also an issue. There are a lot of additional ships, so having everyone to adjust this parameter is problematic.

I fear that because the rescaling will break old habits, it might be more or less well received because the Oolite community is I think on the conservative side (which is not a bad thing - protecting Oolite's identity is necessary). If in addition it breaks too many OXPs - and it probably will break some no matter what because some have hardcoded distances and speeds (DeepSpace Pirates for instance) - then it could be a no-go for some players.

Posted: **Sat Apr 01, 2017 2:32 pm**

Astrobe wrote:
I think that "internal rescaling" may be needed in some places. For instance, OXPs that "move the sun" will break - and judging by their number I think this modification is somewhat common.

Unless they are setting a sun distance factor of less than, say 4, then I think they won't 'break' as such they'd just be a little closer than intended.

Astrobe wrote:
Ship speeds are also an issue. There are a lot of additional ships, so having everyone to adjust this parameter is problematic.

I'm considering a converter oxp.
Bogus code example below:

Code: Select all

this.shipSpawned...
If /= core ship && cargo <1
{model_scale_factor = 0.33
max_speed = max_speed /2
thrust = thrust /2}

else

If /= core ship && cargo <50
{model_scale_factor = 0.5
max_speed = max_speed /2
thrust = thrust /2}

else

If /= core ship
{max_speed = max_speed /2
thrust = thrust /2}

Astrobe wrote:
I fear that because the rescaling will break old habits, it might be more or less well received because the Oolite community is I think on the conservative side (which is not a bad thing - protecting Oolite's identity is necessary). If in addition it breaks too many OXPs - and it probably will break some no matter what because some have hardcoded distances and speeds (DeepSpace Pirates for instance)

If I could really do a good enough job (with some help of course) then perhaps things like oxp config could be used to help out with any upcoming oxps; or like-minded maintainers might consider editing some of the old ones.

That it has come this far when some/many seemed to think it was impossible is already a 'bit of a result' in my book and I suspect that, like the sun distance example, many oxp things will be affected rather than truly broken.

There will be exceptions of course but then some old oxps are already incompatible with the more recent incarnations of oolite.

Astrobe wrote:
it could be a no-go for some players.

Indeed. Folks have been quite vocal about their concerns and misgivings with regards to rescaling...

I can't please everyone, as I think I have consistently demonstrated

I just wanted to make some improvements to my game and be able to share them with anyone else who liked them too.

Posted: **Sun Apr 02, 2017 6:56 pm**

Redspear wrote: ↑Sat Apr 01, 2017 2:32 pm
I can't please everyone, as I think I have consistently demonstrated

I think I've heard A_C talk about a merge with master, so we actually have to please everyone; or rather, to quote someone I don't remember the name of, displease everyone equally.

Just to be clear: I'm betting on its success (even though I don't like the reduced scanner range; but if it has to be part of the "package" I can live with it). I'm adapting what I'm doing to it. I'm pointing out potential problems so that the transition is as smooth as possible.

As for help, is it too early to report problematic OXPs and possible fixes?

Posted: **Sun Apr 02, 2017 7:30 pm**

Just so that I can confirm: the rescaling experiment is working quite well, it's now showing stations in their correct size on the scanner (5:1 level). A little hard to see because it's flashing, but it's definitely there (look closely)

Posted: **Sun Apr 02, 2017 8:09 pm**

Astrobe wrote:
I think I've heard A_C talk about a merge with master, so we actually have to please everyone; or rather, to quote someone I don't remember the name of, displease everyone equally.

That's not for me to decide of course but if that were to be a possibility then you would deffinitely have a point.

Astrobe wrote:
Just to be clear: I'm betting on its success (even though I don't like the reduced scanner range; but if it has to be part of the "package" I can live with it). I'm adapting what I'm doing to it. I'm pointing out potential problems so that the transition is as smooth as possible.

Thanks for your faith in the project, especially to the extent of making rescale-friendly stuff - much appreciated

As for the scanner, what exactly don't you like about it being smaller?
I ask partly because it doesn't have to be as small as I've made it.

Once I'd shrunk some of the ships then I needed to reduce the speeds or we'd have some very nippy ships out there. Reducing the speeds creates the need for either a smaller scanner or a deep love for all things mass-lock.

All ships are half as fast, so the scanner need only be shrunk to half size (as it was in versions 1 and 2 of this thing) but here I've shrunk it to 1/3 size (the most extreme level to which some of the ships have been shrunk). This does have some 'benefits' however such as reduced time spent in masslock; overtaking other ships is a little more 'scenic'; very large objects (see below) can appear as such on scanner; and more 'interesting' station approach.

Of course I could have just carried on making things bigger and not needed to shrink anything but proportionally there would have been no real difference.

Astrobe wrote:
As for help, is it too early to report problematic OXPs and possible fixes?

Please do - I had meant to ask earlier

pleiadian wrote:
Just so that I can confirm: the rescaling experiment is working quite well, it's now showing stations in their correct size on the scanner (5:1 level). A little hard to see because it's flashing, but it's definitely there (look closely)

Yes

even at 1:1 the station blip will appear slightly larger than a ship one as seen in the third picture of this post.
A 1/3 size scanner is big enough for an anaconda to still have a small blip and yet small enough for a station to have a slightly bigger one.

Have you found a 'huge' asteroids yet?

Thanks for the report pleiadian.

Posted: **Mon Apr 03, 2017 5:32 pm**

Redspear wrote: ↑Sun Apr 02, 2017 8:09 pm
As for the scanner, what exactly don't you like about it being smaller?

I can't really be objective about this because I favor an approach where one adds game-play elements to masslocks rather than avoiding/minimising them. That's what I did in my surjectors OXP, which allows one to overtake slowies with almost-free injectors at the cost of some safety.

So it seems to me that it reduces too much the masslock situations. The lanes seem depopulated, and I attribute half of my encounters to my modified Deep Space Pirates that spawn things based on your Torus drive usage rather than your location.

A propos, Deep Space Pirates may need one adaptation: half the distance at which the ships are spawned. As I said I run a modified version but this adaptation let it work as before and I think it should work with the original.

KeerperSky OXP is not in the manager (it really should) but other "sun moving" OXPs are. KeeperSky applies a sun_distance_multiplier to 3, which makes the sun way too close. The new multiplier should be 15, imo. 12 looks ok at first but the planet looks a bit too big from the sun, and 18 is a bit too far. So I think that for those OXPs, applying a x5 on the original parameter should be a good fix.

My "Shaky drives" OXP isn't the most popular thing in the world, but broke interestingly because it relies on a magic number: 32 (the torus speed multiplier). Unlike the other magic multiplier (7 - injector speed multiplier), if I'm not mistaken it is not available to scripts, so even disciplined programmers have no choice but hardcode it. The "Bullet Drive" OXP, which was its father, may have a similar issue.

Posted: **Mon Apr 03, 2017 6:15 pm**

Astrobe wrote:
So it seems to me that it reduces too much the masslock situations. The lanes seem depopulated

That can be adjusted without increasing the scanner.
Crudely:
Narrower scanner = less encounters
Longer lane = more encounters
Narrower lane = more encounters
So there's quite a bit of potential for tweaking here.

In part it could be illusiory (but not entirely I suspect):
You spend less time in mass lock.
You travel greater distances between mass locks.

Lane length in particular was a quick fix that could be optimised.

I'll likely reply further when I have more time. Thanks for your thoughts Astrobe.

Posted: **Mon Apr 03, 2017 7:26 pm**

Redspear wrote: ↑Sun Apr 02, 2017 8:09 pm

pleiadian wrote:
Just so that I can confirm: the rescaling experiment is working quite well, it's now showing stations in their correct size on the scanner (5:1 level). A little hard to see because it's flashing, but it's definitely there (look closely)
Yes even at 1:1 the station blip will appear slightly larger than a ship one as seen in the third picture of this post.
A 1/3 size scanner is big enough for an anaconda to still have a small blip and yet small enough for a station to have a slightly bigger one.

Have you found a 'huge' asteroids yet?

Thanks for the report pleiadian.

As a matter of fact I didn't find any huge asteroids yet, but I attribute that to me not knowing how to scan for asteroid fields

That means, I don't know how to find them yet.

Anyways, as for the Hyperdrive - I must say it's quite fun to zoom around a system with about 300 km per second. I'd say the planets "zoom" by as they should be. I can hyperdrive toward a station and only in a relatively short distance to the station I mass-lock into the aegis. This is quite fun I have to say and much more realistic. When not hypercruising, I'm still at normal speed of 320m/s with a Cobra Mark II-X. This is really cool, and it looks stable enough for me to be used for normal game play.

Oolite Bulletins

Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment

Re: Split: Re-scaling experiment