Trunk nightly

[spara]

Does it only affect updated/new OXPs?

[cim]

Does it only affect updated/new OXPs?

It should already default to "blank" for max version for new OXPs - or whatever it was set to previously for existing ones.

I did need to add some extra options in preparation for 1.82 being released, so maybe I broke something there. I need to do a bit more work pre-release on the admin pages anyway, so I'll check it out then.

[Norby]

I got an oddity during developing [wiki]Trails[/wiki]: if a standard subentity contain flashers within then these are not shown correctly on my machine. Here is the test part of effectdata.plist:

Code: Select all

	"trails2" = {
 		subentities = (
			{	type=standard; position=(0,0,0); subentity_key="trails--"; },
			{	type=standard; position=(0,0,-10); subentity_key="trails--"; },
		);
	};
	"trails--" = {
		subentities = (
			{	type=flasher; position=(0,0,0); frequency=0;
				phase=0; size=30; color="1.0 0.075 0.15 0"; },
		);
	};

The idea behind this is continually repositioned subentities to reduce the number of needed entities from 50 to 1 for each trail by packaging the trail elements into subentities.

Flashers are not accesible in the subentities array in js, so I must place these into a sub-subentity and move the position of the standard ones, but in this case I do not see the normal trail with 100 flashers, just two of them in wrong positions (see below the red balls far from the ship, I changed the color for visibility). Moreover these are turning on an off rapidly, about 5 times in a second. Is this a bug or a missing feature?

[cim]

I got an oddity during developing [wiki]Trails[/wiki]: if a standard subentity contain flashers within then these are not shown correctly on my machine.

Confirmed - and would apply to shipdata as well as effectdata. If a flasher is more than one level down, the OpenGL ModelView matrix is set up from the wrong baseline. I'll see what I can do about it.

EDIT: this should be fixed in tonight's build - at least, your test case works. Thanks for reporting it.

[Norby]

If a flasher is more than one level down...

Thank you, the position is fixed now, but when I use addVisualEffect from script then the flasher show for a moment only then disappear instantly (I guess in the next frame due to it was very hard to make a screenshot with the flasher), this is why can not build up the whole trail. My previous script added it repeatedly after a ship each time when travelled more than 20 meters, this caused the mentioned turning on-off effect.

If I add it from debug console then does not appear at all. I tested under Windows+Nvidia card also in addition to my Linux+Intel HD4000 to close out driver problems.

[cim]

Odd - your test case worked fine for me with the flasher effect being persistent. I can't think of anything which would cause that: if you do system.allVisualEffects from the console are they still in the system?

[Ngalo]

Sorry to have to report this when 1.82 is so close to release, but I've found a slight bug in the new nav charts.

If I save the game with the chart zoomed out in long-range mode, the savegame has a "chart_zoom" of 4, which is (I assume) perfectly OK. The problem arises on loading such a game, whereupon I find that the chart is stuck in 'zoomed-out' mode; pressing 6 toggles it between short-range and long-range behaviours in other respects (i.e. system name search) but doesn't change the zoom.
Editing the savefile to reset chart_zoom to 1 seems to fix the problem (until I absentmindedly do the zoom-out-and-save routine again).

I am using build 1.82.0.6488-150426-a0df280 on Debian 7 (Wheezy).

[Norby]

if you do system.allVisualEffects from the console are they still in the system?

Yes, and no problem in shipdata, just in effectdata.

I found a workaroud: if I put a flasher to the top level also then all shown well.
This require at least the same size for the top-level flasher than the size of the others, else when the engine decide to do not draw this flasher anymore due to the small size from the current distance then others are not shown also. I tried with 1m size in the first level one and all flashers in subentities with 30m size was suddenly hidden also when I reached more than a few hundred m distance, and drawn again when I went back to within this border.

[another_commander]

Sorry to have to report this when 1.82 is so close to release, but I've found a slight bug in the new nav charts.

Thank you for reporting this and please don't feel sorry for the timing. It is exactly for getting things like this that we are going into a month-long freeze and it's best to get any problems now rather than after release.

