Jump to content

Galileo's Planet Pack Workshop


JadeOfMaar

Recommended Posts

A dedicated place for collaboration on addons and tweaks that couldn't make it in time for and possibly cannot wait on inclusion into an official release. @Galileo has expressed his willingness to do major uploads whenever necessary to get a completed project out there and avoid the wider fanbase needing to monitor this thread very regularly for updates. This thread exists to keep posts relating to such projects contiguous and not scattered among the regular (mostly casual gameplay and tech support themed) posts in the main GPP thread.

Current Subjects:

Contract Packs

It is widely known by now that GPP breaks many contract mods. Why this happens is because of a handful of reasons:

  1. Mods with the names Sun and Kerbin hardcoded into them will not adapt to Ciro and Gael and will throw exceptions.
  2. Gael is missing certain anomalies like the Pyramids, KSC2 and Island Airfield. This breaks contract mods like GAP which target them.
  3. The different biome set and topology will upset waypoint and biome-based contracts.
  4. The GPP planet found in a given relative position (Niven in place of Eve... Tellumo for Duna) is nothing like the stock planet and will cause false contracts like Eve ocean science where Niven has no ocean.

Along with these, the stock contract system responds oddly, generating Ore requests for Ciro or absurdly early missions to Grannus. Many thanks to everyone who provides feedback and contributes to this list. Here is a preliminary list of contract mods known to be compatible with GPP. It is not absolutely necessary to produce this list but is helpful for those who are looking for it:

Confirmed OK

Pending

  • Field Research
  • Tourism Plus (Seems just fine but is lightly upset by Gael having different biomes to Kerbin. Gael has no Badlands)

Confirmed Broken

 

 

Edited by JadeOfMaar
Link to comment
Share on other sites

12 hours ago, JadeOfMaar said:

In addition to addressing this, provisions will be made so anyone who's up to it can write science for the 20+ other worlds.

Excellent.  I've got a stack of them I've already written for my own game ready to upload! :D 

Link to comment
Share on other sites

@rasta013 I just a linked a google sheet in the OP for inserting science for Gael. The gaps are in Crew Report, EVA Report, Mystery Goo and Science Jr.

I think I should be afraid what kinds of things @CatastrophicFailure would suggest. :D But writing failure events for the parts was the most fun.

Link to comment
Share on other sites

@JadeOfMaar Did a very brief check of the config you posted in the OP for antennas, doesn't seem to work. I hyperedited a probe into Leto orbit with an RA-100 (and great big RTG), immediately lost contact. IIRC range in the VAB was showing a tick under 1Tm in 6.4x. With ResearchBodies installed, I have no idea how far Leto actually is. :D

Link to comment
Share on other sites

