SpaceSimCentral

[url]http://conceptships.blogspot.com/2011/10/concept-ships-by-adam-burn.html[/url] to post the above link because I just love looking at it all.Hope it provides some inspiration :)andy

some, lots of light and shadow use... (my teacher told me once not much behind "the 3rd kind" looks like a couple of spotlights on a black background)let's say not my style, but crafty for surei don't have to tell that i like the 50's, or do i?and i found out i'm not the only one, i have seen some retro style anime (damned japs )sometimes i feel i see very well known parts section from posted link,suprosa from x-wing alliance (note that it's not a very good screenshot but i haven't any other here),but i guess you can catch itbut it would be a shame imo, if we would all follow anime styleand i hope i found some more "european style" for mine.there is not much outside i see i really like (not because of eager), i miss sometimes something i can tell the name of a modeler by.something that didn't looks like arts schoolsomething own, specialugly, crappy or not but uniquei like the "planet express", yes it's a cartoon ship, but what kind of a simple cool looking submarine shaped vessel that is at least somewhat different to all common, i mean would you like "planet express" as a 21th century type of ship? (anime style?)i guess not, it's this retro 60's bubble gum style that makes it attractive (apart from the fact that comics should be held reasonably simple).[/hr]enough bla bla,i updated already the submodels to alpha15, that is how i would use them.the existing pilot may have to be renamed (folder and script), to avoid overwriting and other confusions, they can be run safe together if i remeber right.it contains all what is needed for the further new models i madei hope someone will check them out please, i have no running pioneer at this time.[url]http://pioneer-universum.web.officelive.com/Documents/sub_models.zip[/url] will be a ship so you can check the new pilots and get confirmed that is really a big difference to performance.the ship i will do in two versions one using the existing pilot models one using the new ones.another advice, if you like to see variations to the pilot, squad_sign and decals, selector.lua must be moved in front of sub_models (like it was before), else it really won't work (i have no idea why i find this under models?). you will have always the same decal, always the same squad sign, always the same pilot, that's poor imo.i'm open for other solutions (players profile), but as long...please response/help!here the ship to fiddle around with, it's the odd "Terra" ship with some new texturei chose this because it use three pilots,i noticed that some variations have been removed from the existing model, sad, either three times the same face/dress or two was simply missing then (courier, but the model wouldn't work then).please keep the 3x3 variations, it's a sneeze for pioneer to handle.i was really surprised what difference it is to what i coded before.[url]http://pioneer-universum.web.officelive.com/Documents/terra_actualpilot.zip[/url] be it's not as much now if the selector isn't properly called and the variations have been removed, but i guess still notable.

next,coolhands viperi know already exists,this version includes (or would)- timberwolf skin- lizard skin- med_wear skin- heavy_wear skin- police skin (actually disabled, more info later)- a crazy UC anim. - a new kind of engine glow (check it out, i love it)- damaged engine animation for the heavy wear version (some random flashes)i disabled the pilot so it should work without troubles for all.disabled police viper:i don't know if one has already something coded for a separate POLICE ship, which is not for sale!now what i did with the viper (or else) i simply tagged it as "static" additionally i didn't allowed the modules (bulk ships etc).to use static ships that have a lower hull mass as i.e. 100 tons.maybe not the best solution, but one that has worked and was easy to realize.[url]http://pioneer-universum.web.officelive.com/Documents/viper_ch_nopilot_nopolice.zip[/url] still uses os.clock()i don't know, should be still possible, no?i can't say if i can use "SECONDS" instead of it, one would have to try.the reason is, i used the little difference between the clocks (os.clock to game time) to determine a random value, a real randomly appearing value.so the flashes for i.e. a damaged engine appear really randomly.i might could have used noise, but actually i can't make no tests.i guess i could now let the ramp get animated when the ship has landed, i would have to fixup that to, but like i said not now.

