[1.12.5] Restock - Revamping KSP's art (August 28)

[Streetwind]

5 minutes ago, madindehead said:

I think I understand this correctly but I just want to clarify. If I have the whitelist file and make the appropriate patch modifications, it's possible for me to have both the original part and your ReStock version available to me? 

Yes, although for that, you wouldn't modify the MM patch that ReStock applies. You would instead write another patch of your own that runs :FIRST, where you use a +PART[ ] node to clone the part before it gets changed by ReStock. The cloned part will remain as it is, while the original part later gets replaced, and you end up with both versions available to you.

[madindehead]

1 hour ago, Streetwind said:

Yes, although for that, you wouldn't modify the MM patch that ReStock applies. You would instead write another patch of your own that runs :FIRST, where you use a +PART[ ] node to clone the part before it gets changed by ReStock. The cloned part will remain as it is, while the original part later gets replaced, and you end up with both versions available to you.

Ah ok! That makes...some sense to me! I will investigate how to write that patch. It's not urgent but I'll get to it. Thanks for your help on that! 

On second thoughts: Taking a look at those patches, they seem complex! Some initial guidance would be great on how to start but no rush. 

Edited June 30, 2019 by madindehead
Added line about initial patch help.

[Superfluous J]

I've not been able to find this anywhere. The wiki shows how to disable part of ReStock so you can enable your mod's parts instead, but how would I go about it for stock parts?

In particular, I prefer the stock science parts over those in ReStock. I can (and currently do) manually disable them by renaming the ReStock science part files (and whitelisting the stock model files) but how would I do it in a ModuleManager config, so when ReStock 0.8 drops I don't have to do any extra work? I like not doing extra work.

The part that's tripping me up is, Restock drops the stock part so I'd have to reload that stock part, which also could change between versions. As I've no control (in my separate modulemanager file) over either, how would I go about reloading the stock part that was dropped, or keeping ReStock from not dropping it in the first place?

Edited June 30, 2019 by 5thHorseman

[cineboxandrew]

15 hours ago, madindehead said:

Ah ok! That makes...some sense to me! I will investigate how to write that patch. It's not urgent but I'll get to it. Thanks for your help on that! 

On second thoughts: Taking a look at those patches, they seem complex! Some initial guidance would be great on how to start but no rush. 

make sure you give the cloned part a new name, multiple parts with the same internal name tend to cause weird things to happen

[4x4cheesecake]

2 hours ago, 5thHorseman said:

I've not been able to find this anywhere. The wiki shows how to disable part of ReStock so you can enable your mod's parts instead, but how would I go about it for stock parts?

In particular, I prefer the stock science parts over those in ReStock. I can (and currently do) manually disable them by renaming the ReStock science part files (and whitelisting the stock model files) but how would I do it in a ModuleManager config, so when ReStock 0.8 drops I don't have to do any extra work? I like not doing extra work.

The part that's tripping me up is, Restock drops the stock part so I'd have to reload that stock part, which also could change between versions. As I've no control (in my separate modulemanager file) over either, how would I go about reloading the stock part that was dropped, or keeping ReStock from not dropping it in the first place?

That's a question for the restock thread, isn't it?

Well, one way to solve this would be:

1) Whitelist the whole science folder:

Squad/Parts/Science/

2) Rename every science part before ReStock can touch it:

@PART[sensorThermometer]:FIRST
{
	@name = sensorThermometer_stock
}

@PART[sensorBarometer]:FIRST
{
	@name = sensorBarometer_stock
}

@PART[sensorAccelerometer]:FIRST
{
	@name = sensorAccelerometer_stock
}

@PART[sensorGravimeter]:FIRST
{
	@name = sensorGravimeter_stock
}

@PART[GooExperiment]:FIRST
{
	@name = GooExperiment_stock
}

@PART[science_module]:FIRST
{
	@name = science_module_stock
}

