Oolite Bulletins

Posted: **Wed Dec 25, 2013 9:44 am**

Here's the "instant" patch.

+++ b/src/Core/Entities/PlanetEntity.m
@@ -441,7 +441,7 @@ static const BaseFace kTexturedFaces[][3] =
 
        last_launch_time = [UNIVERSE getTime] + 30.0 - shuttle_launch_interval; 
 
-       collision_radius = radius_km * 10.0; // scale down by a factor of 100 !
+       collision_radius = radius_km * 33.0; // scale down by a factor of 100 !
        
        scanClass = CLASS_NO_DRAW;

Fewer immediate issues than the other way, and the planets don't look significantly worse close up because they already looked terrible close up.

It's an extensive journey just to reach the planet from the witchpoint, though - that feels far too slow.

EDIT: 5 minutes at full torus speed to get from the planet to the sun, and then even with heat shielding you get mass-locked so far out from the sun that your temperature is in to the flashing red/purple zone before the scoop starts working. Your ship will have melted by the time you get enough fuel to jump out. Masslocking from planets/suns would need some editing.

In a big system like Riedquat, you need the compass to find the station - I got to the point where it switched from pointing to the planet to pointing to the station and if I hadn't had the compass the station would just have been one more speck of light against the background. That's quite good. It took 45 minutes to get from witchpoint to station, though, counting time spent in mass-locks. You'd need to be a lot more proactive about moving sideways out of masslocks.

Posted: **Wed Dec 25, 2013 10:30 am**

Fewer immediate issues than the other way, and the planets don't look significantly worse close up because they already looked terrible close up.

Posted: **Wed Dec 25, 2013 8:18 pm**

cim wrote:
It took 45 minutes to get from witchpoint to station

You mean without Injectors? I do a few test runs to Riedquat in a Cobra Mk III, the fastest count 1.5 minutes with a single masslock and slowest was 3 minutes with 6 slowdowns, where I used Injectors to go through without moving sideways. Based on these the new 3.3x distance mean about 5-7 minutes in the largest systems (except the first few travel before Injectors), so I think it is not so much.

I am thinking on a helper OXP which use forward visual detection over scanner range to detect possible masslocks in time and suggests the best small direction changes like a GPS voice: "turn left...".

Edit: based on this idea I made masslock borders.

Larger increse of systems than 3.3x maybe not practical without some torus bonus imho, which is another story. I do not think to simply increase the multiplyer due to it can roughly negate the effect of increased distances but some slow further acceleration over time what I plan to test in an OXP.

I suggest to increase system sizes to get bigger space for more planets and intrasystem contracts, regardless from the modelling problems due to I do not think it is a tool to reach Paradox's goal who want restore the sizes of ship models, which allow arriving of external ships in 1:1 scale and similar strength with current ships.

Posted: **Wed Dec 25, 2013 8:35 pm**

Norby wrote:
I suggest to increase system sizes to get bigger space for more planets and intrasystem contracts, regardless from the modelling problems due to I do not think it is a tool to reach Paradox's goal who want restore the sizes of ship models, which allow arriving of external ships in 1:1 scale and similar strength with current ships.

You are correct Norby. Increasing the size of everything is not going to fix the whole reason this thread was started. A GPS does sound interesting however. };]

Posted: **Wed Dec 25, 2013 8:55 pm**

People, I can't say this any more plainly... When the unit of measurement was arbitrarily changed from "feet" to "meters", The ships were not re-scaled accordingly, and THAT is the problem. NOTHING else is going to fix it. I understand that making planets etc. would be the "easy way" to disguise this problem. But, it seems to me that doing things the "easy way", is what caused this whole mess in the first place...

Fix it correctly once and for all, or don't bother with all the hassles of making planets bigger etc., because that is fixing a problem that doesn't exist (unless of course you simply want more and bigger space...). If you make planets bigger etc. etc... you will STILL have a never ending stream of new oxp makers asking and arguing on the forum about the "scale issue"!!!

I'm outta here... do what you want.

Redspear, if you are still going to try and fix this via re-scaling ships, let me know, I am still willing to help with that.

Posted: **Thu Dec 26, 2013 2:47 am**

Cim, thanks for your investigations, reports and expert advice. Very much appreciated.
Paradox, thanks for working on this, especially as you've started on some of the most tedious work...