@CatastrophicFailure Umm. I think I failed. :( I needed that tested at stock scale. Leto is within 1Tm (at most 610Gm) at stock scale. Its farthest from Gael is 3.9Tm in 6.4x. I got confirmation from @RocketPCGaming in 10x, after he virtually applied an extra 0 to the same code. So I'll sort things out with stock and all the sigma scales.

Link to comment
Share on other sites

Can we discuss the science definitions a little bit?

@Galileo was asking about definitions and I wanted to try and upload some of what I had started writing so he'd at least have part of it for the release he mentioned in the main thread earlier today.  However, when I went back over to the spreadsheet (had only looked at it briefly before) I noticed there are some problems right off the bat.

Let's talk about the Crew Report first.  In the stock game, without using something like Science Revisted Revisted, the crew report does not act the definition we've requested to be written.  It has situationMask = 63 and biomeMask = 7.  This translates into:  InSpaceHigh, InSpaceLow, FlyingHigh and then FlyingLow and SrfLanded by biome type (e.g. GaelFlyingLowMountains or GaelSrfLandedMountains).  Nothing else that is written will get recognized.  It will use the very first InSpaceLow definition on the list every single time no matter how many are written and the same goes for SpaceHigh and FlyingHigh.  The only biome definitions that will get used are the ones for FlyingLow or SrfLanded situations.  EDIT:  Plus, once the experiment is run once, it is never run again and cannot be run again for additional science so any other definition that is there is wasted as well for this reason - Crew Report is a single shot experiment for the above listed situation/biome masks.

Rather than go into all the different experiments we've requested definitions for I'll just say that the above is indicative of many of the other issues I've seen.  We need to have each one of the requested definitions laid out according to the stock definition as defined by biomeType and situationMask.  Otherwise we are asking for a lot definitions that will never be seen.

Also, are we intending on expanding this to all bodies and biomes for GPP?  Right now, only homeworld bodies are being covered by the spreadsheet albeit with the aforementioned problems.

Last but not least, if not solved before this weekend I'll have my own spreadsheet generated with the existing GPP definitions imported and all GPP bodies laid out by biomeType and situationMask for each stock experiment.  It's really not hard just time consuming to get the initial large biome/situation template made... :D 

Edited by rasta013
Link to comment
Share on other sites

5 minutes ago, Galileo said:

I really only care about the Gael system getting complete. Doing ALL 28 bodies is a lot of work and i wouldnt put that on anyone.

Cool.  I'll decide whether I'll take it on myself but at the very least want to make sure that all the definitions we request are the ones we need as well.  If we continue down the path we're on we're adding a bunch for several experiments that will almost assuredly never be seen and as such, becomes wasted effort. 

Link to comment
Share on other sites

2 minutes ago, rasta013 said:

Cool.  I'll decide whether I'll take it on myself but at the very least want to make sure that all the definitions we request are the ones we need as well.  If we continue down the path we're on we're adding a bunch for several experiments that will almost assuredly never be seen and as such, becomes wasted effort. 

Well that's good to know lol

i don't play enough to catch these issues. To bad we can't just use the community science defs and just change them for GPP, they are too specific to the stock game 

Link to comment
Share on other sites

R'OKAY GEORGE!

My wife and I are going to volunteer to take on the development effort to fill out the stock experiment definitions for all GPP bodies, situations and biomes.  I think this will help make the effort a bit easier to coordinate since it is so huge and we don't want to duplicate efforts.  Furthermore, I've got extensive experience writing full definition files so understand the process intimately.  This will mean I can answer questions regarding the definitions, their operation or any problems we may run into with getting them to work properly.  Toying with the science system has been my pet project in KSP from the start.  If you'd rather I didn't do this please let me know, otherwise I'll start getting the pieces pulled together and get you an updated spreadsheet to work with going forward.

 

Link to comment
Share on other sites

16 hours ago, JadeOfMaar said:

@CatastrophicFailure Umm. I think I failed. :( I needed that tested at stock scale. Leto is within 1Tm (at most 610Gm) at stock scale. Its farthest from Gael is 3.9Tm in 6.4x. I got confirmation from @RocketPCGaming in 10x, after he virtually applied an extra 0 to the same code. So I'll sort things out with stock and all the sigma scales.

Hmm. Well, this probably isn't any help, but this is what I was using before and it seemed to work. Haven't actually tested it beyond Tellumo, tho.

// ============================================================================
// Tweak antenna distances
// ============================================================================

@PART[*]:HAS[@MODULE[Antenna]]:NEEDS[FeatureSignal]:FINAL
{
  @MODULE[Antenna]
  {
    @dist *= 6.4
  }
}

 

Link to comment
Share on other sites

@CatastrophicFailure I finally figured out a part that seems to clear things up a lot. "Maximum SMA" in the reference code translates in Gauss' SMA in GPP. I think I need to know at this point how far the stock antenna should be able to reach. I would like to hold it back some and encourage more use of the JX2 Antenna which will then possibly be buffed enough to reach Grannus. You can call an OPM planet if you wish. Their distances are good references.

@Galileo Input?

Edited by JadeOfMaar
not sure how to phrase things atm
Link to comment
Share on other sites

9 minutes ago, JadeOfMaar said:

@CatastrophicFailure I finally figured out a part that seems to clear things up a lot. "Maximum SMA" in the reference code translates in Gauss' SMA in GPP. I think I need to know at this point how far the stock antenna should be able to reach. I would like to hold it back some and encourage more use of the JX2 Antenna which will then hopefully be buffed enough to (almost? maybe surely?) reach Grannus but neither antenna seem too OP. You can call an OPM planet if you wish. Their distances are good references.

@Galileo Input?

I believe Gauss is near where Eeloo is in stock, so stock antenna should at least be able to reach there. I too would like to see JX2 used more BUT my concern is for those that dont use JX2. are we going to force users to use it or will we give them a stock option? or could they just stack a whole bunch?

Link to comment
Share on other sites

@Galileo They don't seem combinable in Kerbalism therefore my fuss over it. On top of that I'm unfortunately trying to make the antenna patch 2-layered: The default setting posted by ShotgunNinja and then the (re)multipliers for Sigma. Maybe I shouldn't be concerned but If I buff the stock antenna for Kerbalism to reach Leto, the JX2 antenna might be able to reach Grannus at its apoapsis which is madness.

Link to comment
Share on other sites

4 minutes ago, JadeOfMaar said:

the JX2 antenna might be able to reach Grannus at its apoapsis which is madness.

Madness?! THIS! IS! Well, you get the idea...

1 minute ago, Galileo said:

well lets make people use the JX2 then. Im ok with that.

Personally, (with Kerbalism) I'd like to keep some limited functionality of "normal" dishes all the way out to Leto, ala New Horizons (not that I'll be getting there any time soon.) I've only glanced over the thread for the JX2 but it seems a bit overkill to have to lug that thing aaaaaallll the way out there for what's going to be a tiny, lean probe in the first place.

Link to comment
Share on other sites

1 minute ago, CatastrophicFailure said:

Madness?! THIS! IS! Well, you get the idea...

Personally, (with Kerbalism) I'd like to keep some limited functionality of "normal" dishes all the way out to Leto, ala New Horizons (not that I'll be getting there any time soon.) I've only glanced over the thread for the JX2 but it seems a bit overkill to have to lug that thing aaaaaallll the way out there for what's going to be a tiny, lean probe in the first place.

