Split: Re-scaling experiment

[Redspear]

OK, off I go...




Leesti is fairly asteroid rich and there are some of the new large type near the witchpoint buoy.




They might appear a bit too big but note how little of the distance to the planet I have travelled in order to get close to them.




And sure enough, they are pretty big...




The distance from the cobra is comparable with that taken in the screenshots thread and yet the asteroid now almosty fills the screen.




The 'normal' size again for convenience:




The shift in camera angle isn't helping here but they don't look massively bigger to me. I'll have a try with a 6.6 multipier but any more than that will likely undo some of the other rescaling work IMHO.

As an aside, I was having trouble getting the alternate sizes to show up when using like_ship references and so had to overwrite the default asteroid template... perhaps I was just unlucky.

[Redspear]

Well, 6.6 is certainly bigger.



You might be able to make out the light catching some other asteroids directly between me and the planet.


Because they are no further apart than before, there can also be the feeling of entering a (very, very small asteroid field - a park perhaps)




The scanner tells its own story here I think...




As does this image.




So, bigger definitely but is it any better?
Perhaps these shots might help.



Yay! I'm in an asteroid field!... sort of


Beneath the shadow.




Gulp!

[Disembodied]

I think these look great, Redspear. I know these are just tests: I think that it would increase the sense of scale still further if large asteroids stood alone (or on their own within a cluster of smaller rocks).

[Redspear]

Thanks Disembodied and I agree with your suggestion.

I need better to understand how asteroids are chosen in game because it always seems to pick the same type at the moment.
Probably a simple mistake/fix once I realise what's going on.

[Redspear]

Main suspect for grouping 'samey' asteroids together is currently this line in oolite-populator.js

Code: Select all

var rocks = system.addShips("asteroid",size,pos,25E3);

"asteroid" in shipdata.plist references the standard asteroid rather than any of the alternatives, so getting the populator to select by role rather than by name might solve the issue.
Trouble is, changing addShips to either addShipsWithPrimaryRole or addAsteroid only results in no asteroids and errors in the log relating to them not being functions.

Am I looking in the wrong place or just declaring the wrong functions?

Can any devs help point me in the right direction please?

[another_commander]

addShips already uses roles for selecting the ships to add. The "asteroid" parameter is the role. So, according to shipdata.plist, it can select either a standard asteroid or an alt one.

addAsteroid doesn't seem to exist anywhere so errors are expected if you try to use it.

I guess if you want to specifically spawn an alt asteroid and don't want to depend on luck, the simplest way would be to try enclosing the name of the asteroid as it appears in shipdata in square brackets when invoking addShips, something like
[b]var rocks = system.addShips("[asteroid-alternative]",size,pos,25E3);[/b]

[Redspear]

That's odd. All the new asteroids I've created have like_ship refernces and individual names (for testing) and yet it always seems to pick the defaul asteroid, always surrounded by the same

I'll try adding the roles parameter to each alternative in shipdata.plist and see if that makes any difference.

Thanks a_c.

[Redspear]

Success!

(Silly mistake with templates in shipdata.plist)







OK, so I upped the asteroid count a bit but it was all playable and they ranged in size from small to huge.

[Redspear]

After some testing of laser ranges divided by 4.5 and then by 4 I've come to some early opinions.

4.5 is too much - only faster ships or those with fuel injectors could fire at me, even if I simply headed for the station without any evasive action of fuel injectors.

Dividing by 4 makes most ships appear twice as big (remembering that scanner range and many ship sizes are already halved).
That makes such ships identifiable at typical firing range.
If I am correct in this regard, then I shouldn't need to tell you what the ship below is...





...you shouldn't have needed to 'cheat' and read the ID legend.

Remember also that these images have been shrunk, so that their size is only proportionally accurate.


Managed to get in the middle of a scrap and yet struggled to capture any decent images:





Although I didn't do it justice, the feeling of the large python (original size) amongst the fighters (one third original size) was very satisfying.

