Poodmund

You might... but please do not do so in this thread. Just to be clear, to anyone who uses this mod on an unsupported version of Kopernicus and reports issues unless requested to do so, please be aware that I am not going to respond to your issue. I'm not being rude by doing so, its just there's nothing that I can do, or will do about these issues.

Yeah, mobile formatting with the WYSIWYG editor sucks. Even when composing a post using the multi-quote feature, you cannot move the quote blocks around and you cannot delete a quote block on mobile by pressing backspace or something sane.

I should well hope not.

Nearly all of it was already enabled prior to this change. I just changed all of the notation of the config nodes to match what Kopernicus outputs by default and also enabled a small few of scatters that didn't have collision enabled (was only a very small amount).

Packaged some changes which may help resolve some of the issues with body surfaces depending on how Kopernicus Continued pushes updates. Outer Planets Mod v2.2.8 - Updated ground scatter notation to align with Kopernicus directly and enable scatter collision mesh interactions. - Resolved unnecessary double spaces in localization strings and replaced tab indentation with spaces in localization file. - Explicitly state PQS materialType for bodies with PQS meshes. - Remove bad characters from Localization strings. https://github.com/Poodmund/Outer-Planets-Mod/releases/latest

I would suggest unpacking the 1.10 game assets, at least all the Texture2D assets, to see exactly what the game supplies with regards to the gas giants/Jool. There are a good handful of assets... off the top of my head, a tileable normal map that displays when close, Jool's scaled space texture, two band maps and a swirl map.

Why bundle a normal map texture for gas giant use if one isn't specified when you could just leverage the vanilla one?

My suggestion is don't use a version of KSP that is unsupported by the mod.

They have no PQS mesh so they definitely have no surface akin to Jool. Are you going to bundle them in your SIMPLEX Resources mod distribution? That would be the preferred method for me.

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.