Jump to content

[1.2] Galileo's Planet Pack (development thread) [v0.9]


Galileo

Recommended Posts

so, I had a bit of time for GN lately and I looked into GPP to see if I could manage to add compatibility.

since you edit/delete stock bodies and you do so at ":AFTER[Kopernicus]" I can't add compatibility for GPP into GN

 

basically what happens is that everybody uses ":AFTER[Kopernicus]" and as a result the cfg in your mod that deletes bodies may interfere with other mods.

There are two possible solutions here, either:

 

Spoiler

1- you add a check to disable the planet deletion when GN is installed 

changing   @Kopernicus:AFTER[Kopernicus]    to     @Kopernicus:AFTER[Kopernicus]:NEEDS[!GalacticNeighborhood]

in the file RemoveStockPlanets.cfg

 

or 

 

2- do everything at a different time (instead of using :AFTER[Kopernicus] you could use your own time-point like :FOR[GPP]

 

the second option is the one that will require you to change most cfgs in your mod, but is also the change that would have more benefits long term

you could use :FOR[GPP] to add planets, :BEFORE[GPP] to make the changes required to prepare the system before you add your planets, and :AFTER[GPP] to apply changes to after all your planets have been added.

 

of course it's your mod, and I don't expect you to care about GN compatibility.

in case you do, feel free to contact me if you need help setting up the cfgs :wink:

 

in any case, if you decide to make some changes for GN compatibility sake, send them to me before release, so I can make sure everything is ok and you can avoid having to hotfix the release :)

Edited by Sigma88
Link to comment
Share on other sites

3 hours ago, Sigma88 said:

so, I had a bit of time for GN lately and I looked into GPP to see if I could manage to add compatibility.

since you edit/delete stock bodies and you do so at ":AFTER[Kopernicus]" I can't add compatibility for GPP into GN

 

basically what happens is that everybody uses ":AFTER[Kopernicus]" and as a result the cfg in your mod that deletes bodies may interfere with other mods.

There are two possible solutions here, either:

 

  Hide contents

1- you add a check to disable the planet deletion when GN is installed 

changing   @Kopernicus:AFTER[Kopernicus]    to     @Kopernicus:AFTER[Kopernicus]:NEEDS[!GalacticNeighborhood]

in the file RemoveStockPlanets.cfg

 

or 

 

2- do everything at a different time (instead of using :AFTER[Kopernicus] you could use your own time-point like :FOR[GPP]

 

the second option is the one that will require you to change most cfgs in your mod, but is also the change that would have more benefits long term

you could use :FOR[GPP] to add planets, :BEFORE[GPP] to make the changes required to prepare the system before you add your planets, and :AFTER[GPP] to apply changes to after all your planets have been added.

 

of course it's your mod, and I don't expect you to care about GN compatibility.

in case you do, feel free to contact me if you need help setting up the cfgs :wink:

 

in any case, if you decide to make some changes for GN compatibility sake, send them to me before release, so I can make sure everything is ok and you can avoid having to hotfix the release :)

Ok I edited the cfgs like this:

All celestial bodies including the sun have :FOR[GPP] 

And the removestockplanet cfg has :BEFORE[GPP] 

I assume this will work if everyone else is using :AFTER

 

 

Does that sound right?  I never understood the FOR AFTER or BEFORE tag in kopernicus.  This helped me quite a bit

 

Edited by Galileo
Link to comment
Share on other sites

1 hour ago, Galileo said:

Ok I edited the cfgs like this:

All celestial bodies including the sun have :FOR[GPP] 

And the removestockplanet cfg has :BEFORE[GPP] 

I assume this will work if everyone else is using :AFTER

 

 

Does that sound right?  I never understood the FOR AFTER or BEFORE tag in kopernicus.  This helped me quite a bit

 

BEFORE / FOR / AFTER have nothing to do with Kopernicus

they are a feature of ModuleManager

basically it works like this:

(spoiler to not annoy ppl with technical stuff)

Spoiler

Module manager reads all the configs and then executes the instruction written in them in a specific order.

if you make a cfg without BEFORE/FOR/AFTER  it will run the cfg at the beginning, using alphabetical order of the folder to choose between multiple cfgs that have no "time point" defined

then it will run in alphabetical order cfgs that have a defined time point

and of course :BEFORE[Mod] runs before :FOR[Mod] which in times run before :AFTER[Mod]

so for each mod you have 3 time points

 

:FOR[XXX] can also be used to define new mods, for example, SigmaDimensions runs at :FOR[SigDim]

this means that you can use :NEEDS[SigDim] to check for the presence of SigmaDimensions even if there are no actual folders called "SigDim" in GameData

by using a specific time point you allow other modders to do stuff before or after your mod, which is always nice

 

in kopernicus everybody uses :AFTER[Kopernicus] but that's completely pointless. there are actually zero reasons to use :AFTER[Kopernicus]

