WinkAllKerb''

Most associate age only with the number of time thay made a revolution around the sun, this is the most common def. Age are ageS it's not like there only one pole we're mature immature at. That's being said child & teen are an endless source of surprise and enlightnement, and, as each generation goes they are far more concerned by space than most of us currently really are. Question is what kind of space you expect for your child, and how to share them thoose valor. KSP get an amazingly strong potential here. (Moonraker one more time? really ?, moon belong to US cause of a flag, glowing BigMac in the sky @ night time because they spend money redirecting an asteroid, etc. )

nice euh sinon tient Ubio v'la un parapluie y a de l'orage c jour-ci bon courage ... ralalalala misere ...

Delayed, watching for update/modding tools stabilization curve i made enough various modding test to know @ witch rate i can produce the stuff i want. When the above will fit the effort i want to put into modding... Presently a bit AFKSP, but still around.

black hole are like anyone digestive bodies, nothing more nothing less and not so exceptionnal at all despite scale(s) (time and else) it applies. *shrug* Only difference i see is "l'horizon des évenements" wich has no real equivalent in our digestive process but it's kinda like optic diffraction applied to time ... could be interesting but will require playing with huge time "warp" to appreciate it huhu

Thanks +1 101% planned, watching squad/modder moves regarding this, secretly hoping for a "tweakable" param aplliable to large range of device for this instead of an additionnal plugin for now, (for some eva "device" activation). yep true true, got a lot of things in mind regarding door(s)/others animations, time-rescaling them /rearanging keyframes is easily doable. Still got to focus irl atm. (but most of the part side groundwork is done so shouldn't be a matter at all to produce a big update pretty quick when irl is "fixed"). Chears.

an empty blender object (axis also work), or a simple transform in unity, y axis is the pivot axis, and z point kerbol. Stick as much as possible squad part hierarchy + nomenclature will help for first try. (from the few early tests i made appear that you can have an animated suncatching solar panel to work even if the solarpanel {module} in the cfg is nearly empty of any param just using same nomenclature as squad for the main functionnality due to default values call, alternative nomenclatures/hierarchy tend to bring more trouble due to this)

you can't, KSP ignore/overpass some unity parameter in many different cases, wish i can give more clue about this but i m more a generalist than a specialist isolate iterative testing most of the time the simpliest way to figure them out one by one.

very interesting i keep using png for testing/readability tuto purpose for now but will follow how all this evolve thanks to you all for thoose explains.

http://forum.kerbalspaceprogram.com/threads/43491-Moddeurs-Fran%C3%A7ais/page3#22 you can check thoose tutos (fr), in addition you can also try adding/removing some param from the solar panel module{} in *cfg to experience how it impact with the in game object. + using same name as squad vs the name you want and how some default value are applied @ some point even with an almost blank module{}. (wich is also interesting for lot of other modules)

yop, nope 0.23 not seem to impact at all on what work and what don't with the parts. I keep testing a few functionnality i want to integrate (especially wheels) and improve the one already in. Mainly focusing the geometry splitting and variations of some mesh regarding welding & modularity with squad symetry/asymetry standards. +1, just enough not to hurt to much eyes while testing some other things, currently in a KevinKraft state, but yup i put more interest in the concept behind (somwhere in an 'antichamber') than what it look like for now (a bit brainwashed by irl so dunno at all when it will come)

always nice to explore some new path of doing things to improve shared function and ergonomics of important feature. Great initiative

each collider = more phy engine calculation wich is not good at all as it's actually one of the main limit, for testing/first shot purpose when you try to get a perticular fonctionnality to work (like your tries with emissive) don't bother you too much with collider but keep in mind that it's good to get a plan to simplify them as much as possible for your finished part.

Basically most nowdays languages use combination of 'Word made from caracter/pictogram' + 'Grammar rules to articulate thoose word to a meaning'. Same goes with computer, if your able to speak you're able to code don't fear yourself too much. Main difference is computer languages often use way less words and rules than spoken ones making them easier to handle fast. It's not like it's only a 25 years old concept . Frankly internet is so overflooded in the last 15years that it not always as easy to find relevants info between craps like before you just have to spend a few more time filtering amongst search results

doing so become real intereting with complex part with many different fonction. As Touhou explain in is Eva Iva tuto, he first create a basic part with a shared origin. You can do the same for anithing else isolotating each fonction you want to add to a part in a file. Breaked prefab from a single blend don't auto update once in unity for iteration fix and testing. Multiple prefab help doing thing faster as each fonctionnality you want to add to you part is separate from other and will auto.update in unity. Also a faster way to get quick what's work and what don't you can faster turn on/off each prefab/blend file (as well as turning on/off a perticular transform in one of the prefab). will save you lot of repetitive config param in unity.

bah, in fact not a problem at all ideas are like trees, they have many roots and many branchs, but more important there time reference are not human one, let's them grow like precious seeds even if you not control there evolve or harvest them yourself, it's like child, ideas are magic in some way

some other related things may be: - check your anim hierarchy (sometime better to split prefab and isolate/separate different fonctionnality top of root within different game object) unity animation(s) component is very sensitive to hierarchy and may dislike in certain case to be imbricated. - blender layer and unity shader, from what i experienced usually better to separate shader by layer in blender if you use multiple ones keep trying with a simple geometry like only a cube and you should point out what you missed.

speaking of coding also keep in mind that all language (wich is not at all restrictive to computer languages) are built on older ones ... (mostly to add some protective restriction or wysywig them) speaking of computer languages they always end in binaries whatever the one you use, are you allowed to do this: yes or no. (but i believe it's useless to remind ya this as your a good coder So If you keep this in mind when using any languages you should be able to quickly find out what is doable or not. And not waste too many time attempting doing something if you clearly identify the language restriction @ first and how to overpass some of thoose restriction using common syntaxe/operand most languages are sharing due to their inherent basic genealogy. old basic shared operand (even transformed) are most of the time the key to solve things as they are the ones with the less restriction. and finnally if you got a good coding base knowledge, reading mods available source should be enough to learn the language, think 'Champollion' and you ll get it fast .

aaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhh mech jeb mech jeb again and again love the drawing, i myself use it a lot, fact is i have totally no interest in piloting vessel themselves, plus i landed on the mün on second try (after leaving kerbin orbit and reach the mün for the first time) with only stock feature. Really, imho mech jeb save me from all things that i feel boring to hell like piloting, or doing all the math myself for each flight (but this is very personal, i can undertand people who have interest in piloting, even if i will never understand the fact of non stop arguing about mech jeb is evil or not rightly wrong is'nt it ?

I m just starting making a set melting existing ideas with my own. Very rough and basic actually but promising. @vrana love your gallery very nice design.

for the part thumbnail it's linked to the "whereintimeline" when you save the blend file. wich is different of vab + launchpad view playing with anim start/end/reverse in blender is also the simpliest way i found actually, (you can quickly reverse an anim using 'dope sheet' or 'nla editor' view), then animswitch= + animtime= (appear that anim switch no longer work alone like before but i never really used it so can't tell) can offer a little flexibilty on first play + direction and .23 and tweakable will definetely allow a little bit more flexibility with anim.

try this out: http://forum.kerbalspaceprogram.com/threads/25023 play with 'intensity' for light and the 3 'emmissivecolor' value (also notice that regarding light and shader ksp overpass/ignore a few unity param). Try step by step you part with this tuto you should be oki.

missed a vandetta whoops, should'nt have been away so long .... regarding thoose kind of feature i m wondering if there not a way to simulate the process @ some point something like: @loading/leaving scene @docking/undocking @statusvesselmoving true/false (// stable orbit) @else (?) get: current time/date when @modifier precalcul/update result via math in a minimalisitic log file + show part/of precalculated result or alike not yet looked deep in the plugins stuff but from what i have seen here and there so far seem an alternate approach for multiple scene / 2,5km limit simulating thing at some time stamps modifier insteed of always. (just a thought between others anyway) definetly need a terrain mapping feature/addon, (same with sat relay time realisitic or/and not)

Thats probably fairly easily doable, thats why they probably focus something else i guess. But we definetely need to be able to move our crew within assembled part will come sooner or later for sure. @sarb: nice you maintain it.

3bis. and finnaly read and re-read thooses links to headache after each succesfull or not attempt to do something. Good luck

you'll find all you need in Hoojiwana modding link compil thread (light + emmissive + engine sections) Hope it help.