potsmoke66 wrote:
it still uses os.clock()i don't know, should be still possible, no?
It still works, but is almost certainly not what you want. The resolution problems with get_arg(1) have long been fixed.In the future its highly likely that the entire os.* namespace will be removed (unless there's a good reason that Lua should have access to the operating systems).
Quote:
i can't say if i can use "SECONDS" instead of it, one would have to try.
get_arg(1) for alpha 15 and earlier, get_time('SECONDS') for alpha 16 onwards.
Quote:
the reason is, i used the little difference between the clocks (os.clock to game time) to determine a random value, a real randomly appearing value.
Use math.random() for now. In the future Pioneer's internal random number generator will be exposed to LMR enabling better control of seeds and consistency across platforms. Using math.random() means we can make sure it all just works in for you.By the way, you asked somewhere for details of the get_arg replacement functions. LMR now has some documentation, see here:http://eatenbyagrue.org/f/pioneer/codedoc/files/LmrModel-cpp.htmlThis is up to date to the master branch, so what will be available in alpha 16. The only changes compared to what you're used to is the removal of get_arg() and get_arg_string() in favour of specialised functions, and the addition of texture_glow() for adding glowmaps.

adding glow_maps, sounds cool!well, i guess, look at the snipped yourself perhapsit uses already math.random() (never used any else for models, wasn't possible i guess)might look a bit weird
Code:
if lod > 2 thenuse_material('e_glow_b') math.randomseed(os.clock()*10000/get_time('DAYS')) local timer = math.random(1,100)if timer == 24 then texture('models/ships/viper_ch/e_glow_b.png')zbias(1,v(0,0,0),v(0,0,1)) load_obj('models/ships/viper_ch/e_glow.obj') zbias(0) elseif timer == 32 then texture('models/ships/viper_ch/e_glow_c.png')zbias(1,v(0,0,0),v(0,0,1)) load_obj('models/ships/viper_ch/e_glow.obj') zbias(0) elseif timer == 80 then texture('models/ships/viper_ch/e_glow_d.png')zbias(1,v(0,0,0),v(0,0,1)) load_obj('models/ships/viper_ch/e_glow.obj') zbias(0)endend
i used the difference of the clocks to get a random seed, if os.clock() isn't used in future i will have to guess of something else.it works nicely that way (or has at least, i can't check the result myself)sorry for the dynamic use of a tiny .obj, if REALLY needed it can be changed, but needs a few more sub-models.as i was already reaching a "limit" in alpha11, i couldn't use no more sub-models without disabling some.since there is a little difference between the clocks the seed will vary much, if you have any other idea to reach such tell me.i fiddled around a bit with noise for a seed, but it's not really randomly, the sequence is always the same.but for a nice damage effect (some randomly appearing flashes) it has to be random, else you will notice the sequence very quick.this has worked good for me and you can't (couldn't) tell when the next flash will appear, sometimes shortly after sometimes after a longer pause... but not to tell when (a typical damage).after all it's not very important to have this effect, but i guess some will really love it, it looks really cool.

Quote:
[url]http://eatenbyagrue.org/f/pioneer/codedoc/files/LmrModel-cpp.html[/url]
that's made very neat! i like it, thx"FLYING open flight (includes autopilot)DOCKING in docking animationDOCKED docked with stationLANDED rough landed (not docked)HYPERSPACE in hyperspace"i've seen before while checking the source, got any idea how long i waited for this? finally the adder can have his glowing hyperdrive only in hyperspace (and others to).i can (i wrote before) use the ramp on coolhands viper how it's supposed to be, great!and thanks for the update, the previous linked models are now ready for 16, wasn't ment that way first time i'm a step ahead instead of behind (i can't stop laughing)

potsmoke66 wrote:
it has to be random, else you will notice the sequence very quick.
The random number generator will give you a humanly unpredictable sequence if you don't keep changing the seed. Your code could actually make it more predictable.