To reiterate: I intend to explore both making ships smaller AND making planets larger as OPTIONS for people to adapt their game as and IF they see fit.

I can tell you how to alter laser ranges and the torus & injector multipliers from the source, so that you can make ships for your game that fit with your definition of 'the correct scale' and operate as such in your game. However I can't, of course, tell the dev team what to do, nor would I want to.

We can however, make some experiments and show our results. If everyone liked them then I expect you'd get your wish, but...

Redspear wrote:
I chose not to mention my thoughts at the time (although I suspect some may have guessed) for fear of starting a small riot

That was back when I had more sense

...

Anyway, I want to find out how the two contrasting approaches to this experiment play out and, for those who are interested, explain what they can do to make THEIR game adopt the approach that interests them.

So, to further that end, I think your idea of shrinking the Anaconda, Cobra III and Adder makes sense: the two extremes of the player ships and the starting ship. Maybe we should throw in a real fighter too, perhaps the Sidewinder and/or the Viper? We'd need the NPC ships to be at the smaller scale too and perhaps we should overwrite the others so that they are not used when testing this approach.

I'm genuinely appreciative of ALL the offers of help and I'm sorry it's my jumping in that's caused a bit of a fuss to the extent that others have been pressed into tests before I was ready to do them myself.

So, let's try to keep cool for now with the understanding that if we've talked about testing it then that's what I intend to do. I have no intention of abandoning that but I have no intention of forcing it down anyone's throat either.

Merry Christmas

Posted: **Thu Dec 26, 2013 8:11 pm**

OK, for those who are interested in testing smaller ships, here's how to make some of the alterations that have been suggested to the source code.

