Oolite Bulletins

cim wrote:

Svengali wrote:

A few scriptable and bindable 'user' properties would be a dream. I'm often using energy, fuel or lightsActive to control shaders or pass infos. This reduces the need to switch them.

Makes sense. How many do you think would be sensible? I'm thinking two floats, two ints, and two vec4s should be enough in general, plus make hullHeatLevel configurable to simplify use of the default shader.

Switeck wrote:

NPC Shields OXP jacks the npc's ship heat levels to 0.99 to simulate the flash of the shield absorbing a laser (or missile) hit. It might be better if it could instead create a flash directly via scriptable shaders changes. Then, npc ships could even have different color shields for variety.

cim wrote:

Switeck wrote:

NPC Shields OXP jacks the npc's ship heat levels to 0.99 to simulate the flash of the shield absorbing a laser (or missile) hit. It might be better if it could instead create a flash directly via scriptable shaders changes. Then, npc ships could even have different color shields for variety.

Should be fairly straightforward with visual effects - just create one at the ship's current position (or thereabouts), with appropriate shader parameters. Reminds me that I was going to add a scale(f) method to resize visual effects, though.

cim wrote:

Makes sense. How many do you think would be sensible? I'm thinking two floats, two ints, and two vec4s should be enough in general, plus make hullHeatLevel configurable to simplify use of the default shader.

cim wrote:

Switeck wrote:

NPC Shields OXP jacks the npc's ship heat levels to 0.99 to simulate the flash of the shield absorbing a laser (or missile) hit. It might be better if it could instead create a flash directly via scriptable shaders changes. Then, npc ships could even have different color shields for variety.

Should be fairly straightforward with visual effects - just create one at the ship's current position (or thereabouts), with appropriate shader parameters. Reminds me that I was going to add a scale(f) method to resize visual effects, though.

Adding that sort of dynamic rewriting of the shader program itself, though... that would be extremely difficult.

an improved Langston Field which expands as it absorbs energy, increasing its surface area and dissipating heat faster.
-- The Mote in God's Eye.

Tricky wrote:

cim wrote:

Reminds me that I was going to add a scale(f) method to resize visual effects, though.

Adding that sort of dynamic rewriting of the shader program itself, though... that would be extremely difficult.

Would that allow something like this...

an improved Langston Field which expands as it absorbs energy, increasing its surface area and dissipating heat faster.
-- The Mote in God's Eye.

Revision 5223 - Directory Listing 
Modified Thu Aug 23 19:46:23 2012 UTC (3 days, 19 hours ago) by cim 
Some new ship JS properties
ship.currentWeapon
ship.weaponPosition*

Commander McLane wrote:

cim wrote:

Switeck wrote:

NPC Shields OXP jacks the npc's ship heat levels to 0.99 to simulate the flash of the shield absorbing a laser (or missile) hit. It might be better if it could instead create a flash directly via scriptable shaders changes. Then, npc ships could even have different color shields for variety.

Should be fairly straightforward with visual effects - just create one at the ship's current position (or thereabouts), with appropriate shader parameters. Reminds me that I was going to add a scale(f) method to resize visual effects, though.

That would be lovely. I was originally experimenting with flashers in order to create a shield orb around the ship. But this never went anywhere. Using the hull temperature for as visual effect is really only a limited workaround, for instance it doesn't allow for another colour. So I would gladly replace it with a visual effect. Scalability would be great too, of course, because the effect should be proportional to the ship's size.

cim wrote:

A new type of entity for trunk: Visual Effects

...Additionally, properties have been added to the Station and System JS classes to allow the usual break patterns to be suppressed...

cim wrote:

Break pattern suppression

Code: Select all

station.breakPattern = false;
system.breakPattern = false; // must be called in shipWillExitWitchspace to be useful

I'll release a sample OXP for visual effects soon.

cim wrote:

Experimentally, I've changed the system populator so that all systems have at least one rock hermit. If there wasn't one generated on the normal spacelanes, there will be one added to a semi-random point in space quite some distance from the spacelanes.