Oolite Bulletins

El Viejo wrote:

Are these any use for decals?

I got all excited when you posted that.. thought I might get to see some of your creations..

Then I clicked on the link.. oh darn, they're mine..

<grins>

Capt. Murphy wrote:

Apparently there is a permanent fix that could be applied to shipdata.plist - Svengali pointed me in the direction of this post.

Are we sure this totally works? i could have sworn i tried in out in the shipset then noticed that the alertlevel no longer worked *shrug*
I'll have another look at it again this evening and add it into the griff shipset 'addition' & 'replace' OXPs - i probably just made a mistake or something when i tried it last time.

Amazing work on this oxp Capt. Murphy! If you can get the decal placement thing working then i and the shift key on my keyboard will be eternally greatful! It takes loads of fiddling with the shipdata placement values and starting/re-starting the game to get those little devils placed properly!

Griff wrote:

Capt. Murphy wrote:

Apparently there is a permanent fix that could be applied to shipdata.plist - Svengali pointed me in the direction of this post.

Are we sure this totally works? i could have sworn i tried in out in the shipset then noticed that the alertlevel no longer worked *shrug*

This is what I found, then and now!

yeah, i just tried a quick test now, i don't think this is a working fix - it makes the error go away in the log, but the shaders no longer respond to changes in the alertLevel value, they just remain at level 0 which is 'docked - lights off'. I'm sure it's more to do with player only shader uniforms being applied to a copy of the player ship on the demo screen/shipyard screen etc - i don't know why i think this, i definately didn't work it out for myself

Griff wrote:

I'm sure it's more to do with player only shader uniforms being applied to a copy of the player ship on the demo screen/shipyard screen etc - i don't know why i think this, i definately didn't work it out for myself

You are right Griff. It also happens when showing the player ship on a missionScreen, and it's simply because when a player ship is being displayed in this way (all use the demoship method) it is effectively a NPC and NPCs don't have alertlevel. For this OXP I can work around it by temporarily removing the alertlevel uniform binding before displaying the ship, otherwise the player will probably panic when they see hundreds of these messages in the log (each type an adjustment is made it redisplays the ship on the missionScreen), but in general I think it just needs to be seen as an essentially harmless informational report.

Glad you like the OXP Griff, v3 should hopefully be ready sometime this weekend. RL has been a bit hectic this week so I haven't really had time to work on it since Sunday. But the RGB adjustment is all working well, the decal switching is working, now just need to do the adjustment of the rotation (easy) and position (slightly more challenging). I'll also double check the ships from the the griff_shipset_player_flyable_NPC_ships.OXP to see if they are suitable for inclusion. (BTW - I think you should add that OXP to your wiki page as a direct link - I didn't know it existed until a recently, and thought Illicit Unlock was the only option.).

Decal positioning may look weird as you're testing your code as it's heavily dependant on how the UV's are laid out in the model UV map, some UV's are placed at crazy angles which will mean that the decal moves slightly diagonally across the hull when adjusting one of the position values, so don't be perplexed if you see this happening as you're working on your code

I can't remember if i commented any of the shader code properly, but if needed the "decal scale & position" vec3 in the shipdata.plist is as follows,
first component = U (horizontal position),
second component = V (vertical position),
third component = Decal scale (a bigger number makes for a smaller decal)

I'll add a link to the NPC shipset on the wiki, this oxp should get listed there too i think as it and the more vibrant paintmap oxp sound like they're going to be an essential companions oxps when ready

Capt. Murphy wrote:

NPCs don't have alertlevel.

Would you like them to? As a shader-only property, since I don't see a lot of use for it in AI, but it would be easy enough to determine when they were at CONDITION_DOCKED, CONDITION_YELLOW or CONDITION_RED based on other factors. (Any time the player is close enough to see them, they won't be at CONDITION_GREEN, of course)

cim wrote:

Capt. Murphy wrote:

NPCs don't have alertlevel.

Would you like them to? As a shader-only property, since I don't see a lot of use for it in AI, but it would be easy enough to determine when they were at CONDITION_DOCKED, CONDITION_YELLOW or CONDITION_RED based on other factors. (Any time the player is close enough to see them, they won't be at CONDITION_GREEN, of course)

I would like them to. One thought that immediately comes to mind (and something I would like to do) is have a 'Chameleon' ship which switches texture when it is on Red Alert. Maybe I'm missing something, but how else could you tell if an NPC is at Condition Red in a way that could be manipulated by scripting?

