Oolite Bulletins

Hope this isn't a daft request. Would it be possible to add a property to ships etc that the game would use if the entity was destroyed, and would be inherited by the resulting explosion? The effect would be a kind of time accelleration (or rather decelleration) factor, causing the explosion to unfold at a slower rate than normal.

What I'm looking for is the ability to create an explosion that lasts longer, and looks more imposing thanks to its more ponderous progression, without weighing down the game's performance with a string of secondary explosions.

OK, a bit of a resounding silence on that one, which I suppose answers my question. Not really a runner then?

JD wrote:

Would it be possible to add a property to ships etc that the game would use if the entity was destroyed, and would be inherited by the resulting explosion? The effect would be a kind of time accelleration (or rather decelleration) factor, causing the explosion to unfold at a slower rate than normal.

What I'm looking for is the ability to create an explosion that lasts longer, and looks more imposing thanks to its more ponderous progression, without weighing down the game's performance with a string of secondary explosions.

From memory the normal explosion has only two parts: there are a few frames of the small explosion image displayed, then a larger explosion image for a few frames, and that's it. It doesn't progress smoothly, so the progression couldn't be slowed. (I could be very wrong about this.)

JD wrote:

What I'm looking for is the ability to create an explosion that lasts longer, and looks more imposing thanks to its more ponderous progression, without weighing down the game's performance with a string of secondary explosions.

Providing appropriate testing is done, a cascade explosion need not adversely affect game performance. We found this while developing Xeptatl's Sword which features some of the most impressive explosions you'll see in Oolite. Some of these are three-stage cascades and are huge and last for some seconds.
My creaky old computer proved to be an excellent test-bed for these, and the end results should be fine on all but the weakest of computers, and are still spectacularly awesome.

Smivs wrote:

... a cascade explosion need not adversely affect game performance. ... Xeptatl's Sword which features some of the most impressive explosions you'll see in Oolite.

Yeah, explosions like this - awesome stuff!

Wildeblood wrote:

From memory the normal explosion has only two parts: there are a few frames of the small explosion image displayed, then a larger explosion image for a few frames, and that's it. It doesn't progress smoothly, so the progression couldn't be slowed. (I could be very wrong about this.)

Yes, you’re very wrong about that. :-)

An explosion consists of up to four elements (not counting debris): two particle systems, described as “fast sparks” and “slow clouds” in the code (both use the same “particle blur” texture as flashers), a “particle flash” (the same quasi-lens-flare texture as is used for laser impact points) and, for large explosions, a ring. All of these are smoothly animated (try it with TAF set to 1/16), but the “particle flash” texture won’t look good if it’s shown for more than a fraction of a second. As of 1.74 or so, the “sparks” and “clouds” are fully spacial 3D particle systems and quite lightweight.

Ahruman wrote:

Yes, you’re very wrong about that.

Excellent news, thank you.

OK, thanks everybody.

El Viejo wrote:

Yeah, explosions like this - awesome stuff!

Wow. Now if I could just make something like that last for a while I'd be sorted.

Smivs wrote:

... a cascade explosion need not adversely affect game performance. ... Xeptatl's Sword which features some of the most impressive explosions you'll see in Oolite.

I'll take a closer look at Xeptatl's Sword and see if I can take inspiration (or blatantly steal!).

Cheers.

This post might be of interest

Smivs wrote:

This post might be of interest

Thanks Smivs. The mechanism I currently have in place is pretty similar to what you've described there. I've had the impression that I maybe get a slight stutter sometimes when the explosions fire. That's only an occasional thing, but it's stopped me getting too ambitious in stretching out the effect as much as I'd like.

What I'm trying to do is generate a bit of solar activity around the rim of the sun. It works, and it can look ok, but it's a bit more underwhelming than I'd been hoping for. I'd really like to extend it for several more seconds at least. I'll maybe try a few more iterations of the explosions, but I'm not confident it won't turn into a cpu/gpu hog.

Ah, I see. I suppose the problem really is that suns are BIG, even Oolite suns. So to even be noticeable these effects would have to be enormous.
It's a nice idea, and I know many aspects of suns are often debated here so maybe a better solution will come along.

Commander McLane wrote:

Following my trials and tribulations up to here, I'd like to know: Is there a good reason that the shipWasScooped and shipScoopedOther handlers do not fire if the scooped entity is an escape pod?

In 1.76 this has changed and shipScoopedOther fires for every pod that is scooped. There is just one limitation: You can't read the cargo that was actually scooped. You can only see the name of the pod. Also did this trigger before the pod was added to the cargo, so you couldn't see the cargo from the increase from the manifest also.

In trunk there are now two new ship properties: commodity and commodityAmount. I assume the names say enough. commodity returns the cargo as a string.

A special case is scripted cargo. Those pods enter the universe with undefined cargo. Undefined cargo returns the string "goods". On scooping time of a scripted pod, the pods shipScript runs. If it sets cargo for itself, the pod will be added as cargo to the hold as cargo. If not, the pod will end to exist after the script has ran. commodity will return null and commodityAmount will return 0

Is it worth adding a .displayName2 to ships and switching between the two every two or three seconds, for things like Bounty Scanner and ship naming scripts to use instead of appending strings to the existing .displayName? Or would that cause more problems than it solves?

Wildeblood wrote:

Is it worth adding a .displayName2 to ships and switching between the two every two or three seconds, for things like Bounty Scanner and ship naming scripts to use instead of appending strings to the existing .displayName? Or would that cause more problems than it solves?

Someone would be bound to ask for a displayName3 if we went down that route. That suggests that it should really be an array, but changing displayName to be an array now would break too many existing OXPs. Still, there might be another way.

Is it just the name in the STE that you'd want changing this way, or would you want the switching to also occur in the comms log, etc.

cim wrote:

Wildeblood wrote:

Is it worth adding a .displayName2 to ships and switching between the two every two or three seconds, for things like Bounty Scanner and ship naming scripts to use instead of appending strings to the existing .displayName? Or would that cause more problems than it solves?

Someone would be bound to ask for a displayName3 if we went down that route. That suggests that it should really be an array, but changing displayName to be an array now would break too many existing OXPs. Still, there might be another way.

Is it just the name in the STE that you'd want changing this way, or would you want the switching to also occur in the comms log, etc.

Forget I mentioned it. Anyway, it's easy enough to do with a timer in the same OXPs that are messing about with .displayName, and easier to make the timing adjustable there. It's just something I've been meaning to ask about for months.

On an unrelated note, I have some (very, very simple, uncontroversial) code changes I'd like incorporated into trunk. Who can I send it to?