@PART[sensorAtmosphere]:FIRST
{
	@name = sensorAtmosphere_stock
}

@PART[ScienceBox]:FIRST
{
	@name = ScienceBox_stock
}

3) (Optional) Rename them again to the stock names after the ReStock patches are applied:

@PART[sensorThermometer_stock]:AFTER[ReStock]
{
	@name = sensorThermometer
}

@PART[sensorBarometer_stock]:AFTER[ReStock]
{
	@name = sensorBarometer
}

@PART[sensorAccelerometer_stock]:AFTER[ReStock]
{
	@name = sensorAccelerometer
}

@PART[sensorGravimeter_stock]:AFTER[ReStock]
{
	@name = sensorGravimeter
}

@PART[GooExperiment_stock]:AFTER[ReStock]
{
	@name = GooExperiment
}

@PART[science_module_stock]:AFTER[ReStock]
{
	@name = science_module
}

@PART[sensorAtmosphere_stock]:AFTER[ReStock]
{
	@name = sensorAtmosphere
}

@PART[ScienceBox_stock]:AFTER[ReStock]
{
	@name = ScienceBox
}

Of course, if SQUAD changes the internal part names at some point, you have to adjust this patch as well

Not quite sure if there is a more elegant solution for this but this one works for sure^^

[Superfluous J]

1 minute ago, 4x4cheesecake said:

That's a question for the restock thread, isn't it?

Yes and I got a mod to move it, but you saw it before they did

I considered doing it that way, but figured it was about the same amount of work as renaming the Restock files each update.

[4x4cheesecake]

16 minutes ago, 5thHorseman said:

I considered doing it that way, but figured it was about the same amount of work as renaming the Restock files each update.

Well, now I've done the work for you

I don't see any reason why this should break during any update of ReStock. By renaming the parts right at the beginning, the ReStock patch will not find any parts to modify and nothing will happen. I cannot think of any reason for the ReStock team to change their patch to use a different filter than the part name, so this should work in future versions of ReStock as well.

[Superfluous J]

4 minutes ago, 4x4cheesecake said:

Well, now I've done the work for you

I don't see any reason why this should break during any update of ReStock. By renaming the parts right at the beginning, the ReStock patch will not find any parts to modify and nothing will happen. I cannot think of any reason for the ReStock team to change their patch to use a different filter than the part name, so this should work in future versions of ReStock as well.

Oh! I misread what your configs were doing. Quite clever. I take back what I said and will abscond with these configs posthaste. Thank you.

[madindehead]

5 hours ago, 4x4cheesecake said:

That's a question for the restock thread, isn't it?

Well, one way to solve this would be:

1) Whitelist the whole science folder:

Squad/Parts/Science/

2) Rename every science part before ReStock can touch it:

@PART[sensorThermometer]:FIRST
{
	@name = sensorThermometer_stock
}

@PART[sensorBarometer]:FIRST
{
	@name = sensorBarometer_stock
}

@PART[sensorAccelerometer]:FIRST
{
	@name = sensorAccelerometer_stock
}

@PART[sensorGravimeter]:FIRST
{
	@name = sensorGravimeter_stock
}

@PART[GooExperiment]:FIRST
{
	@name = GooExperiment_stock
}

@PART[science_module]:FIRST
{
	@name = science_module_stock
}

@PART[sensorAtmosphere]:FIRST
{
	@name = sensorAtmosphere_stock
}

@PART[ScienceBox]:FIRST
{
	@name = ScienceBox_stock
}

3) (Optional) Rename them again to the stock names after the ReStock patches are applied:

@PART[sensorThermometer_stock]:AFTER[ReStock]
{
	@name = sensorThermometer
}

@PART[sensorBarometer_stock]:AFTER[ReStock]
{
	@name = sensorBarometer
}

@PART[sensorAccelerometer_stock]:AFTER[ReStock]
{
	@name = sensorAccelerometer
}