You will of course need some smaller ships (try some of Paradox's downloads that have been made available within this thread) including the NPC ships too.
As Paradox has already started the ball rolling on that one, I thought I could start off with editing the code.

This requires an installation from the source. This post from another_commander will help you with that if you are using windows.
https://bb.oolite.space/viewtopic.php?f=8&t=5943
I expect there are similar posts for other OS.

Once that is up and running (which will take more time than work) you will need to edit the source itself. This is a lot less daunting than it sounds...

If you go to this folder: myoolite/oolite/src/core/Entities, some useful alterations can be made as explained below.

Laser ranges:

This is one of the easier ones to find.
Within the Entities folder, open the file ShipEntity.m with wordpad or similar (notepad can cause problems with oxps so that may not be a good choice here).
If you scroll to the very end of this file you should find this:

Code: Select all

GLfloat getWeaponRangeFromType(OOWeaponType weapon_type)
{
	switch (weapon_type)
	{
	case WEAPON_PLASMA_CANNON:
		return 2000.0;
	case WEAPON_PULSE_LASER:
		return 4000.0;
	case WEAPON_MINING_LASER:
		return 4000.0;
	case WEAPON_BEAM_LASER:
		return 5000.0;
	case WEAPON_THARGOID_LASER:
		return 6000.0;
	case WEAPON_MILITARY_LASER:
		return 10000.0;
	case WEAPON_NONE:
	case WEAPON_UNDEFINED:
		return 32000.0;

The numbers will be different but that's because I've edited the ones above to be provide an interesting test for smaller ships. You may like to try different numbers but if you scale them at a different factor to your ships then combat will likely work differently.

Make the changes to the numbers that you would like (you can try the ones above for starters) and then save the file.

Torus Speed Multipler:

If you're making ship speeds slower then it will take longer to get everywhere. One way to reduce the impact of this is to increase the speed of the torus drive.

Qualifier: I haven't tested this yet but I expect/hope it works...

The torus drive is only found on the player ship so we need the PlayerEntity.h file
If you open this file and then search for hyperspeed then the first line highlighted should be this one:

Code: Select all

#define HYPERSPEED_FACTOR				32.0

If you change 32.0 to 96.0 then the torus drive will be as fast for one of the reduced scale (and speed) ships as it will for ships in the current game (depending on the exact scaling factor that was used).

Again, once you've changed the number, save the file.

Scanner Range:

Again, I haven't had a chance to test this yet...

I think it's in the file PlayerEntity.m as SCANNER_MAX_RANGE but it's currently unclear to me exactly where the value is set.
If you search for SCANNER_MAX_RANGE within this file then the fifth one found should reveal:

Code: Select all

float		d1 = (float)(SCANNER_MAX_RANGE*((Ranrot() & 255)/256.0 - 0.5));

What makes me doubt is that it appears to exist within a placement of the ship for leaving witchspace...

Hmm... I'll get back to this one...

Rebuilding the Source:

Cim explains how to do that here https://bb.oolite.space/viewtopic.php?f= ... 1&start=63
The command line should be entered into the msys.bat file.
Note that this is not found within myoolite (or whatever you named it) but rather in <RootOfWhereTheEnvironmentWasInstalled>\msys_x2\1.0.

Testing your changes:

Instead of starting the game by clicking on oolite.exe. you'll need to start up oolite.dbg.exe
The game should then start up with your changes to the source incorporated.

Other changes will likely be necessary and can be added to this list later on but the first two should at least provide something useful for a testing environment.

What I'm trying to avoid is a repetitive domino effect of each change requiring another one in order to work as desired. There may at bit of that but I'm hoping for it to be minimal...

So, for those who are keen to do some testing, let me know what you think

Posted: **Thu Dec 26, 2013 9:23 pm**

Redspear wrote:
The torus drive is only found on the player ship so we need the PlayerEntity.h file
If you open this file and then search for hyperspeed then the first line highlighted should be this one:
Code: Select all
#define HYPERSPEED_FACTOR				32.0
If you change 32.0 to 96.0 then the torus drive will be as fast for one of the reduced scale (and speed) ships as it will for ships in the current game (depending on the exact scaling factor that was used).

Where you may find a problem just changing this constant is in acceleration and deceleration times. In particular, you need the deceleration to be abrupt enough on a masslock that you don't sail right out the other side of the masslock while you're still slowing down. HYPERSPEED_FACTOR is also used in the deceleration rate, but that's only linear, so you'll travel three times further while coming out of masslock if you go up to 96.0 here... Deceleration from torus is in the PlayerEntity.m "doBookkeeping" function if you want to make it more abrupt.

Redspear wrote:
I think it's in the file PlayerEntity.m as SCANNER_MAX_RANGE but it's currently unclear to me exactly where the value is set.

It's defined in Entity.h. You should also update SCANNER_MAX_RANGE2 (the 2 stands for "squared") to match whatever change you make to SCANNER_MAX_RANGE, or you'll get some very strange effects.

Redspear wrote:
What I'm trying to avoid is a repetitive domino effect of each change requiring another one in order to work as desired. There may at bit of that but I'm hoping for it to be minimal...

Good luck with that...

(It's still going to be a lot easier, if you're working off 1.79 which can cope with the larger world coordinates, to make everything which is not a ShipEntity 3 times bigger than to make everything which is a ShipEntity 3 times smaller. The end result will be identical in terms of gameplay)

Posted: **Thu Dec 26, 2013 9:46 pm**

cim wrote:
Redspear wrote:
The torus drive is only found on the player ship so we need the PlayerEntity.h file
If you open this file and then search for hyperspeed then the first line highlighted should be this one:
Code: Select all
#define HYPERSPEED_FACTOR				32.0
If you change 32.0 to 96.0 then the torus drive will be as fast for one of the reduced scale (and speed) ships as it will for ships in the current game (depending on the exact scaling factor that was used).
Where you may find a problem just changing this constant is in acceleration and deceleration times. In particular, you need the deceleration to be abrupt enough on a masslock that you don't sail right out the other side of the masslock while you're still slowing down.

... Tempting

...

cim wrote:
HYPERSPEED_FACTOR is also used in the deceleration rate, but that's only linear, so you'll travel three times further while coming out of masslock if you go up to 96.0 here... Deceleration from torus is in the PlayerEntity.m "doBookkeeping" function if you want to make it more abrupt.

Redspear wrote:
I think it's in the file PlayerEntity.m as SCANNER_MAX_RANGE but it's currently unclear to me exactly where the value is set.
It's defined in Entity.h. You should also update SCANNER_MAX_RANGE2 (the 2 stands for "squared") to match whatever change you make to SCANNER_MAX_RANGE, or you'll get some very strange effects.)

Thanks

cim wrote:
Redspear wrote:
What I'm trying to avoid is a repetitive domino effect of each change requiring another one in order to work as desired. There may at bit of that but I'm hoping for it to be minimal...
Good luck with that...

I know, I know but there are a lot of phantom problems at the moment. The more I try to work it out the more clear the problems will become... Hopefully

cim wrote:
[(It's still going to be a lot easier, if you're working off 1.79 which can cope with the larger world coordinates, to make everything which is not a ShipEntity 3 times bigger than to make everything which is a ShipEntity 3 times smaller. The end result will be identical in terms of gameplay)

I think I understand that too but in part I feel duty bound to try both and also there's the possibilty (unlikely perhaps) that a combination of the two may work better than either on its own.
Paradox has gone to the trouble of editing some ships at my request, it would seem cruel to abandon that avenue now.

Speaking of making things bigger rather than smaller, I seem to recall a set value for heat shielding. Can it really be that simple for addressing the sun-skimming problem that you had previously highlighted?

Posted: **Fri Dec 27, 2013 12:00 am**

Redspear wrote:
Speaking of making things bigger rather than smaller, I seem to recall a set value for heat shielding. Can it really be that simple for addressing the sun-skimming problem that you had previously highlighted?

Increasing it might help, but you should be able to sun-skim safely without needing heat shielding (it'll just be closer).

The problem on the expansion of planets side is that the masslock of a planet (or star) is proportional to its radius, so they lock you far too far out, and similarly scoop height is proportional to the radius, so you have a very long journey in.

If you don't decrease the masslock radius, you end up with it taking 15 minutes to circle the planet to the station (without injectors) if you fly into the masslocked zone.

Posted: **Fri Dec 27, 2013 1:49 am**

Here is the Scaled Adder.

DOWNLOAD HERE

Posted: **Fri Dec 27, 2013 6:48 pm**

And about the unit discussion, I found this gem in the Screenshots thread and damn near choked on the apple I am eating now:

Viewpoint is placed ~247,5 oometers right, 15 oometers above and ~247,5 oometers behind the ship.

Posted: **Sat Dec 28, 2013 2:06 am**

cim wrote:
Where you may find a problem just changing this constant is in acceleration and deceleration times. In particular, you need the deceleration to be abrupt enough on a masslock that you don't sail right out the other side of the masslock while you're still slowing down. HYPERSPEED_FACTOR is also used in the deceleration rate, but that's only linear, so you'll travel three times further while coming out of masslock if you go up to 96.0 here...

I suppose many on this forum will have seen the Elite Dangerous capital ships video?
http://www.youtube.com/user/FrontierDev ... ture=watch

Those sidewinders turn up for battle using a means visually similar to the torus-drive (from about 20 seconds into the video).
The big difference being the abrubt halt that stops them almost dead.

"Hey this isn't E.D. this is Oolite! Our inspiration is the original Elite..."
Well, that video is closer to how I remember the torus-drive on the spectrum... Speaking functionally rather than graphically of course

If the torus was tweaked to stop dead upon mass-lock or manual override, would there be any significant gameplay changes besides the cosmetic ones?

If it could simply stop, returning the player instantly to non-torus speeds, then that would mean it could remain constant (right ?) even when using different values for torus speeds that may be necessary for testing at different scales.

Besides, it might just look cool too

Paradox wrote:
Here is the Scaled Adder.

Nice one Paradox

Posted: **Sat Dec 28, 2013 7:48 am**

Without testing ... dead stop would probably be a little too abrupt, but you could increase the deceleration factor by x10 or x20 and still have it look good.

Gameplay implication: you'll come out of torus with the pirate pack on the edge of scanner range rather than at the edge of laser range, which gives you more time to react. Conversely, of course, packs more to the side of your position will be able to successfully masslock you. I do quite like the way you can be rewarded now for paying attention to the parallax of the little specks of light against the background and dropping out of torus manually, but it's probably not crucial to keep.

Posted: **Sat Dec 28, 2013 10:20 am**

Redspear wrote:
"Hey this isn't E.D. this is Oolite! Our inspiration is the original Elite..."

Do spare us the sarcasm - it becomes tiresome.

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: [RELEASE] D.T.T. Planet Express 1.0 Temporarily Unavaila

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