Jebs_SY

@Angel-125 May I friendly ask if I could help bring these great mods to CKAN? I think I know a little bit about how CKAN works and your structure seems pretty ready for automated CKAN use. You have a version file in the zips, which CKAN reads and analyzes it for a new version. You have a good file name on github DSEV_*version*.zip, which can be indexed that way by CKAN so it recognizes a new release on github. The dependency for me seems to be the Wildbluetools. I think this is totally doable in CKAN and when it is set up correctly, you have nothing to do from you side when you update. Just make a new GITHUB release and the rest is done automatically. o/

Does anyone have some examples, which game functions that are? For getting more understanding of overall mod-incompatibilities I would love to know...

This is the same problem as in SVE, the "release download filename on github" changed, so CKAN doesn't find the new updates... And the LR version is gone and now there is one version only for PC and one version for Mac/Linux. I wonder if CKAN can differentiate between Win and Mac/Linux?! At the moment the Netkan indexer matches to THIS. ("SVT.High.*.zip" for SVT-HighResolution and "SVT.Low.*.zip" for SVT-LowResolution) Old filenames were: SVT.High.Resolution.v2.0.zip SVT.Low.Resolution.v2.0.zip Version 201 filenames were: SVT.LR.v2.0.1.zip SVT.v2.0.1.zip Version 202 filenames are: SVT.v2.0.2.Mac.Linux.zip SVT.v2.0.2.zip @Galileo Do you know if the new 2.0.2 naming convention will stick for a while? So it would make sense, that the CKAN guys can adopt to that? LR version is gone and the normal version is splitted into Win and Mac/Linux? Maybe use "SVT.v2.0.2.Win.zip" for the Win version to make it perfectly clear?

Just a quick notice: CKAN is now up2date again and installs SVE correct again. @Galileo CKAN's auto index searches now for new versions of for these 2 sub-packages ( SVE-sunflare and SVE-Scatterer-Config) in every github release file with Scatterer in it's name. See also here. The other packages are matched against "SVE.HR.*.zip" (HR,LR,MR), see also this, if interested. If you change the naming convention, you can give the CKAN guys a notice, if you want. o/

Are you sure? These three packages are listed correct for 1.1.6 (actual) in my CKAN. Just SVE-sunflare and SVE-Scatterer-Config are on the old 1.1.4, cause the CKAN system cannot find the 1.1.6 ".version" file of these 2 packages, cause it searches the ".version" files at the wrong place (SVE.Scatterer.cfgs.zip up to v1.1.4), cause the "github download filenames" have changed to SVE_Scatterer.zip (from v1.1.5 on). I think CKAN missed the update of SVE-sunflare and SVE-Scatterer-Config cause it doesn't find the 1.1.6 ".version" files for these 2 packages, cause it does not know about the new release location (SVE_Scatterer.zip). And I expected this netkan line must be changed for SVE-sunflare and SVE-Scatterer-Config, but I am not sure: "$kref" : "#/ckan/github/Galileo88/StockVisualEnhancements/asset_match/SVE.Scatterer.cfgs.zip" I assume when CKAN finds the actual 1.1.6 ".version" files for SVE-sunflare and SVE-Scatterer-Config in SVE_Scatterer.zip on Github it will make the version jump for the SVE-sunflare and SVE-Scatterer-Config packages. EDIT: @linuxgurugamer Thx for your work, anyway. I assume the kref line in the netkan for SVE-sunflare and SVE-Scatterer-Config must be changed (release filename change here from 1.1.4 to 1.1.5/6). So maybe ping @politas here?

A version change AND a download / download-for-index file name change.

@Torih Wait or install it manually. At the moment CKAN still installs the old (incompatible) scatterer config, cause of a file name change. The CKAN guys / Linuxgurugamer is on this issue. I expect it to be resolved, soon.

Thx for looking into this. Not this?: "$kref" : "#/ckan/github/Galileo88/StockVisualEnhancements/asset_match/SVE.Scatterer.cfgs.zip" ? At least CKAN picked up the change to 1.1.6 for the other SVE packages, but not for the two above. They are still on 1.1.4. Check scatterer\config\planetlist.cfg. A scatterer v0.300 compatible config must now have a "mainSunCelestialBody = ..." in each item{...} listed there. If that's missing, scatterer memleaks KSP fast until the system dies by swapping. At least for me.

@Galileo I've noticed the CKAN guys that the release file name changed from "SVE.Scatterer.cfgs.zip" to "SVE_Scatterer.zip", that they can update their setup and it will install correct via CKAN again. o/ If you're curious, these two netkan files need to be updated: File1 File2.

2 parts of Stock Visual Enhancements need a netkan update cause a release file name changed from "SVE.Scatterer.cfgs.zip" to "SVE_Scatterer.zip". This is a little bit important, cause the actual situation (old scatterer config files with new scatterer) breaks KSP for the people that install SVE via CKAN. The two netkan files that need to be changed (if I see this right): File1 File2. I've checked the old and the new and the folders that are used by the netkans are inside, so it seems that only the filename change listed above must be included to the netkan files. A second look to verify this would be good, still. @linuxgurugamer May I ping you here?

