Poodmund

You're right, the height and normal map are correct, colour and biome upside down. Outer Planets Mod v2.2.11 - Fixed vertical orientation of Nissee colour and biome maps. https://github.com/Poodmund/Outer-Planets-Mod/releases/tag/2.2.11

I expect that both of you are using mods that leverage the vanilla assets that are being blacklisted in Restock. Please see https://github.com/PorktoberRevolution/ReStocked/wiki/Asset-Blacklist-and-Whitelist You're not doing anything wrong. A new part model was just released and you're using a mod (some set of Waterfall configs) that provides different plumes that hasn't been updated to be compatible yet. Its been a total of 17 hours since release, I'll cut the plume config mod author some slack.

Restock v1.5.0 ------ - New parts (all Kavaeric) - LV-T91 "Cheetah" Liquid Fuel Engine: now has 1.25m Truss, 1.25m Boattail, 1.875m Truss, 1.875m Boattail and Compact variants - LV-TX87 "Bobcat" Liquid Fuel Engine: now has 1.875m Tankbutt, 1.875m Truss, 1.875m Boattail and Compact variants - Mk-55 "Thud" Liquid Fuel Engine: now has White Shrouded, Orange/Grey Shrouded and Compact variants - EAS-1 External Command Seat - SEQ-3 Cargo Storage Unit: now has White and Metal variants - SEQ-3C Conformal Storage Unit: now has White and Metal variants - SEQ-9 Container Module: now has White and Metal variants - SEQ-24 Cargo Storage Unit: now has White and Metal variants - Fixed extra random png texture in the distribution (#1017) - Fix NRE when ModuleRestockHeatEffects encounters a missing renderer (#1009) - Fixed rotation of Mk2 Lander can airlock (#1008) - Fixed LT-2 landing leg being weaker than stock (#858) Restock+ v1.5.0 ------ - Introduced patch to give roll control gimbal to Making History LV-T91 "Cheetah" Liquid Fuel Engine. - Added VABOrganizer support - Added Russian language localization (BalaurGD). - Removed Test contract from legacy SRBs and legacy vernier engine. https://github.com/PorktoberRevolution/ReStocked/releases/tag/1.5.0

Would having the full, buildable/compileable source code available, outside of a platform like Patreon, up to date with the code in distributions being shared, satisfy the requirement of being accessible? Would this then be fine?

Forum rule 2.2.i, which I guess is the rule in question here, states: Self promotional posts or that promote a 3rd party for profit, monetization other than optional donation (adf.ly etc) and advertising products or services without prior approval; Its a fine line but I would expect that you should be able to post about a mod that is in development, where the mod developer provides access to their in-development work, prior to full free release (with complete open source at all times as per the forum rules), via supporting them on Patreon, as the option to get access before release is completely optional. Therefore if a user wants to make an optional donation of support to the mod developer, and as a by product gain access to the in-dev work that is not intended for public use, that should be okay. This is all on the premise that the contents of any in-development distributions on a platform, such as Patreon, have the full, buildable source code easily referrable. This is the big dependency here as if this isn't met, then you could argue that General Add-on posting rule 5.1 is violated.

You could install this for a new player and they'd never realise that it wasn't part of the vanilla game. Looks so slick in action.

You eat it with some McFries and Coke... ... I dunno, you go figure it out and I can update my post.

Essentially, yes, as this is a backend value and, although it is technically user facing, it is a bit meaningless to the user. The identifier here could be 'Duck Bill Goop' and it would make no difference to a user. I've reported my own post here as this whole conversation feels a bit overblown and de-railing (as a complete outside observer).

From an end-user standpoint, this changes basically nothing. Your name is still linked to the mod and searchable by it, quite rightly, as you made it.

Use my forum style and you can get rid of a load of the gumph around the forum layout that's unnecessary.

Seeing the start of the forum reorder was a very pleasant surprise today!

Subterfuge? Ooooooh, so we have deceit and nefarious meetings now do we? I would say that 'people' rather 'wanted to stay away from the KSP2 modding scene' because the game state was a mess. Hopefully this whole thing is completely irrelevant and the forum will stay in operation. That's the number 1 hope here.

Essentially this has already been discussed elsewhere, and movement started on this a while back with a current estimation (of public facing content) that a static snapshot of the forum as of around 3 days ago totals to roughly 8.5GB in size. Its not "exactly" a static snapshot as bandwidth is being cranked right down using a single connection as to not put any considerable load onto the site, and therefore there may be some desync in posts but as its front facing content using a drill-down approach its good enough. If this matures and is workable then, at the very worst, we would have likely a monthly fall back to an archive of sorts. I'm speaking entirely on behalf of those working on this so they can continue in quiet without being hassled.

But why lock the thread? Seems like it was done because there were off topic posts. That doesn't seem like grounds to lock a thread, just delete/moderate the posts and let discussion continue. If its because none of you have the access to actually perform the task then that's a different topic altogether, and, as such, just be open about it and say something like, "Sorry guys, none of the moderators have access to the back end IPB Admin CP and therefore we do not have the capability to re-order the forums." At least then the community knows where they stand. At the moment it comes across as a snap judgement and gagging people from being able to discuss the pros and cons of the suggested actions from the poll results.

PLEASE, PLEASE, PLEEEEEASE, split out the KSP1 mods sub forums under a main KSP1 Mod category like it used to be so that we don't have to click into a KSP1 modding sub forum to then navigate to Add On Releases or Add On Development. Having them immediately accessible from the main forum page is such a QoL improvement. ... that and the fact they are the most active part of the whole forum.

There are a few things going on in the background of Restock development that we will share in the not too distant future but I will share an insight into what I have been working on and will be working on over the next month or two... An aerodynamics/drag cube update! Its always been known that Restock does have some effect on the aerodynamics compared to the stock/vanilla game. This is mostly due to the way drag cubes are generated at start-up wherein the game will look at the front, side and top profiles of the parts and assume drag characteristics from these views. As Restock changes the models of the parts, if we don't manually specify the values for these drag cubes exactly as they are in stock, these minor changes in visual profile can generate different drag cube values and affect the aerodynamic characteristics of vessels in the game. Recently, VAOS and Matt Lowne both addressed this in recent videos of theirs (its nice to hear that VAOS said they'd take it on the chin and use Restock ). One of Restock's goals as a mod is "do not affect gameplay or part balance," and this drag cube issue has always impacted our ability to meet this goal. As such, I've (stupidly, now I know the level of work involved) decided to address this and see if I can fix this for good. I've gone through all the current Restock part patches and have edited all of the parts to ensure that they match the stock game setup as far as: useMultipleDragCubes = true (default/not specified) useMultipleDragCubes = false useProceduralDragCubes = true These three values specify whether a part should just have multiple sets of drag cubes for each variant, a single set of drag cubes across all variants of a part, or have them procedurally generated depending on what various things (engine plates, for example, have these done procedurally). I've also created a patch that will sit outside of the part configs that patches every single Restock part, in a Module Manager pass after '000_ReStock' that deletes all drag cube that exist for each part then re-applys drag cubes to the parts, as specified in the vanilla KSP1 1.12.5 Steam distribution of PartsDatabase.cfg. The final big piece of work that I am going to have to do that will be icing on the cake is that I'm going to have to go through this patch, part by part, and correlate the stock drag cubes with each of the part variants between stock and Restock, and where Restock has more variants, include additional cubes with either appropriate duplicates from stock, or use custom generated ones (I've generated custom drag cubes for all the Restock variants) for variants that have no appropriate stock variant shape/size. *Sneak peak* This is gonna take quite a lot of time and manual effort but at the end, we should ultimately have Restock in a place where users' crafts should experience the same aero between stock and Restock assuming they play with the vanilla Steam 1.12.5 drag cubes. To put it into perspective, there are around 260 parts in Restock and many have multiple variants and this task will require assessing every single variant, so please be patient. And, at that point, hopefully, Restock will not affect vessel aerodynamic performance.

