Poodmund

The rules state: So this kind of explains all. Mods contain intellectual property and, like most 'software', it can be protected so that the creators can ensure that their property is handled in the way that they intend. For example, if a mod is licensed under Creative Commons Non-commercial, Sharealike it requires that all further work and distrubution of the work also be open and can be shared between distributions but it must never generate any commercial revenue by the distributor. This kind of thing can stop mods being exploited. If you're working on a pre-existing mod, look at what the mod was licensed under previously. In nearly all cases in that scenario, you cannot distribute a mod under a more restrictive license as the previous license may impose requirements on you in the distribution of the continuation. The best bet is to look at the range of options available for license and pick the one that; satisfies any pre-existing license requirements, suits your needs and is applicable to the type of software (mod) you are releasing. This thread is not exhaustive but is a good starter:

https://goo.gl/Wn03VL

Its quite hard to place each antenna, reflector into a usage group. As there are only a small handful of antennae in the stock game for each range its quite difficult to add in new parts to fill niches when the stock parts cover such a massive range of powers already. You can kind of get round this by making parts' models larger or smaller so that the real limiting factor is how you can package them up within your payload. NF:Ex does this quite well as, generally, it offers some really small antenna parts which are nice but they are pretty anemic in power, maybe a little too much. Also some of the parts that are intended to be used in arrays (multiple antenna parts feeding into a reflector) have their feed factor or combinability exponent too low to actually make their usage in an array impractical as you end up needing too many to justify the size. Basically... balancing this set of parts is extremely difficult. You need to consider a usage case or usage set for each part, tailor the powers to provide that capability, if a part is supposed to be used as a multiple (array), then figure out how many you want to be able to provide that usage case... is their still a usage case, though, with just one? Then there is exploit situation, like that specified above, where a part with a combinability exponent of 1.00 (which is a legitimately chosen value for this part for gameplay aspects) can get spam placed pointed at a reflector to take advantage of the reflectors power as opposed to its own very low power. Wyzard, what I would suggest is that if you are serious about trying to rebalance these parts to take a look at my calculator spreadsheet, specifically the sheet that allows for NF:Ex calculation, and see what types of combos provide different max ranges. This should give you a good idea of what is underpowered, what is overpowered etc. With respect to Nertea's comment above about variables, the only ones that really matter for the vast majority of the gameplay are power, combinability exponent and feedability.

*sigh* Good question. There's a simple answer, people.

Potentially yes, but by implementing it the way I suggested (or similarly in the correct node location) keeps backwards compatibility with existing packs and also would follow convention with the implementation of new shaders like the triplanar terrain shader. I would urge all new contributors to study the existing config syntax and structure, looking at the Kittopia stock body dumps and also looking at a range of the existing popular mods out there to get an understanding of how mods that use Kopernicus expect to be written with regards to their celestial body configs. It's a pain, not only, having, to fix bugs and get new feature implementation working but also considering third party mod dev usage but I think it's one that is still quite important to the makers of the Kopernicus packs to use Kopernicus' full potential.

Would allowing us to specify a material in the scaled space node be a good way to handle it? The default would be the lagacy shader so no additional info would be required and then if you want to use the new system, specify the new shader and then have a node inside the scaled space node where all the new shader's material properties can be set? Thats, of course, if I'm understanding the implmentation correctly.

Or just use Kerbal Alarm Clock to add in the alarm dates for the transfer windows.

Party pooper... can you not suspend the sense of disbelief for a minute?

The new Magnetometer part is listed as 0.5t, being the heaviest science part in the game (including DLCs) apart from the large Science Laboratory part yet it is very small, similar in size to the Barometer and Gravioli Detector which only weigh 5kg (0.005t) albeit they do not extend out. So... is this just a typo, an oversight or maybe the Magnetometer is made of some crazy high density material like Osmium (or Kerbal equivalent). What are your thoughts?

The issue I think with posting this on a forum where hobbyist mod developers post their work is that 99% of the hobbyist mod devs here are exactly that, amateurs. Even though a good handful of the community would be great fits for some of the listed roles over at Intercept they may not have any professional experience although they have had years of experience producing amazing content here for KSP and other games at an amateur level. I hope you appreciate this when considering the applications from the great members of this forum who have no doubt expressed their interest. - A humble plea from an invested member of this great community

... as for the Cheetah or Bobcat, if you follow the Projects and Issues sections on the GitHub repo you'll see what nearly all of the plans are for all the parts. For reference, there has been some work on a Bobcat replacement by another contributor but there is no ETA.

This looks really neat. I always think, if I can easily and quickly identify 4 landing spots that I'd like to explore on a body then its a winner and this definitely has that, whist still retaining the topographical feature scaling to make it look like a Kerbal-sized body (sometimes hyper-realistic looking bodies lose their Kerbal charm). I'm super excited to see how this 'scaled space' view is replicated down on the actual surface and I can only hope that, by release, it has a similar fidelity! EDIT: Also to echo the above, the Dres Canyon/Valley was one of the coolest topographical features of any KSP body... it'd be cool to see it featured somewhere.

It could be one of those situations where you think they're going to handle it and they think you're going to handle it. Thanks for the confirmation anyhow.

