Thanks for checking Griff -it's really very odd. The value just seems to be completely ignored on my system. I can even delete the whole Decal1_Rotation key from shipdata, and the decal is still rendered on the ship in the same orientation as it always it. I've double checked that my flush is caching cache is flushing and shader debug confirms that the uniform is not being set up when the ship is loaded with the key deleted, but the decal is present and correct in what seems to be a default orientation for me with no log errors.
Makes it a bit difficult to test the code for the OXP.....
I think what I'll do is finish 0.3 with just the RGB and entityPersonality based colour changing, then code the decal switching for a version 0.4 and just cross fingers that the rotation works for other folk. At least I know the sensible limits for the rotation - I guess you were working on an upper limit of PI and a lower limit of -PI, with 2PI radians being equivalent to a full rotation?
Edit - Thanks to Wildeblood for spotting my early morning dyslexia...as he pointed out you probably don't want to cache my flush
I think what I'll do is finish 0.3 with just the RGB and entityPersonality based colour changing,
And v.0.3 is now available for download - link in first post.
v.0.3 – Added RGB colour mixing. Added ships from Griff’s Player Flyable NPC ships as options. Added precision toggle for so user can make fine or coarse adjustments.
I noticed in the screenshots you posted recently demo'ing the new paintmaps that the decals were in a different rotation than usual, i just thought you'd customised them but maybe for some reason like you suspect there's something in the opengl implementation in your graphics driver that's not reading the float from oolite properly.
Ahruman's just this weekend modified Oolite to accept vec4 passed to it as shader uniforms from the shipdata.plist, this means that the rotation doesn't need to be in it's own float any more and can be part of the position & scale settings, i'll have a bash at whipping up a modified shader and we can see if it works on your system
Awesome work on this oxp, just had my first go with it!
Is there any way to remember the last adjusted colour component and return to that one after each adjustment? at the moment it always goes back to the 'Increase Red Component' which can make adjusting the blue or green fiddly if you don't keep an eye on what you're doing.
Oo, any maybe on the 'adjust first/second paint colour' screen, is there a way to temporarily highlight that paint map on the model as the player scrolls through the options on the menu, maybe make that corresponding paint map turn lurid green or something?
Is there any way to remember the last adjusted colour component and return to that one after each adjustment? at the moment it always goes back to the 'Increase Red Component' which can make adjusting the blue or green fiddly if you don't keep an eye on what you're doing.
I should be able to implement that, but it would probably have to be by reordering of the menu items depending on the last clicked/selected choice, so it is first on the list when the missionScreen is redrawn. I'm not sure if that would be confusing or not. It may depend on whether the player tends to use the keyboard or mouse clicks to select menu options (I'm the latter). I'll try it and see.
Something that may help make it less fiddly which is in the next version is rather than always increasing the value, and then cycling to the lowest value when it hits a ceiling you can choose whether each adjustment is positive or negative as well as the size of the adjustment.
Griff wrote:
Oo, any maybe on the 'adjust first/second paint colour' screen, is there a way to temporarily highlight that paint map on the model as the player scrolls through the options on the menu, maybe make that corresponding paint map turn lurid green or something?
I don't think that can be done - but how about rather than starting out with the RGBs as two lots of zeros they both start with a colour and a verbal description of the colour is on the choice menu e.g "Adjust First Paint Colour (default pink)" or similar. I think that would work.
I should be able to implement that, but it would probably have to be by reordering of the menu items depending on the last clicked/selected choice, so it is first on the list when the missionScreen is redrawn. I'm not sure if that would be confusing or not. It may depend on whether the player tends to use the keyboard or mouse clicks to select menu options (I'm the latter). I'll try it and see.
Since this is a trunk-only OXP (and since this same issue has been bothering me for New Cargoes), it might be more useful if I added an initialChoiceKey option to mission.runScreen, to which you could pass the key of the previously-selected choice to have the next mission screen start with that one selected.
Since this is a trunk-only OXP (and since this same issue has been bothering me for New Cargoes), it might be more useful if I added an initialChoiceKey option to mission.runScreen, to which you could pass the key of the previously-selected choice to have the next mission screen start with that one selected.
Sounds like a much better solution cim - yes please...
Since this is a trunk-only OXP (and since this same issue has been bothering me for New Cargoes), it might be more useful if I added an initialChoiceKey option to mission.runScreen, to which you could pass the key of the previously-selected choice to have the next mission screen start with that one selected.
Sounds like a much better solution cim - yes please...
And if you are at it... mouse coords exposed to JS... and a small clicky handler...?
And if you are at it... mouse coords exposed to JS... and a small clicky handler...?
I could this with that....
Griff wrote:
Oo, any maybe on the 'adjust first/second paint colour' screen, is there a way to temporarily highlight that paint map on the model as the player scrolls through the options on the menu, maybe make that corresponding paint map turn lurid green or something?
Since this is a trunk-only OXP (and since this same issue has been bothering me for New Cargoes), it might be more useful if I added an initialChoiceKey option to mission.runScreen, to which you could pass the key of the previously-selected choice to have the next mission screen start with that one selected.
Sounds like a much better solution cim - yes please...
Just tested r5025 - this works well. Cheers cim. Just a few more tweaks and a round of internal testing to go so v 0.4 with decal switching/adjustment and compatibility for the extra ships mentioned by EV should be ready sometime over the weekend.
Version 0.4 is now available - needs Ship_Storage_Helper v.20 and a trunk build after r5025.
v.0.4 – Added decal switching and adjustments. Various tweaks to the menus to make more user friendly. Added the multidecal versions of the standard and scuffed cobra III as options.
Included decals are courtesy of Diziet Sma and are re-distributed under the CC-BY-NC-SA 3.0 licence.
Just tested this amazing OXP with Oolite 1.77 and it works really well! would you mind if i linked to this thread on my Wiki page for my shipset? It's pretty much an essential companion OXP for my shipset.
It looks like the decal rotation stuff works now too - at least it does for me (windows7, nvidia graphics card) i didn't realise you'd fixed it! - i can rotate, rescale and reposition the decals and they get saved to the ship (although they default to their original positions on the load/save commander screen but i expect that's because Oolite reads the settings from the shipset oxp for this screen and not the updated settings from this oxp)
![[EliteWiki]](/images/elitewikismall.png){kind=small}
Capt. Murphy's OXPs