Sssshh... don't tell everyone our secrets.

Thank you for this bug report. The issue was that some of the SRBs had been soft deprecated due to vanilla parts changing but the config files for these had not had the test contract patches removed. I've rectified this on my end and will be resolved in the next release. And do not delete the .mu files.

I presume by 'both versions' you mean the Restock art and the vanilla game art. If that is the case, then, no. Replacing the majority vanilla game artwork is the main goal and ethos behind this mod to achieve the following: Create a unity of design and style for all parts Preserve the general aesthetic of KSP Create consistency in the detail level of all parts Keeping the vanilla part models available is not something that this mod aims to cater for. If you want to hack them back in then its kinda on the end-user. The Wiki entry provides the instructions but you'll have to do the leg work.

And as much as I'm trying to resolve, old, outstanding issues... concerning the new content, Kavaeric is the real star here. A perfect addition to the Restock crew.

What's this?! Two releases in two weeks?! Restock v1.4.5 ------ Add drag cubes from KSP 1.12.5 Vanilla to the following parts (this should help a lot with re-entry with craft designed in Vanilla): Probodobodyne QBE Probodobodyne Stayputnik Probodobodyne HECS Probodobodyne OKTO Probodobodyne OKTO2 Probodobodyne HECS2 RC-L01 Remote Guidance Unit RC-001S Remote Guidance Unit R-4 'Dumpling' External Tank R-11 'Baguette' External Tank R-12 'Doughnut' External Tank Heat Shield (0.625m) OX-STAT Photovoltaic Panels OX-STAT-XL Photovoltaic Panels Fix engine attachment nodes on the Making History Kerbodyne Engine Cluster Adapter Tank. New stock part replacement: T-1 Toroidal Aerospike "Dart" Liquid Fuel Engine. Restock+ v1.4.5 ------ Add part volumes for all parts under 2700L to allow for use with the stock inventory system (by mostly using KSP Part Volume mod to generate volumes). Fix engine attachment nodes on the Kerbodyne SIV Fuelled Engine Adapter. Available via GitHub, Spacedock and will be indexed on CKAN in due course. Can we all issue a warm welcome to the Restock team, @Kavaeric, who has kindly developed the Dart Aerospike engine with us for this release. Not only does it feature an amazing heat emission visual but also includes a boat tail variant for all of you who want to use if for space planes and small lifters etc.

