Oolite Bulletins

phkb wrote: ↑Tue Mar 26, 2024 12:34 am

Something like this, then? YouTube PlanetFall2 new landing animation

Under the current constraints this is looking pretty good.
How many images did this take up to now?

hiran wrote: ↑Tue Mar 26, 2024 5:31 am

How many images did this take up to now?

Well, in this instance, because of what I'm doing and how I'm doing it - 2. A left hand "door" image and a right hand one. I'm essentially spawning the two visual entities and then moving them in front of the player, rather than doing a "slideshow" of a whole series of images.

It all depends on what we're trying to animate. Complex scenes with moving parts - we need 15 images per second, all pre-rendered beforehand. If we can do something simple (like sliding a single image across the screen) we can get away with a lot less.

phkb wrote: ↑Tue Mar 26, 2024 5:37 am

Well, in this instance, because of what I'm doing and how I'm doing it - 2. A left hand "door" image and a right hand one. I'm essentially spawning the two visual entities and then moving them in front of the player, rather than doing a "slideshow" of a whole series of images.

It all depends on what we're trying to animate. Complex scenes with moving parts - we need 15 images per second, all pre-rendered beforehand. If we can do something simple (like sliding a single image across the screen) we can get away with a lot less.

Does the image have to be rectangular and opaque or is transparency allowed?

Right now my idea is:
When the beacon is reached, remove it.
Point the nose to the horizon and level the wings. Play a shuddering sound from retro/landing rockets. Then slide in a black cityline from below. Finally you can hear the engine cutoff.

The cityline could be the upper half (no reflections in the water but also transparent sky) similar to this:

Can we add some dust in the end?

To not nurture the feeling fhat all spaceports look alike, create a hash based on the coordinates (galaxy, star, planet, spaceport) and based on that choose one image amongst x, with x growing as we add citylines.

Not sure about the skyline and transparency. I’ll run some tests tomorrow to see what can be done.
If I can’t get transparency to work, that will probably rule out the dust idea.

phkb wrote: ↑Tue Mar 26, 2024 7:14 am

Not sure about the skyline and transparency. I’ll run some tests tomorrow to see what can be done.
If I can’t get transparency to work, that will probably rule out the dust idea.

I genuinely hope it works. Would be really powerful as we could add 'inofficial' landing sites looking like this:

I've been earwigging this thread a while. I dreamed about it last night, and woke with many thoughts from my player perspective. I condense below, as far as I can while still grasping it, the bits that still make sense after my first coffee.

The simplest, and most applicable to current door idea: Could the door have static frames, with lights, chevrons or stripes at the edges, allowing for a computationally cheap, rendered on-the-fly, descending illusion (movie elevator window, or barber-shop pole style, accelerate, decelerate)? Further, could the outside view be visible at the beginning of this descent while the doors are closing, to boost the illusion of motion and place. Roller coaster drop!

IMHO it's better for the pilot to control the 'stop' rather than wrench control from them abruptly.

Would it be possible to use a dockable for the beacon, where the ship must halt within a certain distance, a bit like the fuel station OXP does? Here, control would be yielded as velocity hits zero in the right place. At least this way, the player is in control of the stopping bit, rather than an abrupt grabbing of control while in flight.

This could be a tube type thing like fuel stations, where you can see outside as you enter, or a smaller wall type object with edges that grow around the craft as it halts nose-to-target, like a big balloon or umbrella.

Out there, probably too mad:-
Wall or doors could show a carefully scoped ground view of a "car park" of berthed ships, perhaps initially from above, rendered in the usual way from stock, and with lighting colour guided by the planet colours. This allows for more variations, and/or could embellish a finite backdrop/texture album. Seeing small ships next to large might help give scale and awe. The player stops within say 100 metres, the ship is grasped and aligned to the screen (or screen aligned to ship, then ship grasped if using the fuel satellite idea), pulling the TV view closer once it's all that can be seen. For extra immersion, the 'TV' view could be sourced from station traffic control data if applicable planet-side. The view could pan to horizontal during the brief descent to embellish the conceit. If using traffic control data, the view going up might even have different ships in it. The planet colours could be used to tweak the lighting. Rather than try and render two locations at once, maybe "porthole glows or shows test-card until outside view gone and ship secure in tug", then the car park view switches on.