With regards to the issue at hand, have you tried zooming in and out once the chart has been shown? It seems to work fine for me here using PageUp/PageDown or mousewheel. However, you are right that the behavour is not the same as when you manually zoom out completely and then try to switch chart mode. It seems to be an inconsistency glitch, but thankfully manual zoom still seems to work.

[kanthoney]

Sorry to have to report this when 1.82 is so close to release, but I've found a slight bug in the new nav charts.

If I save the game with the chart zoomed out in long-range mode, the savegame has a "chart_zoom" of 4, which is (I assume) perfectly OK. The problem arises on loading such a game, whereupon I find that the chart is stuck in 'zoomed-out' mode; pressing 6 toggles it between short-range and long-range behaviours in other respects (i.e. system name search) but doesn't change the zoom.
Editing the savefile to reset chart_zoom to 1 seems to fix the problem (until I absentmindedly do the zoom-out-and-save routine again).

I am using build 1.82.0.6488-150426-a0df280 on Debian 7 (Wheezy).

Fixed in tonight's build. Thanks for the report!

[vsfc]

Hi Commanders,

Congrats on getting the 1.82 version freeze.

I got the trunk version of it and played a new Normal commander with only LogEvents extension installed through OXP manager.
While docked at the station I got the following messages repeatedly recorded.

TL99 is deprecated for EQ_MILITARY_SCANNER_FILTER
TL99 is deprecated for EQ_MILITARY_JAMMER

I managed to get rid of them by editing Resources\Config\equipment.plist file and changing TL 99 to a 100 for these equipments.
The rest so far looks great and I love new explosion affect for asteroids!

Hope this helps.

Cheers,
VSFC

[cim]

I found a workaroud: if I put a flasher to the top level also then all shown well.
This require at least the same size for the top-level flasher than the size of the others, else when the engine decide to do not draw this flasher anymore due to the small size from the current distance then others are not shown also. I tried with 1m size in the first level one and all flashers in subentities with 30m size was suddenly hidden also when I reached more than a few hundred m distance, and drawn again when I went back to within this border.

Could you give an example effectdata for this, please? The size of the effect should be considered at least the size of its largest subentity (recursively), and the draw distance calculation is usually fairly conservative in what it culls.

[cim]

TL99 is deprecated for EQ_MILITARY_SCANNER_FILTER
TL99 is deprecated for EQ_MILITARY_JAMMER

I think this should be fixed in tonight's build in a way that's compatible with OXPs - TL99 only matters anyway for OXPs which make them available for purchase on F3, and since they've never had "available_to_all" on them that wouldn't do much good anyway, but setting the special mission variable should still work.

If you use the TL99 feature on these, though, it might be worth checking your OXP before release so this can be backed out if necessary.

[Norby]

Could you give an example effectdata for this

Yes. Put this into Trails 1.2 and all ships within 10km should make red trails when FPS is not too low but I see only the nearest part of the trail when I follow a ship from about 1km. Confirmed again under windows also in the tonight's build. As you think my guess is the missing recursivity.

[cim]

I see only the nearest part of the trail when I follow a ship from about 1km

Ah - this is something slightly different, then. Subentity drawing draws each subentity as if it were an individual thing - the original expectation being that you'd have a ship model (large) with subents (small) on it, so you could safely drop the subents from drawing at long range to get a basic Level-of-Detail optimisation.

The problem is I think then with the no-draw distance in the first place. At the moment something will cease to be drawn once the camera is more than around 1450 times its radius away (or equivalent to subtending an angle of around 0.08 degrees). With a 1920x1080 display at default FOV setting that's still 2 and a bit pixels wide when it vanishes.

With variable FOV and much more variable display hardware than there used to be we probably need to start adjusting the no-draw distance to the actual display settings. In the meantime we could raise the constant value, though this might cause slower performance on old hardware which can't reliably see that far anyway - is anyone around with some old (probably looking for no-shader era) hardware to test this with?