So, dividing by four looks good but some of those problems mentioned earlier still remain - the cobra mkIII is just too fast...
As has been discussed, there are important reasons for that speed and without tackling those, the range is still a little too short.

I think if you're being attacked by pirates with pulse lasers thenm they should at least be able to get a few shots in before you escape and if the pirate has a beam laser then you should at least need to employ some evasive manouvers.

Options:

• Stick with laser ranges divided by 3 - most ships will still appear slightly bigger, freighters significantly so.
• Reduce speed of the mkIII - raises other issues and so perhaps best avoided
• Increase pulse laser range - been suggesed before but needn't exceed beam laser range

The first one of these is well tested and improves on the default game IMHO with no targeting/closing issues.
The last one remains untried but could be useful if laser ranges somewhere between 0.33 and 0.25 were to be more fun.

[Redspear]

Whilst in testing mode I thought I'd have another look at this.

Tried ranges divided by 4 and pulse range boosted to equal beam range.
The slower ships just couldn't get a shot in.

A big motivator here is that ships be more visible and the experience be more like dogfighting.
Laser ranges /3 does work and results in the largest ships appearing 3 times bigger (when in range) and medium sized vessels 1.5 times bigger than before, with the smallest ships appearing as before.
I could try ranges /3.5 but the benefit would likely be marginal.

Another option would be to reduce the scanner range.

I did briefly test this before the first release of this (2014?) and in rejected it at the time due to it being too easy to overshoot when approaching a station (with the reduced catchment area) and also in my efforts to disturb the status quo as little as was necessary in order to show that rescaling could work.

Perhaps it's worth testing again as it might also help with masslocking issues.
A ship travelling at half speed within a third scale scanner would clear the scanner at 3/2 = 1.5 times the speed it did before, reducing typical masslock times by 33%.

Slowing the cobra mk III could even be an option then - back to 0.3 and it would onl have lost approx 15% of its speed.
33% less masslock with 15% less speed might sound like a winner but crucially it is the speed difference rather than the overall speed that relates to masslock escape.

Another effect of a reduced scanner would be that fighters appear no smaller than in the standard game with regards to scanner range but other ships would appear larger. With the scanner set to half distance (as I have done in all previous versions) there is a nice balance of the smaller ships looking tiny in relation to the scanner and the largest ships looking big. The benefit to the smaller ships would be lost (at scanner /3) but then it is the large ships were it would be most noticeable so it might still be worth testing.

A smaller scanner range would mean that aggressors begin their attacks closer to the player and so should have more time to get a few shots at an escaping player and may even allow laser ranges to be shruck a little further.

I think I'll have to test the scanner idea again as stations and freighers appearing bigger is perhaps more of a boon than a curse.

[Redspear]

Tried rescaling the scanner to 0.33 rather than 0.5...

Only an initial test so far but early indications are VERY promising

I've got some screenies to post when I have more time but for now a brief summary.

Visuals:

• Fighters still appear tiny when on the edge of the scanner.
• Freighters are recognisable on the scanner edge (e.g. "that must be a python")
• Station masslocks you a little later (of course) and so looms larger, earlier.

Gameplay:

• Masslock duration is significantly reduced
• Ships have a better chance to open fire on the player (even with laser ranges at 0.25)
• It is slightly easier to overshoot a compass target but it's not the sort of mistake you're likely to repeat unless you're being careless
• Docking time is slightly more generous

To Do:

