@robn & @brianetta: please, forgive my bad use of english language... i was thinking in italian and writing in english, a mistake i should not do anymore...

i'm very sorry you had the feeling i was trying to impose my ideas. i wasn't insisting at all, only arguing what was supposed to be a suggestion...

you know, italian (and tuscan much more) are talkative and polemic... i'll control myself better for the future.

as for coding my thoughts ... i'll give it a try!

23 May 2011 - fabea7a

This is a huge build! A whole bunch of stuff was finished off over the weekend so you get it all at once.

* New fonts and font config

The font rendered has been heavily updated and the fonts have been switched to Titillium Text for the GUI font and Cousine Bold for the world (ie ship model) font (though the latter was chosen to sort out some potential licensing troubles, and looks the same). Of particular interest in font configuration files in data/fonts that allow you to modify some of the details of how the fonts are drawn. This is foundation work for some bigger changes that are coming down the pipe (like use of multiple fonts in the interface).

* New open-air ground stations

Philbywhizz has put together some great new open-air ground stations. There's four variants of the pad station, with 1-4 pads. There's also the beginnings of an airport/runway station, though its not fully working yet. Undoubtedly this will uncover a raft of problems as we've never had ships docked outside a station before, but this is an exciting way to start finding those!

* Thruster control in set-speed mode

This is one of those things that is trivial to implement but gives fantastic results. Now, while in set-speed, you can use the thruster controls to temporarily override the set-speed mode. When you release the controls, the ship will correct itself again. This allows very fine positional adjustments and is great for manual landing.

* Heaps of fixes

There was a bunch of small issues in the tracker - crashes in odd cases, layout problems, starports not quite in the right place, that facegen power-of-two bug that stopped it appearing on some graphics cards, and so on. Lots of them are fixed in this build. See the Changelog for full details.

Just took fabea7a for a spin. Looking good guys! My saved games work and I can see faces again! 😆 It's great to be able to land outside, and that runway thingy is... interesting. I assume the pads and runways have to be elevated to keep them above ground level. No, that wrong. Ground not level. 😉 So I'm wondering, after I land on a pad and get out of my ship, how do I get down from up there? An elevator, or am I supposed to use my jetpack? Hm... jetpack... interesting thought. I've been waiting for mine for years. I hear that we may be able to exit the ship eventually. Orbital skydiving, anyone? 😈

Thanks everybody! 😀

Thanks for the feedback guys.

To answer some of your questions, yes the runway and landing ports are 'up in the air' because I was finding that when the ground was uneven (like Brasilia) v(0,0,0) was underground.

The 'runway' idea is more of a proof of concept while I was playing around the lua scripts and learning how pioneer does its modeling. My aim would be to when you autopilot to the station it will look like your aircraft is landing, and when you take off you take off on a horizontal direction with a little bit of 'lift' instead of launching vertical.

Always looking for feedback. 🙂

There's an open issue about this. Ideally we want the terrain under the station to be flat, either by searching for the optimal area or excavating the space under the starport.

any way of just simulating a flat ground within say 200km of every open air spaceport ? like a flat crator in which it sits.

Might be useful later on if player built faciliities are plopped down it could flatten out a surrounding area

Its pretty much what I said - flatting area under the starport. Its just a larger radius.

26 May - 7b2aa07

Last night saw the new HUD graphics merged. The panel itself is slighty updated from the previous one, and it has the new alert icons too. There's some minor text position adjustments to make it all look right with the new font.

Finally we have a HUD that looks as good as the planets it sits in front of 😀

I have got to say that the new HUD does look the part. 🙂

thumbs up for the new hud

These releases certainly keep the interested level up. is it Ok to produce a mod of the new dashboard?

Of course, its open source - you can modify or remix things as you see fit.

ok, here is a high res version with some different/new stuff. 😀

viewtopic.php?f=35&t=2121

29 May - 81d4749

Just a small update today. Screenshots are now saved in PNG format, so you can pass them around without needing to do any conversion.

i like the shift to the PNG screenshot save good move

10 June 2011 - 9cfa09a

First build for alpha 12 dev. Two significant changes in this. The first is more new star and planet icons from form users VampiretteDuCosmos and Firemark. The second is that the long-standing time precision bugs in the model system that caused eg landing lights to blink at odd rates and not match the timeaccel setting has been fixed. We're off to a good start!

well exactly what i thought, changed the os.clock() to get_arg(1).

do you think i would have used get_arg(1) if i liked it?

i really dislike it, i don't like to see scanners and posl. being animated according to time accel. (wrong term, wrong imagination, it's a hibernating not a speed up in time. this wheel you can't let go or slow down!).

don't you think that should be left to the choice of the modeler, i mean if one likes them rotating/flashing according to gametime, well do so, but i don't like it.

and i used it very rarely, because it looks stupid to me, only sometimes when it makes a good look (viper engine, orion's rotating lights, which i changed already to os.clock because they won't get updated proper after the first month, i will check that to), else not.

more a question of style to me then realism.

from on the first model i made for pioneer (ip shuttle), i used os.clock, because it looks stupid imo to see i.e. a scanner rotating so fast, you feel it must fly off.

i will check further and post some small clips, to better show off what i mean.

[/hr]

before i started off modeling for pioneer, i started a "LEGO" mod for FFED3D and i was thinking about better dashboard symbols, FFWD symbols let you imagine a time acceleration which is not true, it's a hibernating (stardreamer). so i came to the conclusion that cubes in the way of a matryoshka (nesting puppet) will symbolize it much better.

it will symbolize the amount of space you travel instead of time, doesn't makes much difference, but at least it didn't symbolizes a time acceleration.

Couldn't you just write a function that slows down the scanners and lights by the same amount as the time acceleration? I've never quite liked the frantic scanner look either.

But scanners don't hybernate.... 😉

True, but to me it just looks better, kind of like warp drive. Perhaps you're in a time bubble.

This is where a clear bug report would really have helped.

The conclusion I drew from your long and rambling description of the problem was that you had uses os.clock() because get_arg(1) lost precision after a month. As a result I found the bug in get_arg(1) and fixed it, and the models were updated.

os.clock() is fundamentally the wrong way to achieve what you want. Its not locked to the frame rate which is why it appears to slow down and speed up as the frame rate changes.

The physics simulation is being run faster, so technically anything within that simulation should appear to go faster too. I agree that it looks strange, but I also think it looks strange when there's no apparent change. I'm not sure what the correct behaviour should be; I will need to consider it further.

My personal take is that this is a no-brainer. When you speed up time, things like rotating dishes and antennae on the ship should spin faster. Flashing running lights should flash faster. When paused, all these things should pause too. Not only is that how it logically would appear to a pilot using a stardreamer, but that's what's aesthetically and intuitively correct for me.

i concur with brianetta

Frankly I'd never considered that there was a problem until someone said there might be. I still can't think of a way it could change without also looking weird or unintuitive. If all the options are going to look odd then I'll take technical correctness as a fallback criterion.

This just made me thought if a spaceship even needs blinky lights like airplanes 🙂

http://www.aerospaceweb.org/question/el ... 0263.shtml