For the Vanilla assets that Restock replaces, it stops those Vanilla assets from loading so that they do not increase resource usage. Restock contains a small plugin to handle this and it is done upon game load... so please don't be concerned about trying to lessen the PC resource usage due to unnecessary Vanilla textures being loaded when using Restock.

The Restock+ parts that hide themselves if MH is installed will share the same models as the MH parts if Restock is installed. You can confirm this by, for example, looking at the configs for the RE-I2 "Skiff" in Restock and the config for UR-2 "Caravel" in Restock+... they both point to the same model at 'ReStock/Assets/Engine/restock-engine-caravel-1'. There may be minor stats differences to the parts i.e., thrust, Isp etc. where the team felt it was more appropriate but the models and textures will be the same.

Hi @CanOmer, its been a while, but I've gotten around to adding ModuleCargoPart volumes to all of the Restock+ parts using the mod KSP Part Volume to generate the volumes of the parts (and a little manual calculation in Blender for some of the animated parts). You can find all the changes here: https://github.com/PorktoberRevolution/ReStocked/commit/6d573ff53e6f1fd771b407e55b825deff5fcf70b Are there any missing that you can think of? The most volumetric, storable part in stock is 2400 litres and I stopped for the RS+ parts at 2700 (or there abouts). Is anybody else experiencing this? I cannot replicate this.