• Distance between station and beacon exceeds the radius of the scanner and could benefit from being brought in a touch. As I think this might not have been adjusted for the last build anyway (I don't think I could find the line in the more recent code) halving the distance would probably be more consistent with ship speeds anyway.

Overall Impression:

• I can only assume I was being concerned with not making the first rescale attempt too different from standard oolite when I rejected this change. For the first time in ages I disabled Variable Masslock oxp (hesitantly) and yet masslock events didn't seem to bother me (it was only one test however, so I may be getting carried away ) Big things look big earlier and yet small things remain small - this needs pictures to illustrate properly but I think I captured it quite well with some screenshots (to follow).

Other Issues (unrelated to scanner):
One of the reasons that ships are struggling to catch the mk III at reduced laser ranges (should the player decide to run straight for the planet) is their preference to attack from behind. By the time they are in position, the slower ones are simply out of range. On the rare occasion that I was attacked from the side the range problem wasn't evident. Sounds like an AI issue but I still think there are more adjustments I can make to remedy this (especially in a reduced scanner environment).

[Redspear]

I've got some screenies to post when I have more time

But first, what is this?







This was spotted recently but before the scanner rescale. It almost looked like an astrological feature (especially as it could neither be approached nor evaded from what I could tell).

First sign of a rescaling bug perhaps? I hadn't seen it before nor have I since.


OK, now back to the scanner...


Firstly although it is at 33%, unless you're very familiar with this thread, 66% is probably a better way to think of it in terms of how it relates proportionally to the standard game.

So, how big do ships appear at that kind of range?
Bearing in mind the rescaling factors to ships that have already been applied in this experiment, the following pictures provide some answers. If you have trouble seeing the smaller ones then remember that the scanner gives you their approximate location.

Small ships at long(ish) range:




Big Ship near the scanner edge.




Medium ship at medium range (we're looking at the far cobra in this image )




Medium small ship at extreme range.




And arriving at the station.




With some work to be done to bring the buoy in a little.




So, ships are hardly getting close before the scanner can spot them.

As for things being visible before they register on the scanner I think that particular horse has long since bolted even in the standard game with regards to stations etc. (besides, that's what the compass is for I suppose).

Yes, the station masslocks you pretty close but remember that in this version it takes you twice as long to cover the distance (speeds halved); it's not something that I see as a problem.

As for ship masslocks the first test was glorious (I must do more). Trimming off 33% might not sound like that much but then it's that 33% that is the most annoying (i.e. the annoyance increases with time spent in masslock). Even without updating the lane width encounter rates seemed fine.

More to do, with a another possible soulution the the laser range conundrum...

[Redspear]

No progress on laser ranges yet but got some more testing done with the new scanner.

Impressions are still very positive.

Some observations when the player simply heads in a straight line and waits for masslocks to clear:

• When combined with the AI evading the player (angling sideways) masslocks usually last no more than 2 minutes and sometimes less than 1 (comparable with elite).
• When the AI ignores the player (no evasion) then masslocks can take quite a bit longer. The longest so far was a fer de lance at 4mins 30 but more common would be 3mins.
• Some ships (e.g. pythons) never seem to avoid the player whilst others do somtimes and others seemingly all the time.
• The longer duration masslocks, whilst irksome, are less common and so cause less annoyance.
• With a smaller scanner to escape, AI evasion tactics can make a big difference.

I would like to know what makes a ship attempt to evade the player (outside of combat)?

Is it determined by relation to player ship max speed?
In relation to 0.35LM? (regardless of player ship)
Ship role?

It seems to me that if this behaviour were more common then most if not all of the 2 minute plus masslocks could be cut.

Whether as part of the rescaling experiment or not I think a smaller scanner (66% of norm) has a lot to offer the game.
At present, I cannot think of any real drawbacks to doing so.

[cim]

I would like to know what makes a ship attempt to evade the player (outside of combat)?

Player perceived role, their role, and in some cases whether or not the NPC feels it can outfight the player.

[Redspear]

Thanks cim.

That makes sense I suppose.
Gameplay wise it might be nice if they also moved when peaceful and ship speeds were similar.

Quick test of masslock times in the standard game using the method described above:

I was getting masslocks of 6-9 minutes with an average of around 7 mins.
So the reduced scanner appears to be cutting masslocks by about 5 minutes (based on very limited, unscientific testing)