steedcrugeon

I have reordered you quote to better answer this. A1) An 'Emissive' in this context is a material assigned to a mesh, the material comprises a texture and a shader which is built in Unity. The shader used comes form the KSP PartTools asset bundle and the it is "KSP Emissive/Diffuse" A2) It is defined in Unity, there are multiple ways to define which colour the emissive is when it comes out of Unity. The Alpha of a texture can change some of the appearance of the emissive but you don't have to have an Alpha mapped, it will just give a uniform colour and brightness across the emissive element. A3) How IndicatorLights works is by overriding the original _EmissiveColor with that determined in the IndicatorLights config. The example below will help explain. Changing the colour/alpha on the original texture will NOT make it work with indicator lights. The mesh material you are targeting has to be KSP Emissive/Diffuse to begin with, otherwise the mesh will not have the _EmissiveColor property in its shader and IndicatorLights cannot target it. A4) To my knowledge its not possible to change the shader of the material after it has been exported as a .mu [clarification needed from someone more, as it may be possible?] as such the attribute in the shader must be defined in Unity before it's 'wrtitten'. In response to this question let me run you through how these 'running lights' on the MiniDock work, they are driven by IndicatorLights: The above space dock uses multiple objects, which are animated, some with colliders, some without. none of these things interfere with how IndicatorLights work. When IndicatorLights is not present then the blue strobing indicators appear as simple dark grey lugs, that are attached (parented) to the 'arms' that run along the bottom but are separate objects. In order for them to work as they do they are separate objects from each other and more importantly separate materials (this bit is critical as they share a .mu and KSP cannot determine between the same material on the same .mu, if you use multiple models in the part config this Is not an issue). However because (unlike in blender) Unity can have multiple instance of the same component names, whilst they are separate objects they have similar mesh names. This is the Patch that's drives the effect seen above: @PART[miniDock]:NEEDS[IndicatorLights] { MODULE { name = ModuleControllableEmissive target = ledLower emissiveName = dockingLEDs } MODULE { name = ModuleEmissiveArrayController emissiveName = dockingLEDs toggleID = ModuleToggleLED activeColor = blink(#08E8DE, 200, $Off, 800, divide(index, 5)) inactiveColor = $Off } MODULE { name = ModuleControllableEmissive target = ledLowerB emissiveName = dockingLEDs2 } MODULE { name = ModuleEmissiveArrayController emissiveName = dockingLEDs2 toggleID = ModuleToggleLED activeColor = blink(#08E8DE, 200, $Off, 800, subtract(0.8, divide(index, 5))) inactiveColor = $Off } MODULE { name = ModuleToggleLED status = false } } From the above the arms on one side have a small emissive lug called "dockingLEDs" and on the other side they are called "dockingLEDs2". Now we couldn't have them all called "dockingLEDS" because the array controller fires each sequentially and the effect would leap frog from side to side. Interestingly enough, and only found through trial and error, if the code was the same for both sides they do not run together. Instead one side ran a slight delay (one LED in fact) behind the other so when one running sequence was at the end, the other was at the start. Also worth noting is that when using the ModuleEmissiveArrayController, IndicatorLights will determine the direction in relation to the origin of the part, which means that the array for one side needed to be told to be negative and run in the other direction, to appear as though its mirroring its counterpart array on the opposite side. The 0.8 is used to offset the start of the sequence for one side. Now, if you are still with me at this point good going, I will try to expand on the answer to 3); you can see from the code that we are targeting the meshes named "dockingLEDS" and "dockingLEDS2". they both use ModuleToggleLED so despite being two separate controllable emissives the toggle in the part controls them as one. In the ModuleEmissiveArrayController we actually define the colour we want to change on the targeted mesh. This is to say that for that mesh, we are changing the value of _EmissiveColor of the shader in that mesh's material. It is for this reason that each mesh must have its own material (if they are all on the dame .mu) because if all of the emissive shared a material then when one mesh was toggled, all the meshes that shard that material would change colour too. So for the running lights in the above config, if all the "dockingLEDs" used the same material, despite being separate objects in unity, when the LED was toggle on then all the lugs would appear to be constantly on, their would be no sequence. To put this into terms you could use for the custom runway. If it were me and I was building this in Unity, I would added the 'LED's I wanted to use for my running lights over the original model. I would have all the objects on one side with the same name, than all the objects on the other side with a similar name. Each of the 'LED's gets its own material, a duplicate of the material is fine but it must have its own name (for instance runwayEmisMat1, runwayEmisMat2, etc.). If you were trying to implement this through a patch alone, you could use the BL-001 model (.mu) to give you your 'LED's, then you wouldn't need to worry about Unity at all.

I can see you have made your own fork of the repository. You now need to make a 'Pull Request' that way I can merge the branches

