Page 5 of 9
Posted: Sun Feb 22, 2009 2:42 pm
by Griff
Blimey, that took a lot longer than i thought it would - finally, I've uploaded a test version of the oxp here:
http://www.box.net/shared/7vbl44b81m
it seems to work ok, but since it's one of my oxps i'm expecting a whole bunch of shader error reports and stuff like that, actually i am seeing a lot of this message appearing in the logs when running the OXP:
Code: Select all
[method.undead]: Believed-dead method -[ShipEntity setSuppressExplosion:] called.
from the silent ship removal script i tried to write, is it serious?
The oxp uses normal mapping based shaders so it will only work on the build it yourself trunk version of the oxp.
I'm getting a bit of stutter in oolite when the debris first appears from an exploding ship, probably because this is literally a frankenstein monster of an oxp - it's a lot of different test oxp's fused together horribly so a lot of cutting down on shaders and stuff could be done to help spped it up, maybe i'm just generating too much junk in one go? i might just pick a few of the nicer pieces of space junk and do a more sensible version with smaller texture sizes and a non-normal mapped version for oolite 1.72
The oxp uses some scripts & AI's that Thargoid wrote for me, it generates some spectacular chaining explosions, well worth a look!
Posted: Sun Feb 22, 2009 3:25 pm
by Eric Walch
Griff wrote:
Code: Select all
[method.undead]: Believed-dead method -[ShipEntity setSuppressExplosion:] called.
from the silent ship removal script i tried to write, is it serious?
No, and I read elsewhere that this message is already removed for the 1.73 release. At least when triggered by the
remove() function.
Posted: Mon Feb 23, 2009 12:28 am
by Frame
yeah
Code: Select all
[method.undead]: Believed-dead method -[ShipEntity setSuppressExplosion:] called.
is harmless, and will be removed.. got it for my wrecks too...
happens when you explode or remove something
Posted: Tue Feb 24, 2009 2:28 pm
by Griff
I've had another go at the OXP, i've dumped the normal maps since they weren't really noticeable on the burning space-junk and were just taking up Oolite brain power, i've cut down the number of objects to just the best looking ones and reduced the number of textures used too - the oxp plays a lot faster now, and as a bonus it works on the current test version of Oolite (Oolite v1.72.2!)
It's downloadable here:
http://www.box.net/shared/k2lvh3enuy
I've included a copy of the built in Oolte shipdata.plist in the download that adds a required script entry to most of the native ships so they can blow up using this oxp, if you've made you own custom versions of thenative ships you might want to skip using this as it will reset all the ships back to their default stats & settings.
Posted: Tue Feb 24, 2009 2:34 pm
by another_commander
The new wreckage looks great (not that I expected anything less). But I had to hack the shaders to get them to work with the Intel X3100 card. Seems that the Intel shader compiler has some problems understanding global variables, which translates to no heatglow. I have uploaded
here the set of edited shaders that works, for those who have a similar card with similar problems. Just drop those inside the Shaders folder of the OXP.
Edit: Oh, looks like we had a new version just as I was typing this. Well, looks like I'll have to redownload.
Posted: Tue Feb 24, 2009 2:42 pm
by Griff
@ A_C, Yeah, i've got the rest of the day off work due to having been through a big ordeal at the dentist this morning and having a numb gob as a result i thought i'd fiddle with this oxp to cheer myself up. Thanks for fixing the shaders, hould i replace the ones in the original upload with your fixed ones? If poss, could you post a bit of info about what you had to fix so i could make sure to include it in future shaders?
Posted: Tue Feb 24, 2009 2:56 pm
by another_commander
Griff wrote:A_C, Thanks for fixing the shaders!
Should i replace the ones in the original upload with your fixed ones? If poss, could you post a bit of info about what you had to fix so i could make sure to include it in future shaders?
I am not sure if the original ones should be replaced. If they worked for you as they were, then it probably means that it's my gfx driver that misbehaves. However, you can try using them on your system and if they work as expected anyway, then you can probably replace them so that they will work on any card, even the semi-decent ones
.
The correction was in how variables are declared. Initially it was
Code: Select all
// Constants
float kInitialHeat = 5.0;
const float KspecExponent = 5.0;
const float kSpecular = 0.4;
// Set up the total burntime
float FadeTime2 = FadeTime * 100.0; // Multiply FadeTime by 100 to lengthen the burn time
float FadeFactor = kInitialHeat / FadeTime2;
All this was declared outside of main(). I brought most of it in, making main look like this (note I did not touch the two const variables):
Code: Select all
void main()
{
vec3 eyeVector = normalize(vEyeVector);
vec2 texCoord = vTexCoord;
vec3 normal = normalize( texture2D(uNormalMap, texCoord).xyz - 0.5);
normal = normalize(normal);
vec4 colorMap = texture2D(uColorMap, texCoord);
vec4 effectsMap = texture2D(uEffectsMap, texCoord);
vec4 diffuse = vec4(0.0), specular = vec4(0);
float specIntensity = colorMap.a;
// ------------ Brought in from outside of main ---------------
// Set up the total burntime
float kInitialHeat = 5.0;
float FadeTime2 = FadeTime * 100.0; // Multiply FadeTime by 100 to lengthen the burn time
float FadeFactor = kInitialHeat / FadeTime2;
//------------------------------------------------------------------
#ifdef OO_LIGHT_0_FIX
LIGHT(0, normalize(vLight0Vector));
#endif
LIGHT(1, normalize(vLight1Vector)); // change the 0 to 1 when saving the shader for oolite
diffuse += gl_FrontMaterial.ambient * gl_LightSource[0].ambient;
float NonClipHeatGlow = effectsMap.r; // just the hot metal effect, no polygon clipping
// Calculate the lighting,
vec4 color = diffuse * colorMap + specular * specIntensity;
// Add the glowing metal effect
float metalTemperature = max(0.0, kInitialHeat - FadeFactor * timeElapsedSinceSpawn * 0.5); // half speed cooling for the no-clipping heat glow
float Heat = max(metalTemperature - 0.5, 0.0);
Heat = Pulse(metalTemperature, 0.5);
float FinalTemperature = NonClipHeatGlow * (Heat + metalTemperature);
color += MetalGlow(FinalTemperature) * colorMap;
// Add the Sparking Illumination
color += effectsMap.g * SparkColor * Blink_on_off(Pulse(1.0, 1.0)) +
effectsMap.b * SparkColor * Blink_on_off(Pulse(1.0, 0.4));
gl_FragColor = color;
}
and that seemed to have been enough to fix it. Same fix for all of the fragment shaders. But since you have a new version out, I would like to try that as well.
Posted: Tue Feb 24, 2009 4:13 pm
by ZygoUgo
Griff you are the master!
Do these not work with the Neo variations yet then?
Posted: Tue Feb 24, 2009 4:43 pm
by Griff
It should work fine but not until the ship has been told to run Thargoids
"griff_explosionScript.js" script - all the magic happens here - when a ship dies the script calls up various burning junk items from the oxp, all of these have some cool AI's that Thargoid wrote that get them to behave in some cool exploding ways.
In cases when a ship doesn't already have a script attached to it, you can just add the line script = "griff_explosionScript.js"; to it's entry in the shipdata.plist and this will trigger the oxp when the ship dies, but if a ship already has a script assigned to it it gets a bit more tricky and Thargoids code has to be merged into the original script somehow
Posted: Tue Feb 24, 2009 4:49 pm
by ZygoUgo
Ooh goody, I'll have a look at that then, for research purposes of course..
Posted: Tue Feb 24, 2009 4:58 pm
by Thargoid
Griff wrote:It should work fine but not until the ship has been told to run Thargoids
"griff_explosionScript.js" script - all the magic happens here - when a ship dies the script calls up various burning junk items from the oxp, all of these have some cool AI's that Thargoid wrote that get them to behave in some cool exploding ways.
In cases when a ship doesn't already have a script attached to it, you can just add the line script = "griff_explosionScript.js"; to it's entry in the shipdata.plist and this will trigger the oxp when the ship dies, but if a ship already has a script assigned to it it gets a bit more tricky and Thargoids code has to be merged into the original script somehow
If the ship already has a script that has no entry for this.shipDied just copy/paste the one from my script into it.
If it does have a script and does have a this.shipDied entry then my code will need to be added into the existing one. The best point will probably be at the end of the existing code. If people need help with specific ships/scripts give me a PM.
Oh and if I may say it (even though I was involved with it a little) - "WOW!"
*
Posted: Tue Feb 24, 2009 5:29 pm
by Lestradae
Hey Thargoid & Eric,
is it possible to start the "griff_explosionScript.js" via death action?
Posted: Tue Feb 24, 2009 5:30 pm
by Kaks
Thargoid wrote:
If the ship already has a script that has no entry for this.shipDied just copy/paste the one from my script into it.
If it does have a script and does have a this.shipDied entry then my code will need to be added into the existing one. The best point will probably be at the end of the existing code. If people need help with specific ships/scripts give me a PM.
Thargoid, this might just be overkill (groan)... but what about having a global world script that looks at all ships & does something along these lines:
Code: Select all
if(ship.script){
if (ship.script.shipDied){
ship.script.oldDied=ship.script.shipDied;
else
ship.script.oldDied=function(){};
ship.script.shipDied= function(){
ship.script.oldDied();
// cool explosion code here!
...
...
}
} else
ship.setScript("griff_explosionScript.js");
I'm nowere near my development machine atm, so I'm doing this from memory: I'm sure the actual implementation details will be different(I can't check the wiki either, & I'm not too sure if you access this.shipDied exactly that way, etc, etc... ), but in principle it should work without a problem, and people won't have to go & edit their configuration files by hand...
In principle!
..
Posted: Tue Feb 24, 2009 5:46 pm
by Lestradae
Kaks wrote:Thargoid, this might just be overkill (groan)... but what about having a global world script that looks at all ships & does something along these lines
This is not overkill, this would be most practical!
Please do this guys, it's absolutely logical to do it that way ...
Cheers
L
Posted: Tue Feb 24, 2009 5:51 pm
by Thargoid
The only problem is deciding which entities get the script and which don't. For example you don't want it on asteroids, fragments, cargo pods or various other odds and sods.
But in principle something like that could be done yes, although I must admit I didn't know there was a ship.script or ship.setScript command