[1.x+] Community Resource Pack

[Zenith22]

On 4/20/2020 at 1:41 AM, zer0Kerbal said:

I know I don't bundle. Installed via CKAN for any mod of mine.

Also using CKAN to install mods, it won't let me download this one because it says it is only compatible through KSP 1.8.x. Wondering if there's a way to get around this issue within CKAN, or do I just have to wait for this to get updated?

[Gargamel]

1 minute ago, Zenith22 said:

Also using CKAN to install mods, it won't let me download this one because it says it is only compatible through KSP 1.8.x. Wondering if there's a way to get around this issue within CKAN, or do I just have to wait for this to get updated?

If you check the CKAN thread, or this tutorial, it will show you how to install outdated / non-compliant mods using CKAN.

[Mossconfig]

So, what mods allow you to get the stuff out of the ground? I know the USI drills work, but I want to use kerbalism. Is there a thing that adds the ability to configure drills to extract certain materials, not just ore.

 

[RoverDude]

17 minutes ago, Mossconfig said:

So, what mods allow you to get the stuff out of the ground? I know the USI drills work, but I want to use kerbalism. Is there a thing that adds the ability to configure drills to extract certain materials, not just ore.

 

Probably worth asking in the Kerbalism thread

[majNUN]

I have a file called AsteroidScannerSetup.cfg in my CRP folder, and it is empty. Does anyone know where this came from? I'm trying to hunt down the source as it is giving me an error.

[goldenpsp]

24 minutes ago, majNUN said:

I have a file called AsteroidScannerSetup.cfg in my CRP folder, and it is empty. Does anyone know where this came from? I'm trying to hunt down the source as it is giving me an error.

Not offhand.  It isn't in the core CRP mod files.  I'd look through the other mods that bundle CRP and see which one has that file.

[etmoonshade]

I think this is a feature request more than a bug report, but...

Is it worthwhile to define volume correctly for all the resources? The reason I ask this is that I'm trying to script up something that generates procedural tank definitions (for Procedural Parts) based off the CRP configs, but I find that simply using (1/density) means that every single tank of a particular size ends up weighing exactly the same. Which is vaguely hilarious, but really counterintuitive.

What I do not know is where this would cause knock-on effects - presumably any static configs would be safe, but anything that actually uses resource volume to calculate anything (apparently B9 Part Switch and KIS, according to the KSP wiki?) would presumably be affected.

[RoverDude]

6 hours ago, etmoonshade said:

I think this is a feature request more than a bug report, but...

Is it worthwhile to define volume correctly for all the resources? The reason I ask this is that I'm trying to script up something that generates procedural tank definitions (for Procedural Parts) based off the CRP configs, but I find that simply using (1/density) means that every single tank of a particular size ends up weighing exactly the same. Which is vaguely hilarious, but really counterintuitive.

What I do not know is where this would cause knock-on effects - presumably any static configs would be safe, but anything that actually uses resource volume to calculate anything (apparently B9 Part Switch and KIS, according to the KSP wiki?) would presumably be affected.

Sorry, what do you mean by define volume correctly?    

Right now, tanks using CRP of the same size end up with different resource masses - i.e. as far as I can tell this is working just fine.  Unless there's something else you are asking for that I am missing?

[etmoonshade]

Figures, I was actually editing to clear that up and got distracted by a satellite launch.

In CRP, everything is defined with a volume of 1unit/liter (see: https://wiki.kerbalspaceprogram.com/wiki/CFG_File_Documentation#Resource_Configuration_Files - it's actually defined in L/u, but I'll use the inverse here since that's what PP essentially uses.) Density, on the other hand, seems to be defined in kilograms/milliliter? Not useful when you're trying to decide how many units to stuff into a tank of a specific size.

To use an example, NFT seems to be using a volume of 209.48u/L for ArgonGas. I have no way to extract this "correct" data short of digging through .cfg files and doing the math for each part individually. If I had that data to feed into my script, I could use 209480u/kL as the tank size, let the game figure out the mass of that, and it'd work - no weird super-compressed (or super-uncompressed) tanks. This math meshes pretty closely with what shows when I look at the parts - 200000u/kL. It's in a part that reduces tank capacity by a percentage depending on what's stored in it, so I consider this "close enough" for me to say my math is working right.

All this is as far as I can tell, at least. It's possible I'm missing something else that I could grab that would let me decide this, or I've got my math entirely wrong. And I admit, volume data is of no use if you're just defining the parts by hand - you're going to either have the info on hand, or you're going to fudge it (and end up being inconsistent with other parts that use the same resource.) If someone is making a new mod using CRP resources though, they don't have an easy means of maintaining consistency with other mods that use the resources.

Edited July 19, 2020 by etmoonshade
kg/mL, not g/u...

[RoverDude]

Consistency with other mods is actually really easy.  Look at all of the stock tanks (or tanks of stock-alike mods).  Note that in stock, units are actually 5l each not 1l (we chose 1l normalized volume when CRP was made - Rocketparts I believe are the only ones still at 5l).  And in stock, the mass/volume ratio is consistent for all fuel tanks.  So volume is still 'correct' from a CRP standpoint.  Everything is normalized off of the 1l unit.

So to figure out how many units to stuff into a tank... that's easy.  Measure the tank volume in liters.  That's how many units fit inside.  Stock btw starts with tank dimensions, chops off a percentage for the walls of the tank, then we manually round it to a reasonable unit number - but at the end of the day, a tank's volume and dry mass have a set ratio used for balance.

So the initial ask - correction of volume - does not make sense.  The volumes are all already correct.  So I remain confused on what the ask is?

 

[etmoonshade]

No, you're not confused on what the ask is - it was just an incorrect assumption based on the content of one of the mods that are part of the CRP.

Having every volume set to 1 looked like a placeholder to me rather than an intentional choice, since NFT doesn't seem to follow that scale (and of course, that's what I've been using lately since I'm not into the KSPI-E phase of my game where I may have noticed consistent numbers.)