Hmm, not really sure how to resolve this one. i know its a big ask but can you put a fresh install of KSP1.3 on your machine (in a separate directory) and just run it with only the REKT mod and see if it repeats this behavior?

drag and drop the localization file you have written into here: PicoPort Localisation folder on Gtihub And create a 'pull request' is the best way.

Does this behaviour happen when you manually control the vessel?

Ah yes, that's left over from a much earlier version of the OTAV. The correct RetractableLiftingSurface should be found in the GameData folder, not in the SHED folder anymore. Okay, this will require further testing. If safe to do so (as in so long as it doesn't affect any of your saves) can you go into the 'RETIRED' folder within the OTAV subfolder and remove the 'OTAVcore.cfg'. Also check to see if there is an 'OTAVcore.cfg' lurking anywhere else in the OTAV folders. The only one you want for now is the 'OTAVcore2.cfg'. It uses a slightly different CoP/CoL to the newer 'rektOTAVcore2' and I just want to eliminate that as a possible source of confusion.

Hmm, again I saw this happen in testing but though it had been resolved. I wonder.. This may be a bit extreme but can you clear out your MM cache for me, make sure that there is nothing left of RetractableLiftingSurface 1.1 in your KSP directory and then load the game again?

Minor update v0.4.5.1 - Fixes to KSPResucePod Validator (thanks @DStaal) - Updated bundled version of RetractableLiftingSurface

Ah I think I may have sussed what it is. which version of RetractableLiftingSurface do you have installed? I can see on the GitHub release its still got 1.1. bundles but it should be 1.4 (current version). That looks like I made that mistake when putting the binaries together for release. Can you check to see if installing the 1.4v of RetractableLiftingSurface (find it here) resolves the issue? Yes the Pitch stabiliser is very powerful, as it is large and needs to be affective in thinner atmosphere/higher altitude. It shouldn't cause blackouts, just get close to the limit.

Yesterday saw my first attempted at a manned Duna Landing. I used predominantly Tantares stuff with a little help from Stock/Lack Parts. I present here are the fruits of DunaMunar2 (full story in Spoiler)

Hmm, I have observed something similar this behaviour in testing but I though it had made it go away. It is 1.3 you are using correct and this is observed with the two-part winglet arrangement? Can you double check for me that pitch IS disengaged for the winglets (as set by default in the config).

Have you considered exploiting the 'allowDeployLimit' in ModuleGenericAnimate, like that used in the Mk3 cargo bay ramp animation? And have it so the full animation for horizontal but restrict it by default, something like this perhaps: MODULE { name = ModuleAnimateGeneric animationName = Eridani_Antenna_1_Deploy startEventGUIName = Extend endEventGUIName = Retract actionGUIName = Toggle Antenna allowDeployLimit = true deployPercent = 80 } Or something like that? and then just have a little greebly animation for the 'ModuleDeployableAntenna' (like maybe a loop animations that spins the Rx part [yellow] inside the antenna dish (still have the original pivot as the pivot point for breakage purposes)?

Your statement is accurate. FreeIVA will work much better with support from the original mod author, much easier to take into account at ground level when building the IVA for a model/part The problem you have here is that IVA's are generally quite time consuming to being with. modelling an exterior part can vary from quick and simple to drawn out and complex, this I soften determined by the level of detail and any animated parts involved. IVA's tend to start at more complicated than the part they are attached to and then get more so as the level of detail goes up, difficulties can arise if you want to end up with an IVA smaller than the part its going in when the part is small to begin with. Then to add to that, to incorporate FreeIVA compatibility you will need additional physics colliders on your Internal Model (and on the correct layer: 16) as well as colliders for any Props that you may be choosing to use. None of these are beyond the wit of an individual who is already making a model but its an additional consideration that has be taken into account and planned for (that and making sure your bulkhead colliders have a hole large enough to pass a Kerbal though). Note, colliders need to be thick enough to not let kerbals pass through but also no so thick as to upset the layout/physics of adjacent IVA's

This is most impressive work. I had a great deal of difficulty trying to get the part shown below to export from Blender to Unity but I figured out the multiple things I did wrong. This was supposed to be at it's 'retracted state' but because of how various parts were parented it ended up looking like the above (not correct). I used no constraints on this model, everything was done through 'rotation' , 'XYZ euler' location and 'Scale' animation. It eventually became the parts shown in this post: Unfortunately I don't have the complete back and forth I had with fendrin as this part was developed as it's pretty much the cornerstone of my Blender animating knowledge learning. As a general rule of them whilst Blender is more than happy to scale things to the nth decimal place Unity does not like it, so for started if you have any objects that scale down past 1, redo that part of the animation so that is scales down to 1 , resize the object mesh etc. (that's how the stretching of the reflective hexes works in the animation below, which does use contraints). Also for blender to unity animating stuff I find that 'setting' as few fixed points as possible is best. For if you move a part along it's local x-axis only then only 'set' the x-axis positions at the required time frame. You aren't moving it in the z or y axis so don't bother setting them it can cause weird things to happen in game. A quick question; your deployment animation is all in one animation yes? I would be happy to answer any question I can, I know only the stuff I have learned though as a rank amateur in the 3d modelling/animating world.

