InsaneDruid

I'll have a look and try to push an updated version soon. Also currently looking in the new shaders, so maybe even a wee bit of graphical update later. Also try to finally release my TKS in the foreseeable future, but work in uni has a tight grab on me, as COVID postponed many of our user studies and we are currently rushing to do as many of them in the timeframe before the next virus outbrake.

I'm still here, but my job & slowly ongoing doctorate ate most of my time. If there is a prob, let me know, actively seeking for errors is a bit problematic for me right now.

Thanks!

As we have fc.SetBits and fc.ClearBits , will there be a fc.GetBits() function to check if a bit is set? ATM I'm kinda thinking how to check otherwise, but as we don't have bitwise shift commands I am kinda stuck.

First, you either need old school fairings or, as this mod isn't that well maintained (like, mine actually - but i still work on it from time to time) you better use the procedural fairings. And then, its a matter of not letting her tilt too much too early. And nudge her sideways very gentle, only a one or two degrees at a time.

His own work: http://forum.kerbalspaceprogram.com/index.php?/topic/141066-the-iss-replica-project-proton-added

The best program is always the one you like the most. I work with Max and Blender in a professional environment and I like blenders streamlined UI much more than the hodgepodge UI Max uses where you have different UI styles cobbled together. Like there is a ribbon UI but there are also non-standard dropdowns and selection boxes etc etc. One of my collegues likes Max more, but even he hwas a hard time migrating from 15 to 17 as all the icons are different now. Blenders UI philosophy is clearly shortcut based, you have a lot of shortcuts to learn, but the same shortcuts work on all objects. You scale objects with the same operation like you scale timeline events and material node ec. Also you can enter values as formulas. There is a 1024 in a value-field, but you want it to be 4098? just type *4 behind the 1024. Want to rotate a vertex so that it aligns with the vertices of a 24 sided cylinder? Just type r=360/24*x (with x beeing how many steps you want to rotate). Max is much more Mouse based by default. You can use shortcuts but they tend to be different for every action. With max I use a spacemouse to navigate and a mouse to edit, but with blender the spacemouse isn't as effective (and needed) for me, as my hands are more focussed on keyboard and mouse. Want to add some more edgeloops to a mesh? Blender: alt-r , hover over on of the edges and use mousewheel up/down to adjust the amount of new loops to add, then leftklick. Max: Klick on edge-selection mode in the edit poly mode panel, klick on an edge, klick on "ring-select" in the selection-panel, klick on the settings icon of the connect-button in the edit edges panel, edit the amount of loops to insert in the popup menu that appeared, hit ok in the pop up menu. Yes there is a swift loop funtion (of cours it resides in the Ribbon Menu and NOT in the dropdown-field menu of the edit poly modifier), but it will only add one loop at a time and it doesnt half the distance automatically, so placing the loops is a bit harder or consists of adding the loop, selecting it and then moving it. There are some things i like better in max, like the auto grid function and generally the grid (transform orientations in blender) handling, but I use blender whenever I can.

I work since a week with MAS now and have all my props converted from RPM in this time. Everything went smooth and it's a blast to work with MAS. So much is possible now and its so easy to set up. So @Angel-125: MAS is the next logical step from RPM, which used to control the ASET Props.

Is there a (different) option to trigger more than one function on a collider event? Like: onClick = fc.SetTilt(0, 20),fc.SetTilt(1, 20) I just wrote a small lua script that forwards the parameters and calls the setTilt function on both cameras.

Just a bit OT: Your MAS_pb_Clock_KacMode Button (that is used to display if the stopwatch portion of your clock is in stopwatch mode or displaying the countdown to the next KAC event) could use a display that is working regardless of the instrument backlights. For example, add some indicator dots like the other buttons use. As it is now, it doesn't show anything when the instrument backlights are turned off, loosing its whole function.

Quick Question, where does the MAS_BITMAP_FONT definition go? Tried to put it inside the PROP{}, outside of it, inside a MASComponent{}, inside a MASMonitor{}, inside the PART{}, every time it throws NullReferences...