For story ideas . The ships are bulky, the larger ones, like sea ships, need supporting evenly over their whole under-surface rather than on pin-like legs. Anti-grav moorings need careful ship alignment. The ground level traffic of flying metal monsters needs controlling. A variety of methods have evolved across the eight to handle these requirements. Smaller moons use old-fashioned pilot robots to tow the craft to their allotted berth, many planets have faster sky-to-ground elevators, which move from berth to berth to drop or raise ships for the sky tugs. The highest tech level planets can use short range hyperspace elevators to park the ships anywhere on the planet in the blink of an eye (maybe even station to ground!). Low tech level and poor planets might only cater for smaller craft that can stand on legs, using simpler balloon tugs to dock them.

Good luck with this. Crash-test dummy standing by.

Apparently I should have been an animator!

MrFlibble wrote: ↑Tue Mar 26, 2024 11:07 am

IMHO it's better for the pilot to control the 'stop' rather than wrench control from them abruptly.

I can see your point, but it would mean doing something different for this mod to every other docking process in the game. In every other dock, you have to keep moving forward until the dock "grabs" you. This would end up being the exception.

MrFlibble wrote: ↑Tue Mar 26, 2024 11:07 am

The simplest, and most applicable to current door idea: Could the door have static frames, with lights, chevrons or stripes at the edges, allowing for a computationally cheap, rendered on-the-fly, descending illusion (movie elevator window, or barber-shop pole style, accelerate, decelerate)? Further, could the outside view be visible at the beginning of this descent while the doors are closing, to boost the illusion of motion and place.

Theoretically, yes, although to be clear, I can't render images on the fly and use them in game. Everything has to be pre-rendered. However, to achieve the exact experience you're describing would necessitate starting the animation *before* any of the docking process kicks in. Once the docking process starts, all external visuals are turned off, the docking animation plays, and you're docked.

To explain in a bit more detail: At the moment, everything that happens begins during the shipWillDockWithStation world event. The animations that are playing are replacing the default animation you see in the strict game when you dock at a station (the blue and red boxes that come towards you). To get everything in you're describing, I would have to wrest control of the ship from the player beforehand, playing a bunch of visual effect animations, and *then* triggering the docking process.

So yes, it's possible. But (and here's the thing) I'd have to rework all the docking process I've implemented up until now. At the moment, I'm leveraging the "External Dock System", so it's handling the actual docking process. To fully get all the animations we want, I'd have to shelve that work, and start again. Now, obviously, I wrote the EDS so I could very quickly copy/paste the important bits, but that kind of defeats the point of a customisable system.

MrFlibble wrote: ↑Tue Mar 26, 2024 11:07 am

Would it be possible to use a dockable for the beacon, where the ship must halt within a certain distance, a bit like the fuel station OXP does?

I can use anything I like as a replacement to the flasher that's currently there. The benefit of a flasher is that it's visible on the dark side of planets, where some of the fixed dock points will be. Of course, I could still add flashers to whatever I use as the primary dock point, but the problem you'll get is scale: whenever you put a physical object close to the planet, it reinforces the scaling issues we have with our planets. A flasher, being kind of an indeterminate object, I think can get away with it more, but put anything like a fuel station there and the visuals start to break down the illusion.

MrFlibble wrote: ↑Tue Mar 26, 2024 11:07 am

Out there, probably too mad:-

Yeah, maybe a *bit*! It would be a cool sequence, but *way* beyond what I'm capable of producing. It's hard enough to get a simple, square, flat image to scroll across the screen at the right distance and speed, to say nothing for that sequence.

I'm trying, everyone! I really am! My "archive" folder for this OXP is filling up with lots of discarded code and images from all these various attempts. I don't mind - the experimentation is fun, and I currently have a bit of time on my hands. But I'm really not an animator! That closing door animation was created by finding an image on the 'Net that looked like it could be used as a door, cutting it it half, and then dragging them together in front of the player. I couldn't draw that myself. And my animation strictly speaking isn't: it's more like an illusion of animation.

So, I'm happy to bat around ideas until we find something that (a) I can do, and (b) Oolite can do as well. I just thought some additional clarification was important.

It might be a case of too many cooks here (and I mean no disrespect to anyone), so I'll probably shut up (relatively... for a bit...) after this.