I'd ask for it to be stated in a comment at the top of CommonResources.cfg or somewhere in the OP though - it'd have saved me a fair bit of time to have it explicitly said that resources are normalized to 1u/L, and that it's the fault of other mods if they don't follow that guidance.

[aradapilot]

Looks like a few people have gotten this working on 1.10...but are there plans to rebuild it against that version?

[hemeac]

5 hours ago, aradapilot said:

Looks like a few people have gotten this working on 1.10...but are there plans to rebuild it against that version?

@aradapilot, this mod is just config files and does not have any compiled code. As the syntax in the config files has not changed, there is nothing that needs to be updated. It is safe to use in 1.10.

[aradapilot]

cool, this should make it play nice with dependency chains (set max ksp to 'any')

https://github.com/BobPalmer/CommunityResourcePack/pull/249

[Wuwuk]

Please set max ksp version to 'any' on GitHub/ckan like "Community Category Kit".

[HebaruSan]

Posting here because I'm not sure how often @RoverDudechecks GitHub...

This PR was closed in error. I explained in a comment, please have another look.

• https://github.com/BobPalmer/CommunityResourcePack/pull/255

Edited December 20, 2020 by HebaruSan

[RoverDude]

9 hours ago, HebaruSan said:

Posting here because I'm not sure how often @RoverDudechecks GitHub...

This PR was closed in error. I explained in a comment, please have another look.

• https://github.com/BobPalmer/CommunityResourcePack/pull/255

Not closed in error.  That fix is moving up with the new version tomorrow.

[HebaruSan]

5 minutes ago, RoverDude said:

Not closed in error.  That fix is moving up with the new version tomorrow.

If there's another release coming then it's not a high priority, but yes, it was closed in error. That file's URL is in the URL property of the version file in the release. It's live now, affecting users, and fixing the syntax error in between releases would make a difference. This isn't the kind of thing that makes sense to delay until a new release.

[RoverDude]

Just now, HebaruSan said:

If there's another release coming then it's not a high priority, but yes, it was closed in error. That file's URL is in the URL property of the version file in the release. It's live now, affecting users, and fixing the syntax error in between releases would make a difference. This isn't the kind of thing that makes sense to delay until a new release.

It was not closed in error.  I do not take PRs to Master, I take them to Develop.   I then promote them to Master.

[HebaruSan]

4 minutes ago, RoverDude said:

It was not closed in error.  I do not take PRs to Master, I take them to Develop.   I then promote them to Master.

The URL field of a version file points to a remote copy of the version file intended to be updated as needed. Making it a static copy of the file in the release, unchanged till the next release, defeats the purpose of that aspect of the KSP-AVC architecture. A syntax error just adds insult to injury.

This pull request should have been merged, not closed. Ideally soon after it was submitted 17 days ago, but it's understandable that folks are busy.

[RoverDude]

1 minute ago, HebaruSan said:

The URL field of a version file points to a remote copy of the version file intended to be updated as needed. Making it a static copy of the file in the release, unchanged till the next release, defeats the purpose of that aspect of the KSP-AVC architecture. A syntax error just adds insult to injury.

This pull request should have been merged, not closed. Ideally soon after it was submitted 17 days ago, but it's understandable that folks are busy.

I have a process for promoting code.  Full stop.  While you may disagree, that's fine, but it's not going to change the process.  And I will continue to close PRs sent against master.

[HebaruSan]

29 minutes ago, RoverDude said:

I have a process for promoting code.  Full stop.  While you may disagree, that's fine, but it's not going to change the process.

Maybe consider using http://ksp-avc.cybutek.net/ for the remote version file in your URL property, then. It shouldn't point to a file that's locked down by process.

29 minutes ago, RoverDude said:

And I will continue to close PRs sent against master.

https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/changing-the-default-branch

[RoverDude]

FYI 1.4.2 is up

[alphaprior]

Is there a guide for all resources? There are some which I have zero information like mopedantte, borate, fluorite and spodumene which I can convert into lithium and then what?  mopedantte

Edited January 29, 2021 by alphaprior

[goldenpsp]

4 minutes ago, alphaprior said:

Is there a guide for all resources? There are some which I have zero information like mopedantte, borate, fluorite and spodumene which I can convert into lithium and then what?

These are all just resource definitions there.  How they get used will be a part of whatever mod is making use of them.