Progress

[CaptSolo]

So I am not the only one who has experienced this. On a hunch, installed r5595 on my wife's top end gaming computer and Griff's Shipset, then disabled shaders. Result: No emission lighting. I did get this in the log:

Code: Select all

17:54:55.328 [rendering.opengl.state]: Incorrect OpenGL state in -[Universe drawUniverse] (line 3754)->OOVerifyOpenGLState
17:54:55.328 [rendering.opengl.state]: Expected previous state: OPENGL_STATE_OPAQUE
17:54:55.328 [rendering.opengl.state]: GL_LIGHT0 should be disabled but is ENABLED.
17:54:55.328 [rendering.opengl.state]: GL_LIGHT1 should be ENABLED but is disabled.

[cim]

So I am not the only one who has experienced this.

No, it's a general problem, though one we weren't aware of until your previous post. We hopefully will be able to fix it (and the log errors) in time for tonight's nightly build, though that depends on our current theory about the cause and solution being correct.

@cim:

I'm not the best person to be asking about either graphics or release schedule, but I'll see what I can do...

-when I set the players diffuse map [...]

This may - and I haven't had chance to test this yet - be a texture caching issue. If you have an illumination map, then this gets combined with the emission map and the diffuse map when the textures are loaded to create a combined emission map. You may then be making a sort of change to the material definition that it thinks the cache from a different generation of that material is usable when it isn't. The key difference here with the player and NPCs is that the player's textures are never going to fall out of the cache, while the NPC ones will depending on how many are around in the player's vicinity.

A couple of potential workarounds:
- don't use illumination maps. Instead, bake the illumination map into the emission map and just have an emission map. May get complicated if you're needing to vary (illumination and/or diffuse) and emission separately, though ... .
- give the player ship a different material name to the NPC variant, which will probably require using a copy of the model.
If you could try both of those and let us know if either or both work, that may be useful for tracking down the problem (or ruling out the texture cache as a source of it, at least). If they do work, they'll probably also work in 1.76 - but we'd obviously want to fix the underlying bugs so they wouldn't be permanent workarounds.

Also, on a recent test for a temporary glow feature when hitting an unshielded hull, the illuminations modulate color would only work if the value was "1.0 0.0 0.0" where "0.99 0.0 0.0" would not work. This is definately a bug of some kind.

Might be part of the same issue, might not. If it's not, that seems unusual.

I just thought I would report this and ask if there will be at least until the end of february before 1.77test is released.

We don't at this stage know exactly when the release will be. However, it hopefully won't make any difference to your work.

If you manage to get your OXP out before 1.77 is released, then bugs which are found will probably also be fixed before 1.77 is released. If you don't manage to do this, however, there are two possibilities:
- there are no bugs, or at least no serious ones, and 1.78 is released with the necessary fixes.
- there are major bugs, the fixes for which we feel need wider testing, and 1.77.1 is released. 1.78 then follows after we're confident the fixes were correct. (Or 1.77.2, .3, etc. as necessary)

We expect 1.77 will have a number of serious but currently unknown bugs, and the point of the test release is to make the code previously only used by a handful of dedicated testers available to a wider audience for testing - and much of the new code is for OXP writing, so time too for OXP writers to actually try the new features, give feedback and have their OXPs get some live testing too. We wouldn't want to release 1.77 with known bugs - especially not regressions from 1.76 like the one Capt. Solo found - but we're not too concerned about releasing it with unknown bugs - it's the 1.78 stable release for which those need to be located and removed. (And I can say quite confidently we won't be releasing that before the end of February...)

[CommonSenseOTB]

@cim:It's funny you should mention giving the player a different model with a different texture defined as that is what I tried last night. Doesn't work. However, combine that with also a different diffuse map in the setMaterials dictionary and then it does work. My problem is solved.

No problems on my limited hardware even running 1024x1024 maps for both player and npc, although a bit choppy and shouldn't be for better computers as I can run 512x512 maps and it is reasonably smooth and acceptable with full detail.

What you say about the texture caching actually makes sense from my observations of what was happening. The above solution works for both 1.76 and 1.77trunk. I'll wait to upload latest trunk with the fix for solo's problem to see if it still works well for me. The other idea of using a combined emissions and illuminations map was something I thought about before but with the way I'm combining all the maps to create specific effects, this will prove impractical.

