CaptSolo wrote: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.
I'm not the best person to be asking about either graphics or release schedule, but I'll see what I can do...
CommonSenseOTB wrote:-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.
CommonSenseOTB wrote: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.
CommonSenseOTB wrote: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...)
) but it still sounds great!