@PART[sensorGravimeter_stock]:AFTER[ReStock]
{
	@name = sensorGravimeter
}

@PART[GooExperiment_stock]:AFTER[ReStock]
{
	@name = GooExperiment
}

@PART[science_module_stock]:AFTER[ReStock]
{
	@name = science_module
}

@PART[sensorAtmosphere_stock]:AFTER[ReStock]
{
	@name = sensorAtmosphere
}

@PART[ScienceBox_stock]:AFTER[ReStock]
{
	@name = ScienceBox
}

Of course, if SQUAD changes the internal part names at some point, you have to adjust this patch as well

Not quite sure if there is a more elegant solution for this but this one works for sure^^

Sorry for quoting such a long post. Normally I would spoiler tag parts of it or snip it but I'm still learning how to use the forums.

I think this is what I was looking for above so a big thank you for your help 

[4x4cheesecake]

5 hours ago, madindehead said:

I think this is what I was looking for above so a big thank you for your help 

Well, almost. You want both variants, so you have to run just the first patch and change the "@" to "+", for example:

+PART[sensorThermometer]:FIRST
{
	@name = sensorThermometer_stock
}

 

[madindehead]

20 hours ago, 4x4cheesecake said:

Well, almost. You want both variants, so you have to run just the first patch and change the "@" to "+", for example:

+PART[sensorThermometer]:FIRST
{
	@name = sensorThermometer_stock
}

 

Ok! I will start looking at that. Would that be a separate patch file with a different name? Or is it possible to include at the top of the existing patch file? Apologies again for all these questions. I am very grateful for your patience and responses 

[Superfluous J]

52 minutes ago, madindehead said:

Ok! I will start looking at that. Would that be a separate patch file with a different name? Or is it possible to include at the top of the existing patch file? Apologies again for all these questions. I am very grateful for your patience and responses 

You can do them all in one patch or in separate patches, whichever is easier for you to maintain/understand.

In theory you could take every mm config you use and put them all in one huge file instead of separate. I don't suggest it though!

[Jognt]

7 hours ago, madindehead said:

Ok! I will start looking at that. Would that be a separate patch file with a different name? Or is it possible to include at the top of the existing patch file? Apologies again for all these questions. I am very grateful for your patience and responses 

If I were you I'd make it a seperate patch file per tweak and just save it in a folder of your own in GameData. That way you can just copy/backup that one folder and have all your personal preference tweaks in one place for easy portability.
For example I have about two dozen patches in a personal folder, each patch containing only a few lines so I can easily share/disable/adjust specific patches.

ModuleManager does not care where specifically in GameData a patch is saved. As long as it ends with .cfg it'll find it, read it, and process it.

Edited July 2, 2019 by Jognt

[madindehead]

13 hours ago, Jognt said:

If I were you I'd make it a seperate patch file per tweak and just save it in a folder of your own in GameData. That way you can just copy/backup that one folder and have all your personal preference tweaks in one place for easy portability.
For example I have about two dozen patches in a personal folder, each patch containing only a few lines so I can easily share/disable/adjust specific patches.

ModuleManager does not care where specifically in GameData a patch is saved. As long as it ends with .cfg it'll find it, read it, and process it.

That's a great idea, thanks  I was going to put them in the ReStock folder with different names but that seems safer and more sensible. Thanks for all your help here everyone, this is such a great community

[Nertea]

On 6/30/2019 at 1:38 AM, madindehead said:

I think I understand this correctly but I just want to clarify. If I have the whitelist file and make the appropriate patch modifications, it's possible for me to have both the original part and your ReStock version available to me? 

Absolutely loving the mod by the way! The visuals are amazing. Just not a fan of some of the engine models  or rather, I would like the option to have both (aesthetics matter to me more than they probably should!) I've just started playing KSP properly after owning it for years. 

It looks like people have already answered your actual question, but I'm always down for understanding which engines you don't like and the why of it so I can improve things in the future.  

