[1.2.2] Stock Part Revamp, Update 1.9.6. Released Source Files!

[Spartwo]

Seems it's not a Revamp related issue.

[Spartwo]

Conflict with a solar panel config from Kopernicus, a section from the Renaissance compilation, issue non existent in 1.3

 

Edit: Just remove the solar config from it and it works perfectly fine.

Edited October 13, 2017 by Spartwo

[Tyko]

Revamp is working fine in 1.3.1 and I'm not seeing any issues with solar panels.

[dtoxic]

51 minutes ago, Tyko said:

Revamp is working fine in 1.3.1 and I'm not seeing any issues with solar panels.

can confirm it works ok, but also there is an old bug with engines if you attach it with the first node (it add's an extra part esthetic only) that part disappears  if you do a scene change and then come back to the orbiting vessel

[Tyko]

12 minutes ago, dtoxic said:

can confirm it works ok, but also there is an old bug with engines if you attach it with the first node (it add's an extra part esthetic only) that part disappears  if you do a scene change and then come back to the orbiting vessel

agreed...I didn't mention that because it's been that way for many release cycles...It would have been more clear to say "it works just as well as it did with 1.3"  

By the way, someone earlier in this thread had a fix for that...check around June 30th

Edited October 13, 2017 by Tyko

[dtoxic]

40 minutes ago, Tyko said:

agreed...I didn't mention that because it's been that way for many release cycles...It would have been more clear to say "it works just as well as it did with 1.3"  

By the way, someone earlier in this thread had a fix for that...check around June 30th

yeah, also just noticed that the small inflatable hubs wont inflate? are you too experiencing this?

[Tyko]

47 minutes ago, dtoxic said:

yeah, also just noticed that the small inflatable hubs wont inflate? are you too experiencing this?

I'll check tonight...what's the name of the part?

[dtoxic]

IKU-02,IKU-01,IKU-03  (Kerbal Safety Bubble), i remember it was also a problem back in ksp 1.2.2 (dont know witch version was Ven's back then) something to do with animation or something, i would remember, but i see a lot of files got rearranged since then directory structure etc, maybe that's causing a problem?

I tried an old copy from my 1.2.2 and it works, i just cant figure it out why on this new one it doesn't.

Edited October 13, 2017 by dtoxic

[robson1000]

10 hours ago, dtoxic said:

IKU-02,IKU-01,IKU-03  (Kerbal Safety Bubble), i remember it was also a problem back in ksp 1.2.2 (dont know witch version was Ven's back then) something to do with animation or something, i would remember, but i see a lot of files got rearranged since then directory structure etc, maybe that's causing a problem?

I tried an old copy from my 1.2.2 and it works, i just cant figure it out why on this new one it doesn't.

Delete patch "VenStockRevamp\Patches\USIPatches.cfg".

[dtoxic]

5 hours ago, robson1000 said:

Delete patch "VenStockRevamp\Patches\USIPatches.cfg".

Thank you kind sir

[dtoxic]

19 hours ago, Tyko said:

agreed...I didn't mention that because it's been that way for many release cycles...It would have been more clear to say "it works just as well as it did with 1.3"  

By the way, someone earlier in this thread had a fix for that...check around June 30th

hey btw, is there a possibility to disable those esthetic parts (first node) with MM patch?

[coolguy8445]

Not sure whether this has been asked before, as I'm not sure what search terms to use, but: 

Is it intentional that the engines' stack nodes don't seem to make sense? Especially on the bottom of, say, an LFO, the node is inside the bell of the engine, which can cause issues like decouplers getting lost inside the bell, or cause some inconsistencies with other mods that cause things to need to be manually dragged into the right positions.

I've noticed similar problems with the decouplers' top nodes, but I can see that those mount points *are* intentional (presumably) to align the part being decoupled with the rail inside the texture? Also, the bells of certain engines, like the Rhino, seem to stick out beyond the end of their shrouds. I'm assuming that the purpose of that is, again, for alignment with decouplers, but it can cause some strangeness.

Personally, I would just as soon not try to be heroic about alignment, and have all engines' bottom nodes and shrouds at the end of the bell, and decouplers' top nodes at the top edge instead of nested inside (especially since one won't *necessarily* have an engine mounted above the stack decoupler). But then again, I'm not the developer. I could make the tweaks well enough myself, but wanted to get some input on the rationale behind this before breaking things. 

 

EDIT: After looking at the config files for VSR, it looks like barely any stack nodes are changed...least of all engine and decoupler nodes. And the shroud endpoints are based on the bottom node, so that makes sense now...

Edited October 15, 2017 by coolguy8445

[Eric S]

I've got one minor issue with Ven's Stock Revamp that isn't just my own weird aesthetics.  The Mk16 and Mk26 parachute are rather odd if you don't install RealChute.  Basically, the Mk16 is too weak and the Mk26 is way too strong.

In a stock game, a Mk16 will land a Mk1 Command Pod at 5.1 to 5.5 m/s.  With just VSR and ModuleManager installed, the same parachute/pod combination lands at a harrowing 9.7-10.5 m/s.  On the other hand, the Mk26, a freaking DROGUE chute that's lighter than the Mk16, will land the same payload at a "I hope you didn't activate this early without adjusting the 2.5Km deployment altitude" 3.5-4.3 m/s.

If you install RealChute, this all sorts itself out, with the Mk16 landing slightly faster than stock at 5.7 m/s and the Mk26 a capsule-destroying 75 m/s (approximately, it was still slowing down when it impacted).

I took a look at the .cfg files and didn't see anything obviously wrong, and I won't have the time to dig into it more thoroughly until I finish my current playthrough, as I've got missions in progress that have adapted to this situation, and fixing it mid mission would be fatal.

 

[Tyko]

On 10/15/2017 at 11:36 AM, Eric S said:

I've got one minor issue with Ven's Stock Revamp that isn't just my own weird aesthetics.  The Mk16 and Mk26 parachute are rather odd if you don't install RealChute.  Basically, the Mk16 is too weak and the Mk26 is way too strong.

In a stock game, a Mk16 will land a Mk1 Command Pod at 5.1 to 5.5 m/s.  With just VSR and ModuleManager installed, the same parachute/pod combination lands at a harrowing 9.7-10.5 m/s.  On the other hand, the Mk26, a freaking DROGUE chute that's lighter than the Mk16, will land the same payload at a "I hope you didn't activate this early without adjusting the 2.5Km deployment altitude" 3.5-4.3 m/s.

If you install RealChute, this all sorts itself out, with the Mk16 landing slightly faster than stock at 5.7 m/s and the Mk26 a capsule-destroying 75 m/s (approximately, it was still slowing down when it impacted).

I took a look at the .cfg files and didn't see anything obviously wrong, and I won't have the time to dig into it more thoroughly until I finish my current playthrough, as I've got missions in progress that have adapted to this situation, and fixing it mid mission would be fatal.

 

I saw this too and my conclusion was that the stats had been reversed for the two chutes. I wrote a quick config to reverse them which I'm happy to post later (not at my computer at the moment)

EDIT: Here's the config I wrote to swap out the drag characteristics:

Spoiler

@PART[parachuteSingle]:AFTER[VenStockRevamp]
{
    !MODULE[ModuleDragModifier]{}
    !MODULE[ModuleDragModifier]{}
    MODULE
    {
        name = ModuleDragModifier
        dragCubeName = SEMIDEPLOYED
        dragModifier = 0.2
    }
    MODULE
    {
        name = ModuleDragModifier
        dragCubeName = DEPLOYED
        dragModifier = 4
    }
    !MODULE[ModuleParachute] {}
    MODULE
    {
        name = ModuleParachute
        semiDeployedAnimation = semiDeploySmall
        fullyDeployedAnimation = fullyDeploySmall
        invertCanopy = true
        autoCutSpeed = 0.5
        capName = cap
        canopyName = canopy
        stowedDrag = 0.22
        semiDeployedDrag = 1
        fullyDeployedDrag = 500
        minAirPressureToOpen = 0.04
        clampMinAirPressure = 0.04
        deployAltitude = 1000
        deploymentSpeed = 0.12
        semiDeploymentSpeed = 0.5
        chuteMaxTemp = 1000
    }
}

@PART[parachuteSingle_drogue]:AFTER[VenStockRevamp]
{
    !MODULE[ModuleDragModifier]{}
    !MODULE[ModuleDragModifier]{}
    MODULE
    {
        name = ModuleDragModifier
        dragCubeName = SEMIDEPLOYED
        dragModifier = 0.2
    }
    MODULE
    {
        name = ModuleDragModifier
        dragCubeName = DEPLOYED
        dragModifier = 1
    }
}

 

Edited October 17, 2017 by Tyko

[Eric S]

On 10/16/2017 at 1:15 PM, Tyko said:

I saw this too and my conclusion was that the stats had been reversed for the two chutes. I wrote a quick config to reverse them which I'm happy to post later (not at my computer at the moment)

EDIT: Here's the config I wrote to swap out the drag characteristics:

  Reveal hidden contents

@PART[parachuteSingle]:AFTER[VenStockRevamp]
{
    !MODULE[ModuleDragModifier]{}
    !MODULE[ModuleDragModifier]{}
    MODULE
    {
        name = ModuleDragModifier
        dragCubeName = SEMIDEPLOYED
        dragModifier = 0.2
    }
    MODULE
    {
        name = ModuleDragModifier
        dragCubeName = DEPLOYED
        dragModifier = 4
    }
    !MODULE[ModuleParachute] {}
    MODULE
    {
        name = ModuleParachute
        semiDeployedAnimation = semiDeploySmall
        fullyDeployedAnimation = fullyDeploySmall
        invertCanopy = true
        autoCutSpeed = 0.5
        capName = cap
        canopyName = canopy
        stowedDrag = 0.22
        semiDeployedDrag = 1
        fullyDeployedDrag = 500
        minAirPressureToOpen = 0.04
        clampMinAirPressure = 0.04
        deployAltitude = 1000
        deploymentSpeed = 0.12
        semiDeploymentSpeed = 0.5
        chuteMaxTemp = 1000
    }
}

@PART[parachuteSingle_drogue]:AFTER[VenStockRevamp]
{
    !MODULE[ModuleDragModifier]{}
    !MODULE[ModuleDragModifier]{}
    MODULE
    {
        name = ModuleDragModifier
        dragCubeName = SEMIDEPLOYED
        dragModifier = 0.2
    }
    MODULE
    {
        name = ModuleDragModifier
        dragCubeName = DEPLOYED
        dragModifier = 1
    }
}

 

That was going to be my solution, but I like yours better (Module Manager was a bit more primitive last time I got into it up to the elbows).  I'll probably use this, fixing the mk16 only until I retire all my craft that are depending on the current broken stats, at which time I'll either apply both, or switch to RealChutes.

 

[sjbuggs]

I love the mod but there are times when the parts don't mesh well with parts from other mods as well as the stock parts.

Is there a sane way to support both the stock and Vens models at the same time?  Or only include a subset of the mod?

[Eric S]

8 hours ago, sjbuggs said:

I love the mod but there are times when the parts don't mesh well with parts from other mods as well as the stock parts.

Is there a sane way to support both the stock and Vens models at the same time?  Or only include a subset of the mod?

Yes.  In fact, the above discussion about the parachute issue I was having lead me to figure out the basics about this, since the MM config above makes the Mk16 parachute as overpowered as the default Mk26 parachute is.

Basically, copy the part directory that you want to have unmodified from the Squad directory into a different directory and then edit the cfg file within that directory to change the name and title parameters.  You have to change the name, otherwise KSP will only keep one of the two parts, and you should change the title parameter so that it's easier to tell which is which in the VAB or when you're mousing over the part in flight.

If you want more details, feel free to ask, I'm just skimping on the details because I'm still waking up and not thinking well yet.

 

[Agustin]

On 13/10/2017 at 4:41 PM, dtoxic said:

can confirm it works ok, but also there is an old bug with engines if you attach it with the first node (it add's an extra part esthetic only) that part disappears  if you do a scene change and then come back to the orbiting vessel

What do you mean by the first node?
I am thinking in installing Revamp, but don't want to break my game if engines go missing... O_O

[dtoxic]

On 10/27/2017 at 2:23 PM, Agustin said:

What do you mean by the first node?
I am thinking in installing Revamp, but don't want to break my game if engines go missing... O_O

don,t worry you wont...after you install VSR drop this also into /Gamedata https://github.com/otaithleigh/VSR-B9PartSwitch-Cfgs/releases

and make sure you have B9 partswitch mod installed

[Beetlecat]

Any SVR users noticing lights showing up on planet surfaces from orbit while using PlanetShine?

Using both, I see lights from my (all-stock) craft shining on the mun below, but disabling PlanetShine or removing VSR stops this effect.

Did/does SVR use an older light method for projecting lights from custom/overridden lighted parts?

[Tyko]

20 hours ago, Beetlecat said:

Any SVR users noticing lights showing up on planet surfaces from orbit while using PlanetShine?

Using both, I see lights from my (all-stock) craft shining on the mun below, but disabling PlanetShine or removing VSR stops this effect.

Did/does SVR use an older light method for projecting lights from custom/overridden lighted parts?

I've seen this with VSR docking port lights. Never made the connection with PlanetShine though...I've just gotten in the habit of disabling the docking port lights. I'll try removing PS and see what happens

[Poodmund]

The solution is discussed here: 

However, I am not sure that it can be resolved unless the light parts are re-exported through Unity.

[Beetlecat]

1 hour ago, Poodmund said:

The solution is discussed here: 

However, I am not sure that it can be resolved unless the light parts are re-exported through Unity.

Thank you!

I remembered seeing this long after I stopped having the problem, and my recent search terms didn't get me close enough. Appreciate it!

So, not something that can be MM patched? Drat.

Edited November 1, 2017 by Beetlecat

[Tyko]

The Bollard engine is causing torque on this ship as reported by Kerbal Engineer. Attach the engine to a fuel tank and you get torque that's not present when other engines are attached it should be 0.0 since everything is inline. There's a pic below showing the Bollard connected and the KER readout in the upper right shows a torque of 0.81.

Any idea why this is happening? Thanks!

[Electrocutor]

So... I was going to work on making a patch .cfg to allow Vens stuff to use the PBR shaders from ShadowMage, but I'm obviously missing something; every single part that should have a new model is missing from the game and the log is filled with "Model was not compiled correctly" errors. I apologize in advance if this is a stupid question, but 'How do I make this work?' I checked a few pages back, but do not see anyone else having an issue?

 

[Update]
n/m I figured it out.

Edited November 13, 2017 by Electrocutor