By looking through the wiki it seems MAS will solve most if not all problems I had with RPM. Nice!

There is a new update on the github version. It includes the 2017 variant of the proton medium launch vehicle as well as a rather drastic overhaul of the breeze-m. The RCS Tanks are now a separate model to allow the implementation of the independent high and low pressure fuel tanks on it, as it was requested. Along with this change, I implemented the different Phase 1 and Phase2 upgrades to the Breeze with different RCS Tank configurations (Phase 2 uses COPV tanks). Also, the 11d458 motors now behave like RCS and can be controlled with the usual RCS controls in KSP. I find it easier to control ullage for the breeze main engine (it is needed now under RO and RF) and also easier to used then in their function of fine control engines. Please have a look and report problems. RO isn't working for me with KSP 1.3 so I cannot really test it.

Use more geometry for the base mesh. Ideally, you should only use quads (use at-j in blender to automatically convert tris in quads). You seem to understand the problem, but you also seem to "fear" to use some more vertices. Don't be afraid. Use them where they are needed. You can only do so much with ultra low polycount. Also you use different vertice count for the inner and outer curves of a window frame. This leads to triangles, and usually to elongated ones. Always seek a mesh that avoids triangles by having egqual amounts of "corners". See your screenshot: each of the blue dotted line sould be an uninterrupted edge, yet your amount and position of vertices is never consistent, aways wildly mixed with vertices on positions where you dont need one and other positions in need of vertices left empty. Seek for tutorials with "mesh topology" in the title. Most of them are for modelling organic shapes, but the principles remain. Only if you understand what a perfect mesh topology would be you can decided where to break such a perfect topology to save some polygons. for example CG cookie has some older videos (old but perfectly fine and still true in all details) for free (only needs a free account on cg cookie) https://cgcookie.com/archive/learning-mesh-topology-collection/

Try enabling the aerodynamic forces overlay (default on F12). She'll flip when you point her out of the trajectory too much. In general, fly a rather steep "throwing" ascent where you just barely turn in the thick atmosphere. Just gently nudge her over and then always keep her nose in the boundaries of the prograde marker on the navball. Throttle down a bit during max q. Remember that this model has no reaction wheels anywhere that magically produces forces Also no fins. All she has is the engine gimbal. Of course you can add a fat reaction wheel to help. Also try controlling from the third stage during ascent, not the breeze or even from the payload. This will help to anti-wobble her a lot. See this video why:

If you also link the textures there might be more people interested to do this, as it would save quite some time.

Definitely stick with PS over Gimp, especially if you are fluent in PS. Unity can read .psd files directly so its really easy and perfectly integrated in the workflow with unity. I work on psd file the whole time and let unity convert it during exporting to .mbm (as it created mipmaps that way) and manually export to tga and convert the tga to dds externally when doing the final export. Gives me the most control over the quality. Regarding Blender, as said even a very very old one would work, but so does the latest beta. Unity can read .blend files just fine, too, though I stick with exporting to fbx as this allows for having multiple versions of one .blend file and also having a metric crapton of parts in one blend file that can be exported individually but can be modelled together for a perfect fit. I never had trouble migrating to a never version of blender even during a project. Biggest difference was the layout of the fbx exporter changed slightly somewhat in the last two years. I learned emissive animation with the newer unity, so i cant say if it was easier in 4.22. Maybe. I find the new way intuitive, maybe its the re-learing that cought some guys. I changed Unity during a project once and all went well and nothing broke.