[Jognt]

24 minutes ago, Nertea said:

It looks like people have already answered your actual question, but I'm always down for understanding which engines you don't like and the why of it so I can improve things in the future.  

Personally I kinda miss the stock-updated truss-mounted version of the Terrier that's one of the few stock-updated engines I think look good. (with the line that runs over it, and that little truss, it's just nice )

Edited July 3, 2019 by Jognt

[madindehead]

30 minutes ago, Nertea said:

It looks like people have already answered your actual question, but I'm always down for understanding which engines you don't like and the why of it so I can improve things in the future.  

As Jognt said, the Terrier is probably also my least favourite update. Some of the boattails annoyed because when you add a decoupler it doesn't totally shroud it. Aesthetics matter for me on that but I just didn't use that variant. I think the more I've played with ReStock the more it has grown on me. I guess I don't like some of the engine burns, but I am really being picky. Overall it's an incredible mod. And whilst I worked out how to do the parts not sure I will need it now!

[Frostiken]

On 7/3/2019 at 1:33 PM, Nertea said:

It looks like people have already answered your actual question, but I'm always down for understanding which engines you don't like and the why of it so I can improve things in the future.  

Not an engine, but I do want to say I'm not a fan of the Mk1 pod retextures. I would prefer 'smooth' textures instead of the lattice-lined (whatever you would call that), and I feel like the loss of the all-white and the lack of gray isn't enough variety. I personally turned off the Mk1 textures for that reason.

[Nertea]

16 hours ago, Frostiken said:

Not an engine, but I do want to say I'm not a fan of the Mk1 pod retextures. I would prefer 'smooth' textures instead of the lattice-lined (whatever you would call that), and I feel like the loss of the all-white and the lack of gray isn't enough variety. I personally turned off the Mk1 textures for that reason.

Too bad that you feel that way - I personally feel like the heat-resistant structure is pretty iconic from the Mercury/Gemini capsules. The stock variants, when revealed with the revamp textures for this part, were really the first sign that Squad was going in a weird inconsistent direction with variants - some would change the look at feel of the part completely (like this one) and some would be meaningless colour tweaks. We've tried to take a middle ground with the colour variants and so I don't feel like changing the surface texture with variants here is quite warranted. 

On 7/3/2019 at 1:56 PM, Jognt said:

Personally I kinda miss the stock-updated truss-mounted version of the Terrier that's one of the few stock-updated engines I think look good. (with the line that runs over it, and that little truss, it's just nice )

On 7/3/2019 at 2:08 PM, madindehead said:

As Jognt said, the Terrier is probably also my least favourite update. Some of the boattails annoyed because when you add a decoupler it doesn't totally shroud it. Aesthetics matter for me on that but I just didn't use that variant. I think the more I've played with ReStock the more it has grown on me. I guess I don't like some of the engine burns, but I am really being picky. Overall it's an incredible mod. And whilst I worked out how to do the parts not sure I will need it now!

I'm satisfied, I didn't make the Terrier so that's all good. We only did some renovation on the PJ overhaul parts - added the compact variants, cleaned up the meh emissives and a few minor tweaks. They are fairly inferior though. 

I do fully intend to redo the boattails of all the Porkjet engines at some point. probably the entire Terrier too because it is pretty weak in its non-compact configurations. 

Edited July 5, 2019 by Nertea

[Frostiken]

3 hours ago, Nertea said:

Too bad that you feel that way - I personally feel like the heat-resistant structure is pretty iconic from the Mercury/Gemini capsules. The stock variants, when revealed with the revamp textures for this part, were really the first sign that Squad was going in a weird inconsistent direction with variants - some would change the look at feel of the part completely (like this one) and some would be meaningless colour tweaks. We've tried to take a middle ground with the colour variants and so I don't feel like changing the surface texture with variants here is quite warranted. 

For me the primary issue is the shading.

We have black, black with white stripe, white with gray stripe.

