Ven

You can't find it because I never defined them, the new engines refer to certain Stock engines for data, then change them slightly to make a new part. Squad probably added a spare transform for the visual effects that doesn't exist in the my models. That transform would need to be added or the parts need to have their Effects node specified to use the thrustTransform instead. As for the Shiba, I couldn't get the smoke to work inside the EFFECT node, so I left the sleeping dog lie.

RadialLFOlong is a radial mounted LFO tank akin to the stock 'Stratus-V Cylindrified Monopropellant Tank.' The VenLV909b, is actually the LV-900. I have no idea as to why the docking ports would be so inconsistent. If they were configured incorrectly on my end, then they would never dock, or would dock in the wrong place/direction. Even if the game changed its way of handling docking ports over the past year, I keep going back to the reasoning above. *shrugs.* I don't believe pointing you towards manually downloading the github repo would help, as the docking port has remained unchanged. Check to see if others have the same issue in the stock game? Validate your game's install? Reinstall the game? Do you have any other mods? The arrows are just cosmetic... They mean nothing. XD

Well yeah silly. I need to see them first though.

To be blunt, it's also impolite to accuse someone of wrongdoing without evidence. Anyways, my permission is irrelevant, the license I picked allows Toric5 to do as he wishes as long as he gives attribution. And yes, he did contact me about this and I told him the same thing. Otherwise, I'm not really sure why he didn't just fork and then submit a pull request on GitHub for some changes, I'm still watching it and will merge the pull requests that make sense. Be aware that I've just pushed my updates to the repository, a whole lot of background config cleanup and added a few tidbits that were previously unused.

VSR replaces most of the assets used by WindowShine, making the majority of the mod redundant/ non-functional. The Parts that remain unchanged by VSR are the only bits of WS that function correctly.

If people believe that those business practices effect the game, then they have every reason to post their opinions as a review, regardless on how overblown their reactions really are.

Mainly this was done to let an ejected escape pod yaw when the escape tower is fired, otherwise the offset was added to simulate the real thing.

Pretty much. Though, there's quite a bit more stuff in there than just the models and textures currently seen (like the wheels/ landing legs, their finished. An unfinished LVN Turboprop and V2 engine) Plus it could be a learning tool for new modders I suppose, even with the broken Unity files. Sadly, during the unity 5 editor conversion, half of the mod vanished, kinda ending development. It's hard to believe that anyone could be slower... *shivers* Thanks for taking the time to do that! I've added the links to the OP.

Anything works, I just need a link to them XD

Dumping the source files, if any of you can re-host the files, and post a new link here that would be fantastic. Same licensing rules as the base mod (https://creativecommons.org/licenses/by/4.0/) : https://www.dropbox.com/s/2hst7myddq34kuk/VSR_Models.zip?dl=0 https://www.dropbox.com/s/t9lw5dm33x7i6g5/VSR_Textures.zip?dl=0 What remains of the unity files will be uploaded when I have more space to upload them. It took two days to upload that second file.

I think you're giving me too much credit... But whatever, I'll just say that it's the case. I've accepted your pull requests and made a proper release and shiz.

Go to Data and then check Auto-Smooth, that'll fix the issue.

Regardless of version, the normal map artifacts (or "blocky lighting") are likely the result of the poor texture compression of DXT5 DDS files. The only way to fix this it is to move to a higher DDS format like DXT7 or to a different format entirely.

Sad to say that changing the Tusb value had little to no result. Changing the suspension distance, however did stop the gear from exploding for a short time, it eventually shook itself apart though.

Hmm, after attaching the sphere to the wheelTransform, The sphere is absent until the final part of animation (the time it pops in is related to the TsubSys Value). After changing the Tgt's layer name to default the results are the same. And fiddling with the Tsub Value (0.7 and 1.5) didn't stop the overstressing, it just delayed it. Could this be caused by an animation issue? In the past I had to set up separate transforms for animations because the game wouldn't touch/move said animated objects. Though, the new stock gear doesn't seem to abide by that old rule... *The headaches intensify*

Unfortunately it still explodes after removing the clipObject. When the landing gear explodes, the game says that it was overstressed (or more specifically: [Log]: [F: 7061]: [00:00:01]: LT-2 Landing Strut overstressed and was destroyed.) The LT-1 config? I'm modifying the LT-2 config with this: @PART[landingLeg1-2] { !mesh = DELETE !MODEL {} MODEL { model = VenStockRevamp/Squad/Parts/LandingLegs/LT-2 scale = 1.25,1.25,1.25 rotation = 0.0,90.0,0.0 } %rescaleFactor = 1 @node_attach = 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 @MODULE[ModuleWheelBogey] { bogeyAxis = 0, 1, 0 bogeyUpAxis = 0.0, -1.0, 0.0 } @MODULE[ModuleWheelDeployment] { @TsubSys = 1 } } Otherwise it's the stock LT-2 config. I believe this is a model setup problem, as my LT-1 works perfectly fine and uses the same config setup. Unfortunatly, I did the LT-1 as a test run more than two months ago, so I don't remember what I did to make it work. :/

I think that everything matches, I modeled and named each part after it's stock counterpart, minus caps on items like pistons and the collider names. The part seems to reach the ground (same stock distance and model size, so I don't think that's the issue). I've added the cfg to the OP.

While updating my landing legs, I've run into some problem that causes the legs to shake and then explode when touching the ground. Aside from that the landing gear appears to be functional. Any Ideas on what might be causing this?

No problem!

Inside one of the SDHI Service module folders there's a config that adds the umbilical plug to the command pod. you need to open the config file and delete something like this: MODEL{ model = squad/parts/command/Mk1-2Pod/model } Or at least that's what I think it said. its been several months since i looked through SDHI. It should be the first MODEL{} node provided in the config.

SDHI Service module System is adding the old command pod, you need to remove the MODEL{} node that adds the old mk 1-2 manually.

You may want to double check the layer and tag names (Airlock and Part Triggers ( verbatim )), if these are misspelled, the part will refuse to load without explanation.

Wipe the VSR folder entirely and reinstall, you probably put a new version of VSR inside an older version at some point.

Using the Unity assets explorer (v1.5), I found the monolith's texture (or more correctly, it's a normal map (the monolith seems to lack a dedicated texture otherwise)) that is inside sharedassets0, called monolith00.tex. perhaps try deleting the logo portion of the normal map and then scaling the 'clear' portions to cover the image (if you have the tools to make and convert the normal maps then do what you want). Then use the asset explorer to import the modified map back into the sharedassets bundle.

You could try rotating the entire model by 90* with a MODEL {} node. That'll turn the transform that the fairing is fixed to at least. Example: +PART [modelnamehere] { !Mesh = del !MODEL{} MODEL{ model = model path goes here rotation = 0.0, 90.0, 0.0 //X,Y,Z rotation }