It is one of rather many points in the cfg that can be used for scaling. But is is not the best way as there are (at least there where) issues when using a rescalefactor of >1 like changing sizes when resetting a flight back to start and such things. In this context, please note that there are multiple ways of defining meshes used in a ksp model and also multiple ways of defining nodes used to connect KSP models. The old way of defining a mesh that is used by a models from the associated config was: mesh = model.mu scale = 1 rescaleFactor = 1 the mesh has to be located in the same directory as the config is. A better way to do it is: MODEL { model = HGA/Proton/parts/stage1 scale = 0.60976,0.60976,0.60976 } rescaleFactor = 1.0 scale = 1.0 as you can see, there is now a full path associated with the mesh (the mesh's name in the example is stage1.mu) and there are also three independent scaled axis (x, y, z) for this mesh. In this example, I used the rather crude looking scale of 0.60976 as the parts used here are modelled to their original size (4100mm diameter) in a metric environment in blender and scaled to be 2.5 meter parts for stock KSP (2500mm/4100mm=0.60976). This allows for easy modelling (as the original values for every measurement can be used) and also for easy exporting to stock KSP or upscaled mods like realism overhaul where 1:1 models are used instead of the 64%-ish scale of stock KSP. The scale and rescale values of 1 outside the MODEL{} element can be kept at 1 to avoid the problems described above that arise when using anything but "1". Using the MODEL{} declaration also allows the use of more than one mesh in more than one location to be used as one KSP model. For the nodes that connect the models the following notation can be used: node_stack_bottom = 0.0, -0.47924, 0.0, 0.0, -1.0, 0.0, 2 node_stack_top = 0.0, 1.19319, 0.0, 0.0, 1.0, 0.0, 1 or NODE { name = top transform = stage1_nodeTop size = 3 method = FIXED_JOINT } NODE { name = bottom transform = stage1_nodeBottom size = 3 method = FIXED_JOINT } The first one uses coordinates that have to be manually extracted while modelling and also have to be manually scaled when using a bigger or smaller mesh like described above. They are especially awkward to use when radial attachment points are used that don't align perfectly with one of the major axis of x, y or z of the model. Also they are not perfectly reliable and a bit inaccurate due to rounding problems. The latter notation might seem intimidating and overly complicated at first, but once learned it is easy to use and completely eliminated the need for any scaling and manual extraction of coordinates. Simply put an empty transform on the model on exactly the location the node shall sit, rotate in in the desired direction and export the model like you normally do. Then each node is defined as: NODE { name = <name of the node, like "top" or "bottom" or "engine1" transform =<name of the empty transform on the model> size = <size of the node from 0 to 3> method = FIXED_JOINT } See this thread for further reference: You can see, by using the more robust MODEL{} and NODE{} declarations you can get an easily and reliably scaleable mesh with no side issues and perfect precision. I learned them for my first model and used them on everything since then with great success.

Just to clarify, this here is not forgotten. Have a new great (dream-, involves science AND modelling) job that starts soon which required a new home in a new town, which required a new car and thus a metric crapton of real world stuff to fiddle with in the moment. So as the proton and unfortunately Nauka takes a break in real world, I take one from KSP, but not as long as the aforementioned. Promised. There will be proton, there will be TKS/VA

As said you CAN leave them as they are, but performance wise you should merge as many objects as possible! They should only be separate if they have a different material or need to be separate due to animation or being on a different layer in unity.

Silly question: have you tried the other docking port? The one that the highlighted one in the image is attached to? If that is not working: try without colliders, maybe a collider is blocking the node?

Nice one. Consider me being a customer.

Dang it!: Expect to see this version in a KSP near you real soon.

Can it be that in the original version, every other panel was flipped before adding the child constraint (and thus flipping its axis), so that copying the rotation resulted that the flipped ones rotated the other way around? My Solution would be using the transformation constraint or a copy rotation instead of the child of constraint and making each panel the child of the other one manually or using the transformation constraint or copy rotation together with the child of constraint (but enabling all three location axis copying the rotation in the child of constraint) here is a small demonstration set up this way: https://www.dropbox.com/s/ke77jxljx587d33/test.blend?dl=0

Yeah, I have uploaded a fix to GitHub in January. Should push it to the main release when the textures are done. For the last weeks, this puppy kept (and keeps^^) me busy: I'm insane enough to (at least roughly) try to learn to understand what each button does. xD