this time for real

both Models will run in Genesia (both are zipped to use as MOD)

Hullcutter

[attachment=2656:hullcutter_lmr_14-07-10.zip]

[attachment=2657:Bildschirmfoto 2014-07-10 um 20.01.25.jpg]

Crecerelle (Kestrel)

[attachment=2655:crecerelle_lmr_14-07-10.zip]

[attachment=2658:Bildschirmfoto 2014-07-10 um 20.03.43.jpg]

the last error was a unused .obj and a displaced gun at the hullcutter and wrong thrusts for the crecerelle.

the crecerelle is untextured but the model is uv unwrapped and file contains a uv map.

@geraldine,

a lot of music

before i answer to anything,

 

vuzz, you reported a problem with the "Hullcutter", in hope this model will fix this.

 

Bildschirmfoto 2014-07-10 um 17.10.09.jpg

 

further i made a quick "new one", formerly it has been called "Kestral" but the author of the model i can't remember, neither i find a entry here on SSC when i search for "Kestral". the model has been renamed by me to "Crecerelle*, which means "Kestrel" (the ordinal name was "Kestral").

 

 

Bildschirmfoto 2014-07-10 um 17.09.26.jpg

i've never reported nothing ? 

i've just make that on Genesia : "- Fix matvar interferences (?) of the cuttin' hull on Hullcutter" ( quote from my Changelog) 

with this fix my actual hullcutter model is ok .

PS  you take time to debug something i've already fix on Genesia . Please, as i've say you since a long time , take a little time to read Ghangelog.

however, this one is slightly different to the old model.

it solves this little problem

can't see anything? that's the problem 😉 the cockpit should be visible from this angle but gets "obscured" by the transparent geometry in front

now it looks like this,

[attachment=2659:Bildschirmfoto 2014-07-12 um 19.57.33.jpg]

i guess it's better as the version in scripted gepmetry, because if you take a closer look at the old model you can even see parts of the hidden geometry.

further in the highest lod the visible "machine parts" are now excavations and not just a overlay. the blinking lights (computer) i can still add to the new version, the laser can be easy positioned at the bottom of the ship again and if i remember right i used the "squad colors" for the hull, this i replaced with the colorvariable material now. i guess that's all in which it differs, the "nav. robot" is a matter of choice.

Yes , i can see what you mean on this shoot :

So , i'll download your new version and after test i'll integrated this one on the next release if it rule ok .

...  Great job Gernot !

Despite i've found some littles adjusts this one is really an improvement with his "true cuttin' hull"

The adjusts i've make :

--  Only one group of main thrusters have the true parameter, so i've activate this one for the other ^^

( really like your logo "Gernot66" on this screen )

-- The material of the registration text was in semi transp ( 0.4) , i've put this to 1

-- And finally I've slightly offset towards the rear the pilot ( he have now his hands on the joystick ) ^^

Thanks a lot Gernot , for this improved model, your'e alway the BOSS 🙂