Thanks for the help cim. Looks like its probably in the texture caching. I'll burn some rubber now and get my oxps out for real testing on this ASAP.

[cim]

@cim:It's funny you should mention giving the player a different model with a different texture defined as that is what I tried last night. Doesn't work. However, combine that with also a different diffuse map in the setMaterials dictionary and then it does work. My problem is solved.

That makes sense. What shader mode does this happen in, or doesn't it matter?

[CaptSolo]

The lights are back! Many thanks.

[CommonSenseOTB]

@cim:It's funny you should mention giving the player a different model with a different texture defined as that is what I tried last night. Doesn't work. However, combine that with also a different diffuse map in the setMaterials dictionary and then it does work. My problem is solved.

That makes sense. What shader mode does this happen in, or doesn't it matter?

No shaders enabled.

[CommonSenseOTB]

It would seem there are still problems with the materials in oolite 1.77. Currently, the only reliable way to make my customships oxp random paintjobs work is with a "" diffuse_map. It may be a hardware issue, but I suspect not as something that was changed just prior to the release of 1.77 has made things worse actually. When I release my oxp this problem can be properly troubleshooted so we can crush this bug for 1.77.1 perhaps? Just a heads up to the devs that 1.77 materials has some issues.

[cim]

Just a heads up to the devs that 1.77 materials has some issues.

If you have a working-enough OXP to be able to demonstrate the bug, then if you PM me a download link for it I can try to figure out what's going on.

[CommonSenseOTB]

Just a heads up to the devs that 1.77 materials has some issues.

If you have a working-enough OXP to be able to demonstrate the bug, then if you PM me a download link for it I can try to figure out what's going on.

Allright, there are some loose ends to tie up first but I'll see if I can get you something to test by the end of next week or as soon as is possible.

[CommonSenseOTB]

Just a heads up to the devs that 1.77 materials has some issues.

If you have a working-enough OXP to be able to demonstrate the bug, then if you PM me a download link for it I can try to figure out what's going on.

Allright, there are some loose ends to tie up first but I'll see if I can get you something to test by the end of next week or as soon as is possible.

Check your PM's cim. A test oxp package for this materials issue is available for download. Good luck cim and let me know what you find out.

[cim]

<brushes dust off thread>

One of the advantages of moving to Github for source control is that we can work on 1.78 and 1.79 at the same time without ending up in a horrible mess. So, some recent additions to the 1.79 path (thanks to everyone who's commented on the proposals so far):

• shipdata.plist reorganised to make future changes easier to integrate with OXP shipsets
• wormholes now have a mostly read-only Javascript representation
• strict mode replaced by an "enable/disable OXPs" switch
• a very large list of extra ship methods and event handlers to reduce the number of things which can only be done in AI, not JS. These will all be documented at some point...
• a few other JS additions: oolite.gameSettings.keyConfig may be of long-term interest for tutorial OXPs
• the new Javascript-configured system populator is running. This behaves approximately the same as the old populator, at the moment, but I'll start a discussion on potential changes once I'm more confident it is stable. There's also a new system repopulator, which replaces pirates and bounty hunters if their numbers run too low. The settings for this one are very experimental at the moment, and the way it adds new pirates is temporary. I've also added a repopulator to interstellar space.
• World-space coordinates are now double-precision. Previously, the graphics and game engine would start looking very odd once you got much over 10^6 metres from the origin, with the engine flares being the first to go. The AI, docking, collision detection, etc. all broke down. Increasing the precision means that - give or take the occasional bug - you should be able to get much further from the origin. Everything seems to work fine in testing out to 10^14 metres now, though you probably don't need to go that far...

There are also various bug fixes, which apply to the 1.77 code too.

• Savegame list is sorted alphabetically
• Flashers on visual effects are scaled properly
• A few other scripting bugs

[Diziet Sma]

Oh my.. you guys have been busy.. kudos!

[Redspear]

I think I only understood half of that (and I might be flattering myself there ) but it still sounds great!

Nice one

[Cody]

Oh my.. you guys have been busy.. kudos!

Agreed!

[Smivs]

Good work cim. It's great to see the game continueing to develop like this.