The white shade of the pod doesn't blend in with anything else - it's far too bright and doesn't match the fuel tank colors on offer. Additionally, black is black enough to blend in with the 'dark' fuel tank colors, but it doesn't blend in with the dark gray of the 'Orange and Gray' fuel tank options. The stock pod color offerings, the 'white' and 'white and gray' offerings blended in with fuel tanks.

So basically I'm just suggesting two more shade options, one that is a gray that matches the fuel tanks, and one that complements the 'orange and gray' tank color. The lattice I can live with.

Edited July 5, 2019 by Frostiken

[Nertea]

7 minutes ago, Frostiken said:

For me the primary issue is the shading.

We have black, black with white stripe, white with gray stripe.

The white shade of the pod doesn't blend in with anything else - it's far too bright and doesn't match the fuel tank colors on offer. Additionally, black is black enough to blend in with the 'dark' fuel tank colors, but it doesn't blend in with the dark gray of the 'Orange and Gray' fuel tank options. The stock pod color offerings, the 'white' and 'white and gray' offerings blended in with fuel tanks.

So basically I'm just suggesting two more shade options, one that is a gray that matches the fuel tanks, and one that complements the 'orange and gray' tank color. The lattice I can live with.

This has actually come up a few times so I have a good answer for that. KSP's lighting model, particularly in the VAB, strongly accentuates the brightness difference between surfaces at different angles. Take the pod, and use the rotation gizmo to match its angle to the fuel tanks' vertical sides. You'll find that the white on all the white elements matches the standard white, the grey stripe matches the grey striping present on certain tanks, and the dark grey-ish matches the standard dark grey. 

The 'soviet' orange/grey on some of the orange/grey tanks is indeed a slightly different grey with a tint of green in it - this is considerably toned down and closer to the standard dark grey compared to the stock version, whose green-grey was pretty unique. 

[Frostiken]

Well I'll be damned.

Edited July 5, 2019 by Frostiken

[Jognt]

8 minutes ago, Frostiken said:

Well I'll be damned.

*magic*

[Nertea]

Consistent, matching colours is my #1 artistic pet peeve with stock, I'd be pretty unhappy if the Restock parts didn't conform...

Seriously, I think there's about 4 distinct 'whites' in stock that really should be the same, not including inconsistent specular intensities within those whites. You've got at least:

• Airplane parts white
• Old standard white (as on the 3.75m tanks)
• New fuel tank white (which is not very consistent between size classes either)
• New RCS block white (also using a different shader!)

IIRC the stock Mk1 pod also has a weird, different white, but you don't notice it because of the angular variations. It's like they baked the angular lighting compensation into the texture...

Orange and yellows also have some variation, windows are pretty nasty. Greys and metals , I'll allow differences, but even then those differences should try to be consistent, eg use a similar grey for fuel pipes, similar black for ablative nozzles, etc...

Edited July 5, 2019 by Nertea

[BigFatStupidHead]

20 hours ago, Nertea said:

Consistent, matching colours is my #1 artistic pet peeve with stock, I'd be pretty unhappy if the Restock parts didn't conform...

Seriously, I think there's about 4 distinct 'whites' in stock that really should be the same, not including inconsistent specular intensities within those whites. You've got at least:

• Airplane parts white
• Old standard white (as on the 3.75m tanks)
• New fuel tank white (which is not very consistent between size classes either)
• New RCS block white (also using a different shader!)

IIRC the stock Mk1 pod also has a weird, different white, but you don't notice it because of the angular variations. It's like they baked the angular lighting compensation into the texture...

Orange and yellows also have some variation, windows are pretty nasty. Greys and metals , I'll allow differences, but even then those differences should try to be consistent, eg use a similar grey for fuel pipes, similar black for ablative nozzles, etc...

It's almost as if... stock parts were made by a hodge-podge different people, all with different artistic visions and using different palettes!

 

That's another reason I love Restock.