Well, for me the flickering still throw's this exceptions and can be seen here in this video. Version in this video: 0.5.20 It seems unrelated to the move into the janitors closet toolbar, cause I have had the same issues when USI-LS is directly in the stock toolbar. One more thing is, that it does not always happens. Unfortunately, I didn't found out, when it happens. As I read the error, maybe if a Kerbal is/was on EVA?

@FreeThinker Well, if it's like stock, it is redundant. And one has to say, KSP-I with CTT does also need (much?) more science to unlock the whole tech tree. At least my highly-modded CTT game in normal difficulty needs around 150.000 science points to unlock the whole CTT (exept 2 unused nodes). In my opinion 2-3 times the stock cap(s) value would be great, so it's a "advanced" lab. (When fair lab is not installed). I think you could also raise the energy/conversion cost, to make the "advanced lab" more expensive in costs of energy to pay for that. But as the time-efficiency of the lab goes down, the less (data) it is filled, there is also a direct downside to a higher cap, cause the time-efficiency goes down when you didn't have enoug data to fill it up. So overall there is some balancing... higher cap ... (maybe more energy) and less time efficency when not enough data is aviable to fill it up.

Edit: Well, nevermind.

Cause the stock science lab is already overpowered. The data and science limit is to counter that. So one has to do something at least something (switch to it, click transmit science), to get the science. @FreeThinker When one pushes experiment results to the lab, it generates data points. At the stock lab there is cap at 750 max. Then the data points get converted to science points over time (data points x 5 = science points). The science points have a cap of 500 max, so after filling the data by pushing experiments to it, the main task is to transmit the science in regular intervals from the LAB to the space center. One more thing is, as more data is in the lab, as faster the conversion is running. So it is helpful, to keep the data value from 50-100% filled. The science lab has already much power (cause the x5 multiplier) to unlock the half/whole tech tree with some experiments. The _only_ downside to it is, you have some manual work (push data in, timwarp, send science home). So playing with data cap and the science cap in my opinion is a big balancing factor. I cannot say what I would like. Sure, small values are sometimes annoying. But if both would be 10000 maybe, it's almost a fire and forget weapon to unlock the complete science tree. Which would be to easy. Maybe one should go like 10x stock, so 7500 science cap and 5000 data cap. But even that is a (maybe to) huge gain compared to the stock lab. Maybe 5x stock? One may not forget that the conversion speed is determined by the scientist level and how much the lab-data is filled in percent. So if the lab has a high data cap one needs to put in much data to make it go efficient. OK, that's at least one "downside" to the KSP-I-lab, which is good in this case, to have a downside, to make it not to easy.

@Galileo Couldn't you just add "mainSunCelestialBody = Sun" to each Item in planetList.cfg as quickfix and release this as 1.1.5.1 hotfix? I think it would work with the old and the new version of scatterer. It's a little unfortunate, that the new scatterer memleaks to death when this line is missing, instead of maybe just "not work", tho.

Maybe read some posts up, if you wanna play KSP 1.2.2 with IR.... Could help. Maybe.

Yes, can confirm. At least sometimes. Maybe when a target is selected? I don't know if it's always.

Look into the ZIP. It includes a gamedata folder on top level. So you need to extract this zip to the KSP directory.

Sure, I would like to. But for a strange reason nothing shows up... I used the githup-dev-master zip. The version is correct: TweakableReactionWheels v0.1.18.0 Scale v2.3.4.1 Scale_Redist v1.0.0.0 DynamicTanks v1.0.0.0 But there is no log entry around it. There is no "partprefab" in the whole log. Hmm. I don't get it. I have to say that this occurs after KSP loading while in the main menu (even before loading a save). And it is a highly modded install. Any more ideas?

@pellinor Could you take a look at this NRE at the main menu? Could that be handled?

Can it be, that just the real chute setup in this vehicle is flawed? Loren, could you try remove all chutes, (save, load) and add them again? Or maybe use another type of chutes? Maybe the stock radials and test again? EDIT: Oh, didn't noticed that there was another page on this thread, already... so you both are maybe already on a trace...

@magico13 I just can say that I am playing with real chutes and for me everything is working. At least I didn't found any problems, yet.

This is just a notice for you, it should work anyway. And it does work for me on 1.2.2. Installed via CKAN, too.

@linuxgurugamer THB, I would welcome a "last updated" row, too. So just sort by the freshness of the latest update. However, I assume CKAN-client doesn't have this information right now. If it would have this information, I assume, we already would have such a row.

@Ursu Mare @BlackHat You could just export your favorite KSP-1.1 CKAN mod list to a CKAN-file. And here and then you use "install from CKAN" on your KSP-1.2 install... now all compatible mods from that list are getting installed. If you like, you can do this once in a week or each day before you play KSP. When mods of your 1.1-list are updated and got 1.2-compatibility, CKAN will just install them. No need for scrolling / manual check. I doesn't say that a "last updated/changed" field would be useful. I would like it. But keep in mind that the devs working on it completely free in their free time, so I am very happy with what we got so far.