Smivs wrote:

cim wrote:

Capt. Murphy wrote:

NPCs don't have alertlevel.

Would you like them to? As a shader-only property, since I don't see a lot of use for it in AI, but it would be easy enough to determine when they were at CONDITION_DOCKED, CONDITION_YELLOW or CONDITION_RED based on other factors. (Any time the player is close enough to see them, they won't be at CONDITION_GREEN, of course)

I would like them to. One thought that immediately comes to mind (and something I would like to do) is have a 'Chameleon' ship which switches texture when it is on Red Alert. Maybe I'm missing something, but how else could you tell if an NPC is at Condition Red in a way that could be manipulated by scripting?

Generally I would just check if ship.hasHostileTarget is true. (Technically this is "trying to kill something" rather than "something trying to kill it", but with NPCs the two are basically equivalent. "Running away really fast" under performFlee counts as true...)

hasHostileTarget is already available as a shader uniform for NPCs, of course, so all NPC alertLevel would do is mostly duplicate that so you could use the same name for both.

Thanks Cim. That might do the trick...I'll have a play with it and report back...

Well it seems to work fine - I opted for 'shipTargetAcquired' and 'shipTargetLost' in the end.
I have a working 'Chameleon' ship which changes colour/texture when it has an active target and reverts to the original when the target is lost for any reason.

By the way, the Wiki has a few typos here...refering twice to 'shipLostTarget' which should be 'shipTargetLost' I think.

Smivs wrote:

By the way, the Wiki has a few typos here...refering twice to 'shipLostTarget' which should be 'shipTargetLost' I think.

Fixed. Thanks.

Griff wrote:

Decal positioning may look weird as you're testing your code as it's heavily dependant on how the UV's are laid out in the model UV map, some UV's are placed at crazy angles which will mean that the decal moves slightly diagonally across the hull when adjusting one of the position values, so don't be perplexed if you see this happening as you're working on your code

I can't remember if i commented any of the shader code properly, but if needed the "decal scale & position" vec3 in the shipdata.plist is as follows,
first component = U (horizontal position),
second component = V (vertical position),
third component = Decal scale (a bigger number makes for a smaller decal)

I'll add a link to the NPC shipset on the wiki, this oxp should get listed there too i think as it and the more vibrant paintmap oxp sound like they're going to be an essential companions oxps when ready

I've hit a bit of a barrier with the decals - in that changing the value of "Decal1_Rotation" whether in script or by shipdata.plist edit doesn't have any effect on the end result. I've run it with ShaderDebugOn and it's not reporting any errors and is correctly picking up the new value, but the decal is in exactly the same orientations as always.

This is after editing the regular griff cobra III entry in shipdata.plist from "-0.73840" to "2". But the decal is in exactly the same orientation as before.

10:18:59.054 [shader.uniform.set]: Set up uniform <OOShaderUniform 0x11743dd8>{24248320: float Decal1_Rotation = 2;}

This might be something to do with my hardware/GPU so I'd be grateful if someone could check to see if changing the shipdata works for them. Probably easiest to do if you are using the replacement pack and change the "cobra3-player" entry and start a new Jameson.

Edit - I should add that changing the position and scale works fine.

Further edit..

Capt. Murphy wrote:

Thanks both - It's fixed on my local copy due for release as soon as I've sorted the decal customisation. It's the same essentially harmless error message you get at start-up when the Griff Cobra is the default player cobra, as you are showing a player ship as an NPC demoship.

Grrrr - my fix doesn't completely eliminate the errors messages, because you can only change the shader after the entity has been displayed, and the error message is already fired once then. At best it can reduce three repeated errors to one. Never mind will just have to put a note in the readme to not to worry.

I'm seeing changes when modifying the decal rotation value for cobra3-player in shipdata.plist
specs:-
Oolite trunk 1.77.0.5006
Griff_Shipset_Replace_v1.31.oxp
Griff_Shipset_Resources_v1.2.24.oxp
Windows 7 64-bit
OpenGL renderer version: 4.1.0 ("4.1.0"). Vendor: "NVIDIA Corporation". Renderer: "GeForce GTX 460/PCI/SSE2"

Could it be something to do with the decal rotation being a float value whilst the position & scale settings are written as a vec3?