the only thing worse would be if people just used @Kopernicus without any time point defined, which would make the patch run at the start

making it almost impossible to do stuff before / after them

 

but if every planet pack used their own tag it would actually be much better I think.

 

of course most of the times these issues  do not come up, since most planet packs are not designed to go together. untill someone crazy decides to make a galaxy where each planet pack gets its own star :D

 

and of course thank you for making the change!

Link to comment
Share on other sites

14 minutes ago, Sigma88 said:

BEFORE / FOR / AFTER have nothing to do with Kopernicus

they are a feature of ModuleManager

basically it works like this:

(spoiler to not annoy ppl with technical stuff)

  Hide contents

Module manager reads all the configs and then executes the instruction written in them in a specific order.

if you make a cfg without BEFORE/FOR/AFTER  it will run the cfg at the beginning, using alphabetical order of the folder to choose between multiple cfgs that have no "time point" defined

then it will run in alphabetical order cfgs that have a defined time point

and of course :BEFORE[Mod] runs before :FOR[Mod] which in times run before :AFTER[Mod]

so for each mod you have 3 time points

 

:FOR[XXX] can also be used to define new mods, for example, SigmaDimensions runs at :FOR[SigDim]

this means that you can use :NEEDS[SigDim] to check for the presence of SigmaDimensions even if there are no actual folders called "SigDim" in GameData

by using a specific time point you allow other modders to do stuff before or after your mod, which is always nice

 

in kopernicus everybody uses :AFTER[Kopernicus] but that's completely pointless. there are actually zero reasons to use :AFTER[Kopernicus]

the only thing worse would be if people just used @Kopernicus without any time point defined, which would make the patch run at the start

making it almost impossible to do stuff before / after them

 

but if every planet pack used their own tag it would actually be much better I think.

 

of course most of the times these issues  do not come up, since most planet packs are not designed to go together. untill someone crazy decides to make a galaxy where each planet pack gets its own star :D

 

and of course thank you for making the change!

That makes a lot of sense. Thanks! 

Link to comment
Share on other sites

Not to veer too off-topic but these two articles are really worth a read when it comes to managing your config files for your mods:

https://github.com/sarbian/ModuleManager/wiki/Module Manager Syntax

https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook

As Sigma has iterated, by the extensive and thorough use of well written MM syntax, you can make your mod pretty much fully compatible with other mods out there that may have issues with yours. Its why I have banged on at Blackrack for so long about incorporating MM functionality into Scatterer. :D

Anywho, I was watching https://www.twitch.tv/vitalijbeam stream briefly yesterday where he was playing KSP using the Beta of this pack... I couldn't understand anything but it looked damn cool.

Link to comment
Share on other sites

6 hours ago, Galileo said:

Added the Astroid belt between Gael and Tellumo... because we all need more obstacles when trying to reach Tellumo

5J9KWFX.png

80- 100 asteroids at any given time :D

This makes me very happy :D

By the way, does this belt consist primarily of large asteroids, like the belt between Mars and Jupiter? 

Link to comment
Share on other sites

Just now, kraden said:

This makes me very happy :D

By the way, does this belt consist primarily of large asteroids, like the belt between Mars and Jupiter? 

They will vary from very small to very huge lol for lack of better words

Link to comment
Share on other sites

Just now, MaxL_1023 said:

Would it be possible to add the ability to focus view on Lili when in Tellurmo's or Lili's SOI? It is hard to monitor your orbit or use map view when you are stuck centered on the primary.

yeah im changing it when i release 1.0 

 

Link to comment
Share on other sites

On 11/14/2016 at 8:41 PM, kraden said:

I think it'd be cool. I am a fan of realism though too (as long as it doesn't keep the game from being fun :wink:). With all of the other cool aspects of this planet pack,  I think it'd fit right in.

We've made sure of that. Realism has its boundaries. :wink:

Link to comment
Share on other sites

Well then. Lili must be a very strongly held together piece of rock/metal. Roche lobes are bad enough - super-rotation is a whole new example of KSP insanity. I wonder if a claw would let a lander grip a planet, or does it have to be an asteroid?

(If this is a bug then the rotation period would need to be about 4 times longer to avoid issues, if intentional than please release a config to texture the surface as a disco ball for optimal Tellurmo High-G dance parties. )

Link to comment
Share on other sites

I will probably just have to jetpack down for the surface sample - I should be able to stay on the ground long enough to plant a flag especially if I pick a spot where the ground slopes "downhill."

Returning from Tellurmo however might be a little sketchy. I suspect I would need either a spaceplane or a balloon, as I am not sure how well rocket engines would perform at 10 atmospheres. The rest of the planets seem fairly easy in comparison, except for that big moon of Gauss which still isn't as bad pressure-wise. 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...