That kind of thing works with RemoteTech imo, where signal delay is a thing, or CommNets are turned off and you have infinite signal like in KSP 1.1.x, but this is Sparta Kerbalism where antennae can't be combined, then GPP is akin to a real solar system, not short on outer planets like stock, and then there's the JX2 which came about to answer the problems of imbalance between all the stock antennae for a game with OPM installed.

So I'm looking at buffing the stock antenna to Nero's distance. Then the JX2 can possibly cover a good chunk of the near-periapsis portion of Grannus' orbit. After that is warp drives. :) Of course.....you can always hack your game yourself and get that New Horizons mojo going. :wink: You've shown so much talent setting up the filler Kerbalism config for people, and helping GPP+Rald to work.

Link to comment
Share on other sites

2 minutes ago, JadeOfMaar said:

That kind of thing works with RemoteTech imo, where signal delay is a thing, or CommNets are turned off and you have infinite signal like in KSP 1.1.x, but this is Sparta Kerbalism where antennae can't be combined, then GPP is akin to a real solar system, not short on outer planets like stock, and then there's the JX2 which came about to answer the problems of imbalance between all the stock antennae for a game with OPM installed.

So I'm looking at buffing the stock antenna to Nero's distance. Then the JX2 can possibly cover a good chunk of the near-periapsis portion of Grannus' orbit. After that is warp drives. :) Of course.....you can always hack your game yourself and get that New Horizons mojo going. :wink: You've shown so much talent setting up the filler Kerbalism config for people, and helping GPP+Rald to work.

as soon as you get it done let me know. Im ready for a push!

Link to comment
Share on other sites

45 minutes ago, Galileo said:

as soon as you get it done let me know. Im ready for a push!

Fixed the patches and tested 3.2X as well to ensure that the antenna ranges scale well with all Sigma configs. I still got weak signal at Nero (what I wanted) for stock antenna and predicted narrow but sufficient coverage arc for Grannus with JX2 antenna. All that's necessary is for you to confirm no MM errors then you can go ahead.

Link to comment
Share on other sites

If anyone is playing with a re-scaled system, I have a patch below that should be applied to the re-scale config file that should increase the resolution of the cloud layers when you are up close by scaling the render range of the cloud detail textures to your system re-scale factor.

In your re-scale config file (i.e. 3.2X.cfg or 10X.cfg etc.) at around line 118, you'll see the following lines (I will use the 3.2X.cfg file for reference):

@EVE_CLOUDS:FINAL
{
	@OBJECT,*
	{
		@altitude *= 0.444
	}
}

Inside the EVE_CLOUDS node add in the two following nodes:

@OBJECT
{
	@settings
	{
		@_DetailDist /= #$@SigmaDimensions/Resize$
	}
}
@OBJECT:HAS[@settings:HAS[~_DetailDist[]]]
{
	@settings
	{
		_DetailDist = 2E-06
		@_DetailDist /= #$@SigmaDimensions/Resize$
	}
}

So effectively, you'd end up with the following code:

@EVE_CLOUDS:FINAL
{
	@OBJECT,*
	{
		@altitude *= 0.444
	}
	@OBJECT
    {
        @settings
        {
            @_DetailDist /= #$@SigmaDimensions/Resize$
        }
    }
    @OBJECT:HAS[@settings:HAS[~_DetailDist[]]]
    {
        @settings
        {
            _DetailDist = 2E-06
            @_DetailDist /= #$@SigmaDimensions/Resize$
        }
    }
}

EDIT: Apologies for IPB's code formatting messing up the nesting, the code/text is still fine though.

Edited by Poodmund
Link to comment
Share on other sites

6 hours ago, Poodmund said:

If anyone is playing with a re-scaled system, I have a patch below that should be applied to the re-scale config file that should increase the resolution of the cloud layers when you are up close by scaling the render range of the cloud detail textures to your system re-scale factor.

This is a great little touch, thanx . :D

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...