There is an issue with the new drag cube generation for that Light Globe part, likely to do with an animation within the .mu. An easy way to resolve this, @firda is to just rename the Light Globe config part extension temporarily to stop KSP from trying to compile the part on game load.

A picture says a thousand words. Anyone have any thoughts on this?

Most likely due to the gas giant bodies in OPM being templated off of Jool (traditional gas giants) rather than Beyond Home's gas giants not being 'traditional' gas giants in that sense and being templated off rocky celestial bodies with a PQS mesh. Kopernicus may require and update or a change of syntax may be in order for mods to specify which material shader is to be used for their Jool templated bodies.

I can reproduce the issue and have logged it here: https://github.com/PorktoberRevolution/ReStocked/issues/869

If you are referring to Sigma: Dimensions compatibility then yes, it does work. It might be worth noting that there is currently a bug within Kopernicus, as of this time of writing, that causes ground scatter to sometimes spawn above/below ground. This mod does not affect the ground scatter placement, it merely enables the colliders on the scatter. Once this bug is resolved by Kopernicus you should experience ground scatter being correctly restricted to the terrain surface: https://github.com/prestja/Kopernicus/issues/5 EDIT: This above mentioned bug is now fixed.

This is not the case. The scatter implementations require a seed number to be specified from which the distribution and placement is determined from. All ground scatter seed numbers are consistent between playthroughs and sessions unless SQUAD revise the body's config i.e. for a revamp.

Stock Scatter Collider Enabler Patch The recent celestial body revamps implemented by SQUAD into KSP are of a high enough quality that many players are no longer using 3rd party mods that revamp the surface terrain. Due to this change in 3rd party mod uptake, it has become apparent that there was no solution to enable the stock ground scatter collider meshes through the use of Kopernicus available to the community. This mod aims to provide this solution by providing a small patch to enable these ground scatter collider meshes for the stock ground scatter instances on the stock bodies for Kerbal Space Program. Download Click here to navigate to the GitHub release page: https://github.com/Poodmund/Stock-Scatter-Collider-Enabler-Patch/releases or install through CKAN! How to Install Extract the GameData folder found in the downloadable .zip directly into your Kerbal Space Program install directory. If located correctly, the SSCEP directory should be found at: \Kerbal Space Program\GameData\SSCEP Dependencies The following KSP mod must be installed prior to using the Stock Scatter Collider Enabler Patch mod (ensure that you install the correct version of the dependency for your version of KSP): Kopernicus (depending on KSP version) - https://github.com/Kopernicus/Kopernicus/releases Module Manager - https://forum.kerbalspaceprogram.com/index.php?/topic/50533-* Conflicts Do not use this mod if you are using a different mod that has its own implementations of ground scatter such as Stock Visual Terrain or Spectra. To reiterate, this mod only enables colliders for the stock scatter implementations. Disclaimer This patch may enable the ground scatter collider meshes on bodies for versions of KSP prior to 1.8.0, however, the further back you go the more likely that the ground scatter has been changed since, config wise, by SQUAD in the multitude of updates. I have limited its usage back to 1.3.1 so feel free to use but your milage may vary. I suggest that if you use anything like KSP 1.7.3 and prior that you just use a mod like Stock Visual Terrain instead. Also, this purpose of this mod means you will now collide with terrain scatter... I take no responsibility for your missions being ruined due to the usage of this mod. Changelog v1.0.1 Version bump up to KSP 1.11.99 compatibility v1.0.0 Initial release License The mod is licensed under the GNU General Public License Version 3, 29 June 2007 Thanks Big thanks to @Thomas P. who talked this whole issue through with me over a few hours... I think this is probably the best way to implement this, right? He did the leg work, I'm just the messenger.

Ovok's mean radius is 26,000m and its sphere of influence is specified as 94,000m. Therefore its max theoretical apoapsis is 68,000m... I've just tested this in game with KSP 1.9.1 and the latest pre-release build of Kopernicus 1.9.1-1 and it seems to correlate with what it should be: This was the highest I could get the apoapsis without the orbit becoming parabolic.

I would suggest then there is an issue with your install: https://github.com/Poodmund/Outer-Planets-Mod/blob/master/GameData/OPM/KopernicusConfigs/SarnusMoons/Ovok.cfg#L26

If a specified variant, used in a craft file, doesn't exist it will fall back to using the base variant as specified in the part file (basically the default variant).

Something very odd and bad is happening with the PQS mesh of the body here at the end of the log: Did you say that this absolutely does not happen when Sigma: Dimensions is not installed? With S:D installed on my own test bed I have also found that ground scatter is floating in mid air when it spawns in distant places so there may be some issues here. The first issue, like I mentioned to Nicias on this page above, I cannot really comment without seeing log files so if you could post them itr would be appreciated. With regards to the 2nd issue of the orbit lines jumping, unfortunately thats an inherent issue with orbits with a very large semi-major axis. This is a long-running Kopernicus issue that, at the moment, we have all just lived with for a long time.

If not already, please set your Terrain Detail setting to High and report back with further details. Please also upload your: Kerbal Space Program/KSP.log file and also the contents of your Kerbal Space Program/logs folder.