first i thought, it's far to fast when i use math.random simply dynamicalbut of course i could use a much wider spread (1-10000, perhaps) and draw only a single number.on the other hand i guess it will be predictable (experience of mine with math.random in model scripts as used up to alpha11)i tried to experiment very early with math.random, one of my early ideas was to give the archologies numbers, each should have a different one, doesn't have to be particulary in row.i noticed then first, dynamic used the numbers change with each update. second, when i use them static i get allways the same numbers drawn, why is (was) not to clear to me (another side effect was, if i didn't used a seed for the numbers on the archologies they changed with the view angle , has not much to do with the actual problem just as additional info).it must be a seed that's already given, but i have no idea where from. further if i use math random dynamical the sequence will also be always the same, if i draw a number out of the sequence it will appear always at the same timepoint. when i draw a number and compare it to a clock it will be the same i guess, because the sequence is always the same.however, unfortunately there is a seed given and to get a different sequence i have to change the seed, right?some suggestions? ideas?

This is a work in progress test addon for alpha 15. I thought I'd share my work thus far. The major thing I've done is made spacestations.lua self-referencing. A copy of all the textures used is in a new folder, /data/models/stations/textures. I updated the lighting in the Coriolis and Hoop stations, fixed the missing texture on the Hoop and updated the adverts. The controversial 'station_splash' ad has been replaced. I put textures and details on the mushroom stations and added back in the basic groundstation model. I have to speed up the rendering, my display is a bit choppy with these stations. I read the discussion about too many texture calls. (guilty!) I have a slow computer by today's standards, so anyone should be able to use this. I'm currently working on texturing and detailing the pad station, and am writing it more efficiently. My goal is to detail all of the naked ground stations. It could take weeks for me to finish the pad and airport stations and then get back to tweaking this file, so here you go for now!Drag the data folder into your Pioneer folder, and replace all files. This includes a backup.[attachment=945:spacestations 10.zip]

Here's some pix of the mushrooms.[attachment=947:mushroom0.jpg][attachment=948:mushroom2.jpg][attachment=949:mushroom4.jpg]

I was wondering, could we somehow have a port with dozens, possibly hundreds of ship bays somehow?Perhaps a landing area then a separate "multi-storey" ship bay area?I was just thinking that we have airports with many dozens - sometimes hundreds - of aircraft, seaports with a couple to dozens of container ship docks, car parks with thousands of spaces etc. Having ports/spacestations with just a few spaces is actually quite limiting in ways because it means we wouldn't be able to have hundreds of ships flying about in systems due to the limited landing spaces

I think the CPU of common folks might have a few objections to "hundreds of ships flying around in a system". But more extensive starports in bigger cities would be nice for atmosphere none the less.

I agree with Fluufy, it'd be nice to have some *real* traffic in-system for high population worlds, Im not sure what impact that would have on 'ye olde peecees' Who knows we may get away with more than we think.. But I always thought it silly how in the originals you have a general population of trillions and trillions of hapless souls, but only about 100 of them can fly a spaceship

s2odan wrote:
I agree with Fluufy, it'd be nice to have some *real* traffic in-system for high population worlds, Im not sure what impact that would have on 'ye olde peecees' Who knows we may get away with more than we think.. But I always thought it silly how in the originals you have a general population of trillions and trillions of hapless souls, but only about 100 of them can fly a spaceship
perhaps people can add this kind of thing in a OXP style? ......where snippets of code and models are added via a addons file ......in this case it would be code snippets making extra traffic ...ect ect ...then those with low ends have a choice ......hmmm to add or not to add that is the question lol

Quote:
perhaps people can add this kind of thing in a OXP style? ......where snippets of code and models are added via a addons file ......in this case it would be code snippets making extra traffic ...ect ect ...then those with low ends have a choice ......hmmm to add or not to add that is the question lol
You can already do that with LUA. It wouldn't be hard to make a scrip that spawns a few dozen ships in a system when you enter it at random locations with random destinations. Problems are, of course, that the starports are too small yet, and that population seems not yet supported by the API, so it might be hard to scale the traffic by system. But Those two problems are solvable.I'm also not certain what happens with those ships when they or you leave the system, but that's just me not knowing my way around yet...

spike1984 wrote:
perhaps people can add this kind of thing in a OXP style? ......where snippets of code and models are added via a addons file ......in this case it would be code snippets making extra traffic ...ect ect ...then those with low ends have a choice ......hmmm to add or not to add that is the question lol
Re OXPs, we have long-term plans to have add-on bundles that include mission/AI/control scripts, models, art, music, whatever all in one file. Many of the pieces are in place already. I have no idea when this will happen, but it will.

UncleBob wrote:
You can already do that with LUA. It wouldn't be hard to make a scrip that spawns a few dozen ships in a system when you enter it at random locations with random destinations.
This is pretty much what data/modules/TradeShips.lua does, though it is far more advanced.
Quote:
Problems are, of course, that the starports are too small yet, and that population seems not yet supported by the API, so it might be hard to scale the traffic by system. But Those two problems are solvable.
System-wide population has been available to scripts since alpha 10 via StarSystem.population (actually it was even available to the "old" Lua API that came before the current one). Per-body population will be available from alpha 16 via SystemBody.population.
Quote:
I'm also not certain what happens with those ships when they or you leave the system, but that's just me not knowing my way around yet...
The ships themselves get destroyed by the physics simulation, which only simulates one system at a time. If you want to simulate ships flying around the galaxy in systems that aren't the player system, then you need to simulate this in your script.The one exception to this is that if a ship is in a hyperspace cloud with the same destination as the player at the time the player jumps, it will reappear via an arrival cloud in the system after the player arrives. In this case its emerges as just a dumb ship. Its up to the script to issue appropriate commands to the ship to continue whatever behaviour is appropriate.Again, TradeShips.lua is a script that does all of these things.

The main reason you don't encounter many ships in flight is that space is big. If you land near a starport and speed time up, you can watch them come and go. (-:

Brianetta wrote:
The main reason you don't encounter many ships in flight is that space is big. If you land near a starport and speed time up, you can watch them come and go. (-:
thats very true ....the chances of encountering another ship would only increase around a planet or space port of some kind anywayi mean ....lets look at it from a sci fi point of veiw (because we cant compare real life to it yet) ......how often does the enterprise come up against another ship in deep space .....its usualy round a planet ....or starbase ....it aint usualy in deep space unlesss its been called to that sector for a particular reason

Brianetta wrote:
The main reason you don't encounter many ships in flight is that space is big. If you land near a starport and speed time up, you can watch them come and go. (-:
This is only partially true though. Lets take the Solar system as an example, there are numerous inhabited worlds, which trade between each other. Then there are the asteroids (yet to be added to be fair) to be mined. Finally there's all of the other systems to trade with, both inbound and outbound.Now, on Earth alone, in the current day there are tens of thousands of very large cargo ships travelling the globe at any given moment. Most of those are much much larger than anything in Pioneer currently. So what I'm saying is that it might be difficult to intercept them in-flight, but it doesn't seem unreasonable to me that after just a moments thought, I would probably expect a star system like Sol to have about 15,000 to 30,000 Lynx-bulk-carrier sized ships travelling around it. Either going planet to planet, or arriving-and-travelling-to-orbit, or leaving-orbit-and-hyperspacing-out.Then there's all of the smaller ships. Of which an order of magnitude more would be quite sensible. So whilst I'd also expect trade routes I'd also expect a lot of ships taking wildly different courses throughout any given system due to differing mass, engines, schedules etc.What we actually have is a lot less, and what we can probably handle is likely a small fraction of that. However that is basically what I'd expect to see in the year 3200.