Active Texture Management about netkan

[rbray89]

I really should do the same thing I'm planning in EVE... Split the Configs from the binaries.

[Ippo343]

I was also thinking that we could use the provides mechanism to have the user select a package. Off to test!

Update: we could have 4 packages, each one providing ActiveTextureManagement. I'm still not sure how we could extract the different downloads from the release though. If someone more skilled than me can take a look, that'd be great :)

[DuoDex]

Eugh, that's really ugly. I don't know what can be done about this...GitHub doesn't really provide a mechanism for differentiating releases.

[Almagnus1]

I think what rbray is thinking is mimicking what TACLS did with their configs, so the x86/x64 mods would require a config loaded, and the user would have to choose one.

The only gotcha is writing the metafile so that the x86 and x64 versions of ATM are mutually exclusive.

[tips48]

I think this is one of the last "big" mods we are missing, so it'd be cool to try and figure this out.

[Almagnus1]

Taking a note from TACLS, here's a way to get all four variations of the mod up, but allow other mods to point to "Active Texture Management".

This starts by including the following JSON fragments in the x86 and x64 mods:

{
    "identifier"     : "ATM-x86",
    "name"           : "Active Texture Management (32 Bit)",
    "provides"       : [ "ATM" ],
    "conflicts"      : [ { "name" : "ATM" } ],
    "depends"        : [ { "name" : "ATM-Config" } ]
}

{
    "identifier"     : "ATM-x64",
    "name"           : "Active Texture Management (64 Bit)",
    "provides"       : [ "ATM" ],
    "conflicts"      : [ { "name" : "ATM" } ],
    "depends"        : [ { "name" : "ATM-Config" } ]
}

The key here is the provide and conflict values, which allows another mod to specify that they need Active Texture Management, and not care about the specifics.

You would need to use the following fragments for the configs:

{
    "identifier"     : "ATM-config-Basic",
    "name"           : "Active Texture Management Basic Config",
    "provides"       : [ "ATM-config" ],
    "conflicts"      : [ { "name" : "ATM-Config" } ]
}

{
    "identifier"     : "ATM-config-Aggressive",
    "name"           : "Active Texture Management Aggressive Config",
    "provides"       : [ "ATM-config" ],
    "conflicts"      : [ { "name" : "ATM-Config" } ]
}

So pulling it all together, this gives mods flexibility to recommend just Active Texture Management, or go with whichever configuration is needed.

I can't speak to the rest of the settings for the configs as I haven't really looked that deeply into them at the time of writing, but this should help with the CKAN side of things.

[pjf]

@Almagnus1 : Thank you! I'm catching up on all things CKAN and your suggestions look very good! Although my understanding is the x64 builds are for Windows-x64 only, so I'd be inclined to have the identifier be ATM-win-x64 or similar so folks running Linux x64 (like myself) don't try to install them by accident. :) (My understanding here may also be wrong, so please correct me if it is!)

We could probably index these manually right now, and @rbray89 has just released ATM 4-0 which looks awesome. Having a separate zipfile contain the config(s) would be nice, but as the files themselves are under 60k in length it's hardly a big deal if we end up downloading an extra file to make the metadata look nicer. (I'm assuming the only difference between x64 and x86 are the binaries, and the config itself is identical in both.)

For full NetKAN indexing, we'll need a way to specify which asset in a release should be indexed, something like #/ckan/github/rbray89/ActiveTextureManagement/asset/x86-Basic-Release.zip.

---

References:

KSP-CKAN/CKAN#489 also has a proposal whereby we could have the same identifier but different documents based upon architecture, although that wouldn't be in until the v1.4 spec at least.

KSP-CKAN/CKAN#259 is a proposal to extend NetKAN to be able to index source releases. Being able to path to an asset would likely involve similar changes to the code.

[madlemur]

@pjf : I don't think the 64-bit builds are Windows-specific. At least, they don't break in my 64-bit Linux system. They are all OS-agnostic .net code, and should be fine on Win, Linux or OSX of the proper bitty-ness... ;) Looking at the source, the difference is just in which csharp.dll and unity.dll they are built against.

[rbray89]

Exactly. I wasn't entirely sure, but I suspect that there may be some difference in the 64-bit dll and went ahead and setup my environment to build against both. Might be a tad overkill, but it is safer.

[madlemur]

Oh, I'm reasonably sure there's a difference in the 32 and 64 bit code, but pjf was talking about the 64-bit being Windows only, which I do not believe is true.

[pjf]

I don't think the 64-bit builds are Windows-specific. At least, they don't break in my 64-bit Linux system.

This is good to know. Mainly I was flagging this because winx64 seems to be the problem child at the moment, and because for Linux, the same csharp and unity assemblies are used regardless of whether 32 or 64 bit KSP is used.

I know that both Linux and Windows use unity 4.5.2 for KSP 0.25, but I have no idea if the assemblies are different for the experimental 64-bit Windows build. (It wouldn't surprise me compiling against the different assemblies resulted in the exact same code as I expect all the method signatures to remain the same, but I'm not that knowledgeable with the guts of .NET.)

[AlexanderDzhoganov]

ATM is now on CKAN, enjoy :)