With the closing doors effect, I don't get a sense of landing, rather I get a sense of being swallowed up by some larger entity or even of a quirky 'game over' screen.

The one that DID have a sense of landing was your very first offering, pre clouds.

https://www.youtube.com/watch?v=WVQgJtPLWl4

That link is just to a video of docking in bbc elite but there are 3 distinct elements to it.

• approach
• tunnel
• docked image

I've said my bit on approach already and what this discussion has been primarily wrangling with is finding a suitable 'tunnel' effect.
If however, we remember that a suitable image can help to contextualise what the tunnel effect was supposed to represent (e.g. docked ships in the video example above) then that tunnel effect is enhanced in its utility rather than just odd and likely unsatisfying.

I'm not suggesting an elaborate scene (nice as that night be) but rather the interior of a docking bay, perhaps only recognisable as such by some designation on the facing wall. I appreciate that such things don't just spring out of thin air but we have some suitably capable artists here for whom I suspect that would be a relatively easy task.

Of course it could just as eailly be a landing strip, a docking pad, a plateau with lights etc. a still image that sets the scene without adding unnecesary detail.

So: approach, sequence, context.
The three should support each other just as they did in the example above as much as forty years ago.

That's probably as much use as I can be, if it's of any interest. If not then no hard feelings and good luck!

hiran wrote: ↑Tue Mar 26, 2024 7:23 am

I genuinely hope it works.

I'm sorry to say, it doesn't work. Cutting a section out of the image, and leaving the section transparent, just produces a black box when rendered in game. So, the only way to have cut-away sections is to include them in the model stage. And modelling is not something I can do.

So, no easy wins in that direction, I'm afraid!

phkb wrote: ↑Tue Mar 26, 2024 12:34 pm

hiran wrote: ↑Tue Mar 26, 2024 7:23 am

I genuinely hope it works.

I'm sorry to say, it doesn't work. Cutting a section out of the image, and leaving the section transparent, just produces a black box when rendered in game. So, the only way to have cut-away sections is to include them in the model stage. And modelling is not something I can do.

So, no easy wins in that direction, I'm afraid!

Thanks for investigating. I am wondering why transparent should become black. What was your transparent color: black, white, gray, pink (consider any rgb color can be transparent by just using 100% alpha - or was it 0 %?)

hiran wrote: ↑Tue Mar 26, 2024 1:47 pm

I am wondering why transparent should become black.

No idea. Probably something to do with the model not defining a "hole", and the diffuse texture is insufficient on its own to create the hole.

hiran wrote: ↑Tue Mar 26, 2024 1:47 pm

What was your transparent color: black, white, gray, pink (consider any rgb color can be transparent by just using 100% alpha - or was it 0 %?)

No color. Alpha of 0%. It looks like this on my editing software:

phkb wrote: ↑Tue Mar 26, 2024 12:16 pm

I just thought some additional clarification was important.

All clear. Very much appreciated.

phkb wrote: ↑Tue Mar 26, 2024 1:52 pm

hiran wrote: ↑Tue Mar 26, 2024 1:47 pm

I am wondering why transparent should become black.

No idea. Probably something to do with the model not defining a "hole", and the diffuse texture is insufficient on its own to create the hole.

hiran wrote: ↑Tue Mar 26, 2024 1:47 pm

What was your transparent color: black, white, gray, pink (consider any rgb color can be transparent by just using 100% alpha - or was it 0 %?)

No color. Alpha of 0%. It looks like this on my editing software:

You cannot have a RGBA color with just alpha. Apparently on your screenshot you set RGB all to zero and alpha to 0. Which means it is a black, but fully transparent. You could have achieved a similar optical result by using 255,0,0,0 - which would be a fully transparent red. Wondering whether that would also turn into black... Do I make sense? Maybe check out https://www.youtube.com/watch?v=BKorP55Aqvg

At last transparency becoming black is ringing a distant faint bell. I've run into that in Visual C++/Microsoft Foundation Classes. It was not related to the image but how it would be applied to the drawing canvas.

I found similar documentation for Java/AWT here:
https://docs.oracle.com/javase/8/docs/a ... eObserver-

So if we find the line in Oolite that renders the image maybe we can replace it with something that keeps the transparency. We might be as lucky as that being a one line change.

Perhaps something from the oolite source folder