while i added the "little computer" and found some more small issues, like the cutting out text or the lod problem it had (the chassis and other parts vanished to early), strangewisely it seems it doesn't matters what bounding radius i enter and it takes since a while now the "real bounding radius" which results in that each (sub)model has a different lod pixels now and (however) it's IMPOSSIBLE to determinate a congruent lod (while otherwise you could have said a (sub)model has a bounding radius of 10 (the whole model) even if it's maybe only 2, but the same lod pixels as for the whole model result then in the same visible distance).

similar lod problems i noticed on many of my models since a while.

the laser i mounted again on top, because else it covers the hatch on the bottom.

edit:new collision mesh

[attachment=2664:hullcutter_lmr_14-07-13.zip]

to use the outer main thrusters even as lateral (linear = false) was willingly done, but feel free.

besides, i neither would have changed the autopilot behave and to set a equal thrust for main and retro,

i didn't think that's the idea. to have ships with different specs is more important to me as to have many.

there might be a ship with good braking capabilities but then it must leak of something else, i.e. little thrust overall.

further i guess the thruster models resp. size of (if there are some visible at all), i used should reflect more or less their use.

i.e. for a "Eagle" this would mean you would have to fix the large nazzeles from the back even on front to get the same thrust, resp. something which looks like. at least this would be reasonable then if main and retro thrust is the same.

like i said depending in the ships "layout", a fighter will usually have a very good main thrust, but to have such a thrust in all directions would result in a quite large engine, while a "maneuverable cargo unit" has nearly no thrust but therefore the same in all directions.

but well, that's just what i guess.

[attachment=2665:Bildschirmfoto 2014-07-13 um 10.40.33.jpg]

[attachment=2666:Bildschirmfoto 2014-07-13 um 10.41.28.jpg]

[attachment=2662:Bildschirmfoto 2014-07-12 um 15.53.44.jpg]

[attachment=2663:Bildschirmfoto 2014-07-12 um 15.53.03.jpg]

i've adjust retro to foward value due to the fact that now in Genesia the ships don't retro facing during the decelleration phase , so now they need same power to avoid crashs , (Remember , Genesia follow his how way of dev ^^) the autopilot of Genesia is not the same of Pionner's.

Please again , read carrefully the GHANGELOG GENESIA .

that was just what i ment i never would have changed this, but it's your decision.

the fact that the autopilot will turn the ship to "brake" is based on the principal design of a spaceship resp. rocket in the extreme case.

for a "rocket" (or even the odd space shuttle) you will have only vertical thrust in one direction, no retro thrust (or only to maneuver, but this won't be much, for the spaceshuttle it's the power the expansion of boiling water produces, that's already enough to maneuver), to maneuver a "rocket" only little thrust is (would be) needed.

ok, maneuvering with steam isn't very agil neither you could lift a ship from the ground.

but obviously this principal design will stay, except all thrusters, or in your case retro thrusters must be sized the same, however if there would be a difference in the size of the nazzel or not, but at least of the whole engine.

of course a ship can be designed under this aspect (e.g. a sphere, or we simply assume some "magical device" instead of thrusters), but what about the other extreme, the rocket and everything between them? therefore i guess this ordinal behave of the autopilot should stay.

apart from this "technical" aspect, in my opinion you loose 30% of the character of a ship (maybe more?), because the character is it's agility and this is given by main thrust, retro thrust and lateral thrust.

which is again for the extreme if a rocket a clumsy ship (no or weak retro & lateral), for a airfighter like type a very fast but less agil (deceleration is important here as difference in other terms "character", for a let's say "saucer type" something balanced (very good lateral) but not very fast (for a cobra i.e. i imagine something between "saucer" & "fighter") and for a transporter something strong enough to lift off but overall slow.

if that is reasonable from the technical aspect is to me only secondary, important is the character.

at least it's worth to think about?

http://www.jades.org/shiprevs/eagle2.htm

yes, probably they had a "day off"... however.

in Genesia there is lot of ships with a cap > 100tons, i prefere see a millfalc or or a lanner , or best, a ncc1701 enterprise decelerate without retro facing despite i loose 30% of ship's character , afterall i have in rest 70% of character ^^ , that make enought difference bettwen ships . Yeah i prefer that instead see the enterprise make decel like a lunar module,

In the game we are after 3000 year and i hightly doutb that ships move like in the 20th century.

To resume , i think this compromise is a honnest solution for a futurist SciFI game.

ps, 

I have long hesitated before doing this, but after many driving tests (manual) I think it does is not so bad as that.

 

equal thrust for main and retro

Ok, that's just plain awful.

matter of choice, i was just suggesting.

[attachment=2672:Bildschirmfoto 2014-07-14 um 15.48.12.jpg] [attachment=2673:Bildschirmfoto 2014-07-14 um 15.48.38.jpg] [attachment=2669:Bildschirmfoto 2014-07-14 um 15.45.35.jpg] [attachment=2677:Bildschirmfoto 2014-07-14 um 15.47.29.jpg] [attachment=2676:Bildschirmfoto 2014-07-14 um 15.46.39.jpg] [attachment=2674:Bildschirmfoto 2014-07-14 um 15.49.09.jpg] [attachment=2675:Bildschirmfoto 2014-07-14 um 15.49.59.jpg]

Ok, that's just plain awful.

Please, you must say " i think it's awful".  thanks to put the name of the member on your quotes !

And nothing is fixed , i've just discover that the autopilot have some problems to reach orbits with theses news parameters ...

... OK  nothing major, in fact, the autopilot turns the spacecraft into orbit shifted (elliptical?), it just remains to check the orbital parameters to find the right orbital speed and adjust it manually. 

matter of choice, i was just suggesting.

I can't really agree. If all ships were designed (like you said) with comparable thrusters sticking out in all direction, then yeah, it would work, but otherwise it just cripples aesthetic-mechanical integrity of the project.

And if all ships were designed this way it would still rob the project of one important way to make ships handle differently and have different strengths and weaknesses.

Rien compris a ton charabia DraQ

Alors avant de commencer a polemiquer stp lis  le texte "about genesia" , il y est clairement explique que c'est Ma version Personelle ( que je met a la dispo de ceux que ca interresse)

Si ca te plait pas et ben continue a jouer a Pionner et lache l'affaire mon gars ( tu commence a me saouler, apres tout avec ton cursus ca dois pas etre bien complique pour toi de modifier les valeurs qui te genent , je suis chauffeur poids lourd et j'y arrive bien)

Geneisia est open source tu peut y bricoler comme bon te semble.

Trop fatigue pour tapper en anglais , apres tout y'as Google traduction.

PS pour ta gouverne Paragon fonctionne aussi sans retrofacing et avec des valeurs egales en acceleration et decceleration et jusqu'a aujourdh'ui ca n'a gene personne. j'ai choisi cette voie pour MON Genesia et ca ME convient. ( et en plus je pense que bon nombre de supporters trouverons ca chouette )

@ Gernot , stp arrete de causer de Genesia comme si c'etait un projet ,( c'est mon trip et ca le resteras) ca eviteras a chaque fois d'avoir a expliquer a des gens qui ne prennent pas la peine de lire les notes incluses dans le jeux qu'ils polemiquent sur un truc perso ( C'EST un MOD ).

on s'en sert si on aime ou on oublie si on aime pas , point final.

@ Vuzz

Could you please use English, which is pretty much the international language today?

Nie damy rady się porozumieć jeśli każdy będzie pisał we własnym języku.

 

 

Nie damy rady się porozumieć jeśli każdy będzie pisał we własnym języku.

 that's just plain awful.

Justement ! J'ai pas envie de communiquer avec toi mon ptit gars

"schpillt doch kei rollä ich verstah nä so oder ä so" (in case, just use the "idiotikon" which will explain allemanic idioms to you)

nah, ok... before i answer to anything, welcome "Potsmoke66" back. i finally made it to have web in one of the wealthiest countries in the world and that's FINE, GREAT, just FANTASTIC!

from now on nothing can be wrong...

[attachment=2680:Minusch01.jpg]

he, he, no one can look as relaxed as such a predator like her.

i miss her, but she's well and still hunting.

this cat is marvellous (like most of them) i had to leave her alone (i moved to a city which is no place for *such a cat) after my divorce, but she managed it to stay a year alive (even in winter), until someone picked her up.

*such a cat, she never knew how to handle cars, usually when i returned from work she was awating me, not at home, in front of the railroad station, now someone should tell me now that cats can't be friends just like dogs. one day she only heard me walking by, ran over the street to "greet" me and nearly lost her life under a car (such a friend).

btw, she's a farm cat, she grew up to handle life by her self, the only "food" farmers give to a cat is some watered milk, they have to live by prey to keep the rats off.

Minusch, Mish, however, i used to call her "Mish Mash" for two reasons "Mish" is maghribian for cat, "Mish Mash" is her fur. 

just like a wiches cat she used to sit on my shoulder (when she liked to attract me and i have to say i trained her to do so, she never felt really comfortable in this situation).

somehing different, it didn't really belongs to Pioneer, but i was not little surprised when i started "FFED3D" on my machine and this happened

(wear some cheap blue/red 3D glasses)

[attachment=2681:ScreenShot_074.jpg]

it's actually the ONLY game on which NV 3D vision responds, which i have installed, but what do you think you can get out of it if a game supports it natively?

of course i wasn't lazy in the past few days:

(today i'm a little drunken, excusé moi)

sunrise over "Olympus Mons"

[attachment=2682:screenshot-20140720-053107.png]

and "guess the name of the Ship":

[attachment=2684:screenshot-20140718-141454.png]

would esperanto help?

it turned out to be english, french would work as well as a international language, a old battle between two large empires.

it seems still it goes on.

erm, i guess depending on majority i should be chinese...

ok, that won't work well, imho.

phew, i remember well how angry the my ex got, when i told her something like: "look latin letters have a enormous advantage to most written languages"

hmpf, i shouldn't have said such to a arab.

but well, the words are build in a comprehensible way from individual different letters.

even more, the letters are designed such clever that you can cut off half of the visibility and it's still readable (try it, it works)

show old gernot one language resp. written word with wich you can do this.

big respect, arabs drove ornamentical art based on their letters to a highest peak.

(if they invented the written word i'm not so sure about, hmm... i referred once to the system north american indogenes invented to "write" musical notes (in a farer sense)

the difference to symbols like chinese or i.e. aztec is hat they used no symbols, "only" a system of knots in laces, a system, systematic build, that's the main difference.

the purpose is to me secondary, important is this, a comprehensible system.

well for some is "bla bla" important, for others it was the sound of music.

but what i really liked to say is you can't top ABCDEFGHIKLMNOPQRSTUVZ, no language exept the latin ones can offer this, clean, comprehensible, logical, perfect.

forget a dot in arab and it means something complete different.

paint a symbol in chinese a little bit tattered and it becomes unreadable.

strike whole letters out of my text here, the sense didn't get lost.

i can almost do with them what i like, invert them, mirror them, hide them by showing only parts of the letters, still it's readable (in uppercase).

i guess what happened with english is pretty much the same, it's easy to learn for most.

you can make yourself understood quick.

and still we have sometimes problems when one is spain, one german, one english, one polish, one french and so on.

but it seems to be a matter of will "do i llike to understand", if not, two can speak the same language natively and still they don't understand each other.

one thing i know for sure deaf ppl have less problems of this kind, their language is international.

also to speak loud is difficult 😉

further, the cultures differ much and this means if i say "red" another one understands "blue".

to give a example i have to refere again to the north american natives.

to most of us (europeans) the color white represents purity, innocence, short all good things and behaves, black we see as, bad, dangerous, uncertain.

to them it's pretty much vice versa, black represents purity, is divine and so on.

speaking the same language often didn't helps,

but to be kind and willing to understand helps a lot, even if you have to use your feet and hands.

"real" latin languages like italian and (brasilian)portugese are easy to understand to, pronouncing is clear, what you read is how it sounds, not to much or no special phonetic characters.

(portugese? yes, i had a preacher from brasil, i can't speak portugese, but nonetheless i understood most of what he said after a short time.

sorry vuzz, but french is still a riddle to me, i was teached french three years in school still i don't understand it, english i learned... - i didn't had to learn it, please forgive a saxon like me).

in this sense, esperanto would be fine, invented exactly by following these rules, easy, pronounced clear.

it's artificial i know, rarely spoken, i neither can speak it, but had once the idea to learn it, exactly because of the named reasons.

it would be perfect as a international language.

however, english works well and this forum is in english. yes we have this "german pioneer thread" but it didn't looks like a good idea to me, to be fair we would need theen a spanish, a polish,

a whatever language forum to, obvious that this isn't possible.

well and if i lke to write in alemannic then i visit a alemannic forum, but pioneer won't be the thematic we discuss there.

---

@vuzz

that wasn't nice of you my friend, why do we meet here in this forum?

to communicate, that's the purpose of a forum.

then well, let's not get picky such destroys any communication between different cultures.

"think big" my friend.

"généreusement", if you like that better.

we exchange thoughts and ideas, we like maybe to have a little fun by the way, and of course it's a sort of entertainment, when we use it wisely.

i didn't think DraQ lliked to insult you, maybe he chose the wrong terms?

how often do i used a wrong term or even you?

"think big" and "understatement" aren't just words, it's a way to go (a way of living, but "a way to go" i like better)

"null problemo" - no problem vuzz, everyone has caprices.

make some sunshine (like my daughter said once: "it seems to me everytime i have a bad mood the weather turns to be bad")

stay naive as a child,

aim at the heart,

but aim high!

----

don't take the following to serious, but isn't it funny?

a german mediates between a pole and a french.

get allies or i...

yep!

just for the fun of it,

the name is the motto 🙂

what follows is all scripted geometry, incl the "cathedral" lookin-a-like sealed groundstation,

ah, i know the ships look very familiar....

and this somewhat new "bulk ship"

if humor belongs to music it certainly belongs to a game as well

sometimes the results of the random name concatenation are really funny or even fitting well

[attachment=2720:screenshot-20140819-130934.jpg] [attachment=2721:screenshot-20140819-131022.jpg]

probably Vuzz is interested to get this funstuff in genesia?

however it's rather simple, just a few lines of code and a large table for the "names" to put in "lmr_functions.lua"....

...i forgot you don't have this, i set up "lmr_functions.lua" to have all functions relevant for th LMR in one file, some i took from "lmr_models.lua" in the "data" folder,

the rest are functions which became handy over the years, such as the "selector" or "missile helper" functions.

i placed them to "lmrmodels" folder and named it "00_lmrfunctions.lua" to grant that they will be executed in front of all model scripts.

one could also join these two files (lmrmodels.lua & 00_lmrfunctions) to "lmrmodel.lua" as well.

it's a "work in progress", but most functions should work as expected.

(a reason why i fumble around with the basic models, it makes it easier to keep them updated for the new functions if you haven't "100 models" to take care of, further all scripted geometry is in a single large file. also i made for this a "01_submodels.lua" which includes all untextured sub-models i need for this experimental alpha30 release, but i guess this won't work so easy for "Genesia").

some changes i made to the "missiles helper", thus it won't work with "Genesia", except you update all the models which use this function

the function call is now: missile(index,vector_position,vector_x,vector_y,scale) and pylon(index,vector_x,vector_y,scale),

misseles usually won't need a orientation (vector_x,vector_y), but i need one for the pylon and the vectors replace the former "orientation, 1 or -1",

makes it first easier to understand what it is for and second both functions accept the same arguments (handy for a "FOR loop").

missile and pylon use the same "index" and if a missilie is fired the apropriate pylon will be removed (should, needs testing).

further it keeps the missiles in scale 1:1 but you have to enter the final scale of the model therefore.

 
missile(index,position,vector_x,vector_y,final_model_scale) not "missiles scale"!!!

same for
pylon(index,position,vector_x,vector_y,final_model_scale)

many other functions have been refined and a few new i have added, such as:

 
"counter":

simply counts from 1 to 10 in seconds stepping(!) and stops at 10 (could be useful to animate something which else can't be animated, e.g. open the doors after docking. other purposes will be anything where a stepping rate becomes useful and you like to start/end the execution at a given timepoint.

i need to work on that but that's the idea behind)

---

 
"rot_gear":

a simple rotation helper to easier animate landing gears, it returns the full vector you need to rotate a model after entering,

 
rot_gear(degrees,vector,delay,offset,[timer])

"degrees", obviousely degrees to rotate,

"vector", specifies the vector/axis you like to rotate around, negative values are allowed, resp. suggested to change between clockwise and counterclockwise rotation.

the function adjusts the difference between them and keeps any (sub)model in it's ordinary alignment at start of the animation ( = 0 ).

but you can also enter negative degrees to reach similar.

"delay", at which timepoint the animation will start

"offset", at which timepoint the animation will end

"timer" is optional, probably one likes a different timer as "wheel_state", for whatever pupose.

it has limits and it's not possible to pre-rotate (correct position of) a wrong aligned (sub)model.

 

also i guessed once to pass the whole "call_model" argument's to it incl. the name of the model to call.
even more simple yet flexible and it would even allow to get around the prerotating for a "Z" rotation
it would generate a new submodel itself, but this is a heavy change to it
it would look then like "rot_gear(degrees,vector to rotate, delay, offset, model_name, v_pos, scale, [timer])" and will call and rotate the (sub)model by itself
vector_x and vector_y doesn't have to be passed to it, the function will determine them by the desired vector to rotate around).
quite a few more arguments, but therefore you don't have to take care about anything.

 
tell me what you think about that idea, i guess it's worth to try, but will change the whole thing.

to rotate along "Z" axis a (sub)model must be prerotated, since i liked to keep the call simple i assumed a given pre-rotation which is

"+Z" (rear) becomes "+Y" (quasi, tilt "nose" down).

example:

local wheel = rot_gear(90,v(-1,0,0),.33,1)

call_model('gear1_wheel',v(0,1.2,0),v(1,0,0),wheel, 1)

"rot_clock":

similar to "rot_gear", a simple helper function, it let's rotate something continously.

 
rot_clock(vector,[fractions])

"vector", is again the axis to rotate around and CW or CCW movement.

"fractions" is optional. without it assumes "get_time()".

the timer i used for the clock is fractioned in 1 second steps (that's why you have the default timer), to keep it 100% synchronized with the time in the game

(the small error of Pi = 3.1416... will lead else to a wrong time on a analogue clock after some days)

"fraction" means "seconds/minutes/hours/days",

no fraction specified means "it will use simply get_time()"

1 = seconds

60 = minutes

60*60 = hours

60*60*24 = days (resp. 60*60*12 for a analogue clock)

example:

local vector = v(1,0,0)
if lod > 1 then
local minute = rot_clock(vector,60)
local hour = rot_clock(vector,60*60)
local hrs12 = rot_clock(vector,60*60*12)
call_model("clockhand", v(0,0,0),vector,minute, 0.65)
call_model("clockhand", v(0,0,0),vector,hour, 0.65)
call_model("clockhand", v(0,0,0),vector,hrs12, 0.45)
end

to use it to rotate i.e. a "scanner" you would call the function:

"rot_clock(v(1,0,0))" as a example.

it's possible to lower (or upscale) the speed of "rot_clock(vector)" if no fraction is specified by simply divide (or multiply) the returned vector, i.e.:

local rot = rot_clock(v(1,0,0)) * 0.5

call_model('rotate_me',v(0,0,0),v(1,0,0),rot,1)

this needs some testing for the "default rotation", but the "clock" works 100% accurate.

i will see, i know i have a accurate working

(i guess, this one isn't easy to make proof of, since it has no "clockhands" resp. are replaced by "dots" which circle around like a "planetary clockwork",

e.g. minutes circle around the hour "clockhand", seconds circle around the minutes "clockhand")

"clock" (sort of) which doen't uses fractioned seconds and will animate seconds smoothly.

[attachment=2723:screenshot-20140819-225613.jpg]

---

a not so much needed, translation helper

which simply adds the delay & offset to the "vlerp" function.

 
translate(v1,v2,starts,delay,offset,[timer])

timer is again optional else it's "get_animation_position("WHEELSTATE")"

same as for "rot_gear". delay and offset mark the start and end timepoint.

v1 and v2 are the vectors to translate to

it's very similar to vlerp, the difference is it returns a single vector and you can set delay and offset, instead to use the "math.clamp" function.

for both, "rot_gear" and "translate" you don't have to take care about the duration of the clamped time, it's calculated always up to 1.

---

something i know marcel wished it years ago 😉

 
autoscale_text(scale,offset,string_input)

it scales any textstring to a given size

 
scale, is the default scale of the text you choose, i.e. the scale you have though the label is sized properly on the ship.
offset, is the length of the string which uses the full space you have in glyphs, i.e. 7 for the label.
string_input, is simply the string which will be displayed, thus to autoscale the text (all above models use this to scale the "legal names" to the size of the label).

also useful to scale the textstring of a spacestation, of course.

it simply returns the scaling value, example:

local shipname = legalname()
local textscale = autoscale_text(.5,7,shipname)
text(shipname,v(-1.87,-.6,-6.3),v(-1,0,0),v(-.1,0,1),textscale,{center=true})

for a stations label it looks like this:

local label = get_label()
local text_scale = autoscale_text(20,10,label)
text(label, labelpos, v(0,1,0), textdir, text_scale, {center=true})

in this example the length is "clamped" to 10 glyphs, means as long as the string is shorter as or equals to 10 the scale will be the defined scale of 20,

as soon as the string is longer as 10 it will be scaled down to use the same space as for 10 glyphs.

---

now, the funny "legalname" function 🙂

 
legalname()

needs no arguments and simply returns some string like: "LOUSY OATH", "RUSTY SUN" or "UNLEASHED SARDINE" (i like that, a "unleashed sardine"),

but also cool stuff like "GALACTIC HELLCAT".

("PAST HACKER" as well as "FUTURE HACKER", "FINAL TRUTH" as well as "FIRST LOVER", "SKY WALKER" as well as "PLANET EXPRESS", depending on if this will be ever selected)

in general the "prefix" is a verb and a noun follows, but there are exceptions to this in the table(s) because of "which will fit to what", thus you find the nouns "Sky" and "Planet" in the prefixes.

the reason is simple "FINAL STAR" doesn't makes as much sense as "STAR FISH", "STAR CAT", "STAR WALKER", on the other hand, "STAR SUN" or "SKY SUN" is neither much senseful, but a exclusion which won't appear often.

of couse "PLANET" is a noun and both tables could contain it, but a possible "PLANET PLANET" or "PLANETARY PLANET" is most of all shitty.

doesn't makes sense always but i can't get enough of the funny combinations, it tickles me to read "SILLY PROMETHEUS" or "ONE EYED COMET".

i chose the table where a word belongs to intuitive, not based on a given rule, combinations came to my mind while i was writing the script.

sometimes it's stunnig what results of it e.g. the "ROSY VERA" on a red/pink ship. besides "VERA" is one of the very few names i used, if not the only one.

but when i started it out i took referencies from the web and searched for famous naval ship names, "VERA" is one of them and i kept it.

i moved then to airplanes thus we have a a "SPITFIRE" as well.

---

a few functions i would have liked years ago, like "mirror x" (to mirror a vectors "x" value) or "interpolate" (evaluate "halfway" of vector1 to vector2)

both handy for localized vectors in scripted geometry.

---

let's see if i'm in the mood i will fix the functions once everything works fine for "Genesia".

but to change all the models to the new functions.... it will need a lot of time and work.

---

ah well and finally added a few lines to "main menu" which displays a random quote at start of the game:

"any working program is obsolate".

---

the functions script:

[attachment=2722:00_lmrfunctions.zip]

the fluffy 🙂 is still alive on SSC

---

@geraldine

a question,

do you know if the "Armstrong Whitworth Whitley" Bomber was named "Flying Barn Door" (easy target) only by the germans, or does that makes sense to you as well?

just because of interest and while i was looking for names of planes.

besides today this term is used for any oversized clumsy airplane in general and if you search for "fliegendes Scheunentor" you get quite a lot results to it.

but the genuine "fliegendes Scheunentor" is the Armstrong Whitworth Whitley

----

@Vuzz

if you ever read this (?)

i found it handy to localize certain things on top of a models script.

this is the scale, the bounding radius and the lod_pixels for all (sub)model of a ships model.

e.g.

local bird_scale = 0.8
local bird_radius = 50 * bird_scale
local bird_pixels = { 50 * bird_scale, 100 * bird_scale, 200 * bird_scale, 0 }

(it's named unique here because i have more as one model in the "ships.lua" script)

for two reasons,

a) if i like to change the size of a ship, slightly or not, i only have to look at top of the script for the scale, bounding_radius and lod_pixels will be scaled as well

(therefore the "xxx_radius" has to represent the radius of the unscaled model)

 
B) i transfer "scale" and "radius" to the ship specifications, to calculate proper thrusts with this little helper function (script) which is to place into the "ship" (specifications) folder

--THRUST CALCULATOR
thrust = function(grav,tara)
return math.floor(grav * 9806.65 * tara)
end

in the ship specifications it will look like this

local scale = 1.5
local radius = 25*scale

--tara = hull_mass + fuel_tank_mass
local tara = 50
local main = thrust(18,tara)
local reverse = thrust(9,tara)
local lateral = thrust(4.5,tara)

the idea behind was to calculate the thrust for the empty ship (not the ladden), "tara" weight in other terms.

scale and "br" i need to calculate a rough angular thrust value (of course one can use the "brutto" weight as well, but my decision is "tara"

the idea was that a shup probably can hold up to 100tons but probably can't lift fully ladden, transporters mainly).

a fighter will have a very high thrust "tara" but it will never be "empty", usally the engine and some equipment uses up most of the capacity.

my the idea was 10G is something we can stand, i've read that the "RLM" (Reichsluftfahrtministerium) tested pilots for their rocket driven planes up to 20G?!!

that's extreme! extreme extreme!

ergo my fighters will have a thrust when ladden roundabout this value of 20G. "tara" this will somewhere between 30 and 40G's.

3200 or 1939 a human can survive up to, let's assume 20G (usually 10G).

erm "pressure suits" well, hmmm.... never heard of one who survived being thrown in a tank of blood plasma, even if we could "breath" this, theoretically,

practically our mind won't accept this and i assume you will die, before you start to breathe a liquid.

besides who would dare to be the first voluntary for such a experiment?

all the rest of ships have a rather low thrust which is "tara" somewhere between 15 and 20G, this to avoid that a medium ship is when empty "faster" as a fighter.

to me this seems to be reasonable, however one could set 100G as thrust if he likes to ( i won't).

lower specced ships are more fun to play and in my second setup for alpha30 which using everything except FE2 and SW ships

my "thug" the "Maneuverable Cargo Unit" (now it's called "Lander" and the triple version "Lifter") is the starting ship and has a rather low thrust especially lateral

needs to take care what mission you subscribe to.

 
INTERMISSION

btw. I NEED LOCAL TAXI JOBS! who likes to write them?

i like to start the game with "nothing", a interplanetary vessel & 100 credits, no autopilot no anything, nothing but the rotten "Lander".

since i started now a few times in this way i find the autopilot alreadey boring in some sort, nothing to do for me except to point and click.

i never liked "point and click" games much.

Walterars "Scout" missions are a refreshing exception, at least you have to do a little.

i would have some suggestions to that, Walterar...

Walterar?.... (still alive?)

i would like i.e carry someone to a given point, long and lat we can request or set, one only would have to display this optionally on the hud.

besides does anyone ever used the "low thrust", this is depracted for real it has no use to me, but to show the lat. long. without pressing "CTRL-I"

would be handy for missions to write, taxi "carry me to planet "x" cooordinates lat. "y" long "z", pick me up at "some day"".

or "need data/probe from planet "x" at coord. "y" "z", and so on, these things can't be handled by the autopilot and this means action without fighting.

ever tried to reach a given coordinate on a planet?

it's a real challange.

i give you some coordinates to find on mars (best use genesia with the proper height map, that's a cool one)

"Cydonia"                          "Olympus Mons" (actually on the foot hills of, cool sunrise)      "Utopia Planitia" (erm, "close to" it's a large region, Viking2 landed somwhere there)

:latitude 50.16716°            :latitude 22.917251°                                                                 :latitude 66.108268°

:longitude -4.654306°        :longitude -42.495296°                                                             :longitude -60.305812°

i made a small "error" when i was looking for the landing coordinates of "viking2",  i thought "dammit why does the program didn't show the lat and long for some objects?"

i haven't noticed yet that it's shown on the very right bottom corner, no matter where you point with the mouse, a drawback of big screens, you won't see all of it at once.

ah well, now you know where to place these cities...

do it it's worth a try

both,

find the coordinates yourself using "CTRL-I"

or

place the cities at the above coordinates, together with the height map they are some nice "landmarks" to visit.

what about "Boreo Syrtis" and "Syrtis Major"? well even these coordinates are known.

if you like i can give you the coordinates of any known and named volcano, crater, mountain or landing pos in our solar system.

the software i use for this is "P.M. - 3D-Atlas des Sonnensystems 2.0" it would cost a little fee, but i have it from a retail disk.

it's not the newest one (2006), but comfortable to use (unfortunately it's in german language).

"redshift" offers something similar, i own a old release of "redshift", this new solar system atlas would even cost a little, but i assume it's as good as i expect it from "redshift".

a cool "open source" program is, Celestia

END OF INTERMISSION

anyway you just enter the desired thrust per one tonne and it returns the thrust for the specified mass (no more guessing in what thrust it will end up).

"math.floor" i used to get rid of the unneeded values behind the floating point.

name='Corsair',
model='corsair',
forward_thrust = main,
reverse_thrust = reverse,
up_thrust = lateral,
down_thrust = lateral,
left_thrust = lateral,
right_thrust = lateral,
angular_thrust = lateral*radius,

how you set up "angular_thrust" is left up to you, i decided for lateral multiplied with "bounding_radius" (in fact it's the max. diameter of the ship)

it wil weaken the ships, but you can use "main*radius" to get more agile ships. (the value will be divided by two in the program, i even wonder why?

because "J.J" explained once to me that a simplified calculation would use the diameter of the ship and the (main or lateral? i can't remember) thrust)

however it's up to you how you like to use the "thrust_calculator".

now if you probably change the size (scale) of a ship, you only have to enter the new scale to the ship specs and the rest will be updated automatic.

change hull mass, fuel tank (or capacity) in the specifications, then reflect this in the localized "tara" (or brutto) and it will keep the desired thrust.

besides still there is obviousely something wrong in the engine, if i move a ship with the mouse it's like pointing with the mouse, there is no (no more, it wasn't always like this, compare to the alpha8 i linked) "delay" respectively inertia to "feel", while if you use the joystick or keystrokes it is delayed or logarithmic, how ever it isn't the same and moving with the mouse is ODD!!! it's like you would play "missile command" with the mouse.

changes which have been made of which i never was convinced if they are apropriate.

it looks to me like the angular thrust is calculated or changed by the engine to keep a given relation between main thrust and angular thrust (?)

if that is true, then it's wrong as wrong can be.

a thruster has a given power and not a power based on linear thrust, which would mean "oh btw, this thruster is only to rotate the ship, but in fact the thrust is higher as the main thrust to make the ships more agile" (or whatever strange idea was behind this).

if a lateral thruster has a given thrust the angular thrust can't be higher imho, how should that work if it's "smaller"?

and if this would be true i would use the angular thrust to accelerate if it's stronger.

actually (i stated this before) "space ships" as far as we have such, have very low lateral and resulting angular thrust,

it's only used to correct the course in free fall and "steam power" is enough to reach this.

ok it's 3200, but still a lateral thruster can't be stronger as the main thrust, in maximum it is to imagine all thrusts are the same if you imagine a "antigravity" engine, i.e.

however, something smells fishy here, i checked different setups and had the feeling whatever i enter to "angular_thrust" there is no difference noticable.

which let's me assume the whole thing has been changed and angular thrust has become "depracted" (like other tard).

economy is another weird thing, i changed a few things in the source and the result was unpredictable resp. not what i expected, it looks like "mining" type has

inverted specifications for goods to import/export (?).

anyway if i say "produces carbon ore" for mining systems, it returns in the game "longs for carbon ore".

the rest is ok and a "outdoor world" longing i.e. for robots longs for robots in the game, a "industrial world" set longs for meat, longs for meat in the game.

only the type "mining" looks like it's inverted for desired and produced.

but i need more experience with this to say if this is true and i think it isn't a good idea to respect this in the production / longing, the error must be somewhere else.

(actually my mining worlds produce anything except what would be to expect, carbon ore, metal ore, whatever mining produces, they long for them now

two possible reasons i see behind this, first i could guess of "let's make mining worlds longing for everything", second, "i like to dig for ore and to get a good price a mining world has to long for ore", both would explain it, but it's still wrong to me. obviousely the price for any ore will be very low in a mining world. ever played "ports of call"?

if i carry to much goods of a certain kind to the same destination the price gets inflationary, obviously and apropriate. in other terms, i don't have to sell potassium to argentinia they produce it and the price will be low as low can be, trading coffee or sugar to brasil will neither be a good deal. we say "Eulen nach Athen tragen" if one does so.

(but trading a "secret crater" of weapons to iraq will make you rich but prob. you loose your ship, one could never know in iraq. or you have to accept that after such every now and then your ship is in quarantaine, that's a sort of "economy" which certainly belongs to something like pioneer. do something illegal, maybe you won't get charged for it but you have to live with the drawbacks of your acting).

imho the idea of mining is dig for ore and sell it where they are in need of them, e.g. a industrial world, mining worlds will have more then enough ore of any sort and the price will be inflationary resp. should be, we haven't "real economy" like in "ports of call". besides would this be a big task? selling the same goods over and over to the same destination should lower the price. but it's not essentially, essential is that i can depend on what is "production" and what is "need", then i can setup a working economy).

sorry, looks like i'm sober and my posts turn to essays.

the ladybug... erm, ladybird

it gets more and more classic

- only scripted geometry

- only greyscale textures from a repository