Is this question driven by Life Support Mods at all? There are no Cupolas in Tantares at present but that isn't to say you couldn't right yourself a little MM patch that implements the Cupola's Habitation Modifier (I'm guessing its that sort of thing your after?).

That... that is impressive, care to share a screen shot?

Sorry to hear about you having issues after having installed REKT. Have scoured through your logs and i can't see any obvious clues or pointers. the first none compiled part is a retired part anyway so it's absence will mean nothing to newer users such as yourself, its deprecated and will be removed from the next release.The same is true of the OTAVwinglets and the OTAVcore. I have no experience of Tweakscale and presently its support is not planned, so if that's causing issues i cannot help, I suspect though it is why the OTAVcore2 is not compiling, those undefined variables are not stock. I haven't seen any other issue/reports of PicoPort problems (that belongs in another thread), I am unable to diagnose whatever the issue is from there and i can't replicate it (i'd need you machine, your install etc.) the sheer volume of Mods you are running I cannot cater for unfortunately. What i will say is that something has changed in the code between 1.2.2 and 1.3 which has upset things, predominantly the bigger .mu files but i wonder if it may be a factor?

Looks like its about to do some eve/duna flybys...

Well this is a new one on me and a peculiar one too. Do either of the two smaller antennas exhibit this issue? I'll need some time to investigate. Interim update: I suspect i have found a partial cause to the problem. the 2.0.1 and 2.0 release versions have models built using an outdated set of PartTools (my fault, I'm very sorry to all affected by this). I have re-exported the JX2 model with the latest set of PartTools. The model load time is exceptionally long (it appears to hang and go not responding but it is actually still loading) the example below took about 3 minutes to load on the Pad. I have conducted some rudimentary testing. Now i'm not sure why this is a problem for 1.3 when it worked in 1.2 but I suspect that due to the size of the original model for the JX2 (the .mu is a bit of a fatty). I didn't suspect that there would be such a disparity in size but both the JU1 and JW1 (with similar deployment mechanisms) are less than 1mb in size whereas the JX2 is almost 12mb. Recovery Plan: 1) I will be sending @Snark the updated .mu files as a 'quick fix'. With this he can push out an updated version. 2) All players with vessels using more than one JX2 antenna should try, where possible, to not fly/load them. if unavoidable wait for the 2.0.2 version of JX2 and prepare for a long load time, ignore the 'Not responding' that is to be expected. 3) The JX2 model will have its deployment model/animation built from scratch (now that I have more experience with Blender).

Version 0.4.5 is now available. This latest release see the OTAV hatch obstruction fixed (from the last release 0.4.4) and a few more bits of folder tidying to cut down on duplicate textures. Note the original OTAV air brake has now bee n removed, the previous OTAVairFins and Winglets (pair) have been deprecated. they will be removed in the not too distant future. This brings us to the biggest piece of rework (courtesy of the pointers i got from @Pak, @Beale and @riocrokite). The OTAV has been revamped and now features integral landing gear courtesy of @Shadowmage mighty KSPWheel mod. Also the aero-package for the OTAV has been overhauled to enable proper glide landings (that's WITHOUT the use of the reaction wheels). This last bit is something i had wanted to do for a while but didn't know how, so this vessel can realise its potential!

Background things have been going on, development of this has NOT been abandoned but I have spent my time recently focusing on bringing other mods up to 1.3 (the localization stuff was a bit more work than originally anticipated but these things happen). Whilst I have no new pictures to share as of yet I have fleshed out the family of parts and the progression through the tech tree both Stock and CTT. Concept designs have been completed for about 80% of the parts with detailed sketches for about 50% so it's coming along. Balancing in terms of cost etc. is still to be done across all parts, hopefully this will be resolved or at least started in Beta. Plugin stuff is back up in the air again, as workload for all parties concerned is unpredictable. It is probable that initial release (certainly the Beta) will use USI tools for functionality, that is unless I can learn to write plugins oh and code too .

I suspect at the very least the .dll will need a recompile, but you'd need access to the source files form that. Nice to see that the 1.25m survives, the centrifuge animation is most likely driven by the .dll and it drove the IVA round as well.

I think I have come across a bug with the control surface, I have raised an issue on the Github for it. If you need any more details I'll try to get it for you. Still damned impressed with this mod, the OTAV would not be what it is without it!

@ArmoredReaper any update on the development of this?

Try to be economical with the available space. I see you have unwrapped the entire model. where you are doing that with cylinders you can often get away with 'mirroring' the image.