many things seem to have changed and it's not always to clear to me why,

next thing i stumbled over, was the changed zbias for the adverts 🙂

i guess i know what's the idea, but...

how do you know that you will use this model only on top of zbias(0)

further if the background geometry has zbias(0) which is actually the case, how should this stay on top of a wall i.e.?

i know a preassuming of 5 or 10 is not the best solution, but the only one, to avoid a depth conflict (flicker, disappearing).

but should work if you don't preassume a to extreme value like 100 .

think about such before you change it,

the adverts i'm sure even without the possibility to check it actually, will "zfighting" with the models on which they used.

the same for decals and such I HAVE to preassume a relative high zbias BECAUSE i don't know on which "layer" it will be, except on top of all the rest (which could be easely more then one).

if you like a clean solution, i would have to rewrite the adverts and decals to functions where you can pass the proper zbias to, only in this way you can control a submodels zbias.

[/hr]

that reminds me of the, if i'm right, still unsolved LOD issue, i can't control LOD for a sub-model (only the ones from folder sub_models) from the model, or i have to tell right actually it's controlled by bounding radius and LOD setting of the final model.

but this leads to a big disadvantage, i have ALWAYS a very low LOD for a small submodel (only those from folder sub_models, sub-models used in the same script have their proper LOD) on a big ship.

as example std. wheels on a big ship

now, imo we have three possibilities, either i write all sub-models (folder sub_models) new as a function like the above mentioned with the possibility to define a explicit LOD for the submodel or that could be reverted to what it was before, because i liked it, or as final solution, we forget simply the LOD for the submodels (folder sub_models).

back to the adverts, well some might have also wondered why a bounding radius of 10?

well it was a "hack" to avoid the above described LOD problem, the adverts appeared always with lowest lod in the big station if i used a bounding radius of 2. the only thing to get around this, set the bounding radius to "astronomical" values 😉

it won't hinder anything the bounding radius is used in the case for adverts only for their lod.

it's a bit a bad example since the adverts need no LOD you will call them if at all at a certain LOD from the building/station model. you can remove the LOD completly from the adverts, they won't change.

but i guess one can understand,

it's a problem to preassume a zbias

it's hell to preassume a bounding radius or LOD!

further i guess, IF i would change for some reason the bounding radius of a sub-model (folder sub_models) because of above described limitations, i'm sure one bright will change this back, thinking it's "wrong".

btw,

as long as i have no web and have to operate from a macbook, i could need some help getting things into github or public at all...

could be my models are ugly, but also a few changes has been made, so they don't work proper now, i can't say that i like that much.

i mean if all didn't works, lod, zbias, selection of material for sub-models, they will really look crappy, but it's not my fault i didn't wrote them in this way.

the problem is one issue is chained to the other, and if i should fix my models from remote, it needs some basical changes to make them work again.

There is no need to lash out like that.

I even agree with some of your earlier points amount single meshes and textures but everyone here is learning and working to get better at doing these things. Simple insulting each other is of no help to anyone.

Just to clear it up potsmoke66 but it is Durandal and NOT vlastan that made the insulting post.

Don't take it to heart.

before you can use it some that have changed to it

- needs a additional sub-model (robot-pilot) 😉

- has again changed names, sorry but it helps to avoid confusion. if you like to use them see the result or compare them

you would need to edit a model and replace the existing call.

- the chair is now separated from the pilot, this allows to use them if you like to design your own chair/seat for the pilot.

- a additional chair model, a bit more comfortable looking one

- runs much faster now!

- needs to have the selector function in the right place, else you will have always the same "jöggel" (pilot, select"n"() will return nil). if it's not loaded in front of sub-models you can forget that function (delete it if you like) it didn't works.

things that hasn't changed

- still the same size and stupid smile 😛

- still the same position values for the seat and the pilot (also robot pilot, if positioned like the pilot it stands on the seat)

the new names are

pilot_seat (global lighting) and pilot_seat_lit (local lighting)

pilot_cseat and pilot_cseat_lit (c for "comfort" 😉 )

pilot_(1-3)_lit, pilot with local lighting, no helmet, rarely used on some bridges that have a local lighting

pilot_(1-3), pilot (global lighting), "modern" helmet

pilot_(4-6),pilot (global lighting), "old" helmet (fishbowl)

pilot_(7-9),pilot (global lighting), no helmet

now, why 3 of the same type?

simply to have at least three different ones in a bridge

the robot pilot will appear only rarely (20% chance, if at all, depends on selector is working)

you need to use the new names in the models to make it appear at all.

it will possibly interfere with the existing pilot model (some submodels have the same name), in general the latter processed model will be used of two with equal names.

http://pioneer-universum.web.officelive.com/Documents/pilot1.zip

http://pioneer-universum.web.officelive.com/Documents/0_robot.zip

http://conceptships.blogspot.com/2011/10/concept-ships-by-adam-burn.html

Wanted 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 sure

i 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 it

but it would be a shame imo, if we would all follow anime style

and 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 school

something own, special

ugly, crappy or not but unique

i 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 made

i hope someone will check them out please, i have no running pioneer at this time.

http://pioneer-universum.web.officelive.com/Documents/sub_models.zip

next 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 texture

i 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.

http://pioneer-universum.web.officelive.com/Documents/terra_actualpilot.zip

http://pioneer-universum.web.officelive.com/Documents/terra_newpilot.zip

might 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 viper

i 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.

http://pioneer-universum.web.officelive.com/Documents/viper_ch_nopilot_nopolice.zip

WAIT!

it 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.

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).

get_arg(1) for alpha 15 and earlier, get_time('SECONDS') for alpha 16 onwards.

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/coded ... l-cpp.html

This 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 perhaps

it uses already math.random() (never used any else for models, wasn't possible i guess)

might look a bit weird 😉

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.

that's made very neat! i like it, thx

"

FLYING open flight (includes autopilot)

DOCKING in docking animation

DOCKED docked with station

LANDED 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)

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 dynamical

but 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 😉

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...

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.

This is pretty much what data/modules/TradeShips.lua does, though it is far more advanced.

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.

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. (-:

thats very true ....the chances of encountering another ship would only increase around a planet or space port of some kind anyway

i 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

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.