[1.12.1] JNSQ [0.10.0] [23 Sept 2021]

[OhioBob]

4 hours ago, Snark said:

Out of curiosity, though... I notice that when I start a new career, it's just before sunset at KSC, rather than being noon as in stock.  Was just wondering, is that by design, or just an accident?  (I've always found it convenient that new games start at midday, so that there's daylight available for the first few missions.)

As far as I know, it's just random chance.  Galileo made the map, picked a good spot for KSC, and that's what it came out to.  I don't like the game starting at sunset either, but I'm not fond of the options for fixing it.  One option would be to offset the textures to place KSC further west, but it's too late for that (it would mess too much up).  Another option would be to change the initial rotation.  But if we did that, then universal time would be out of sync with the planet's rotation.  Right now 0 UT occurs when it's midnight on the prime meridian (as it is in real life).  Of course we could rotate the planet 90 degrees and just say that Kerbals define 0 UT as sunset on the prime meridian.  (I guess there is no requirement that Kerbals do it the same way that we do.)  That would make it approximately noon at KSC when the game starts.

 

Edited July 23, 2019 by OhioBob

[Starwaster]

16 minutes ago, OhioBob said:

As far as I know, it's just random chance.  Galileo made the map, picked a good spot for KSC, and that's what it came out to.  I don't like the game starting at sunset either, but I'm not fond of the options for fixing it.  One option would be to offset the textures to place KSC further west, but it's too late for that (it would mess too much up).  Another option would be to change the initial rotation.  But if we did that, then universal time would be out of sync with the planet's rotation.  Right now 0 UT occurs when it's midnight on the prime meridian (as it is in real life).  Of course we could rotate the planet 90 degrees and just say that Kerbals define 0 UT as sunset on the prime meridian.  (I guess there is no requirement that Kerbals do it the same way that we do.)  That would make it approximately noon at KSC when the game starts.

 

So change the epoch

[Tyko]

3 hours ago, OhioBob said:

As far as I know, it's just random chance.  Galileo made the map, picked a good spot for KSC, and that's what it came out to.  I don't like the game starting at sunset either, but I'm not fond of the options for fixing it.  One option would be to offset the textures to place KSC further west, but it's too late for that (it would mess too much up).  Another option would be to change the initial rotation.  But if we did that, then universal time would be out of sync with the planet's rotation.  Right now 0 UT occurs when it's midnight on the prime meridian (as it is in real life).  Of course we could rotate the planet 90 degrees and just say that Kerbals define 0 UT as sunset on the prime meridian.  (I guess there is no requirement that Kerbals do it the same way that we do.)  That would make it approximately noon at KSC when the game starts.

 

I love that it starts at sunset. With the full set of recommended graphics mods sunset looks amazing. Sure you could change it, but players can also just enjoy the view for a moment then click the "move to next morning" button

[Snark]

9 hours ago, Tyko said:

I love that it starts at sunset. With the full set of recommended graphics mods sunset looks amazing.

Sure, there's that.  I run graphics mods, myself.  But if I had to pick one, I'd prefer sunrise, not sunset.  Because then I get all the eye candy and I have plenty of daylight.

9 hours ago, Tyko said:

players can also just enjoy the view for a moment then click the "move to next morning" button

Sure, it's no showstopper.  And it only affects the very first day, anyway.

Perhaps it's not something that would bother most players.  For me?  Maybe I'm an oddball, but I have an OCD hang-up about the kerbal clock & calendar.  It's "real" to me when I'm playing, probably the most "implicit roleplay" thing I do in KSP.  I hate wasting the kerbals' time, and no matter what I do, I always have a "personal achievement" metric running in the back of my mind:  for any given task, try to get it done in the least amount of kerbal time.

So for me, the start of a new career is always a precious time (those first few missions when the career is "fresh").  That's when missions last minutes or hours, not weeks / months / years.  So I guess I never realized I was doing this before... but "how much do I get done on the first day" has been a thing for me.  So I hate timewarping for multiple hours until I head Munwards.

Perhaps that's just me, in which case all of this is silly.    It's certainly not any kind of showstopper, or anything that would prevent me from using what looks like an amazing mod.  And after the first day of a new career it's going to be completely moot, anyway.  Was just curious about the reasons, is all.

[OhioBob]

On ‎7‎/‎23‎/‎2019 at 11:02 AM, Snark said:

Maybe I'm an oddball, but I have an OCD hang-up about the kerbal clock & calendar.

So am I, which is why I haven't done anything to change it.  I don't like the game starting at sunset, but I'd be even more put off if 0 UT didn't occur at midnight on the prime meridian.  KSC is located at 91.8 W, so when the game starts at 0 UT, it's just before sunset at KSC, as it should be.  Moving KSC is not an option at this point.  Maybe an alternative would be to start the game at a different time of day.  For instance, if the game started at 9:00 UT on Day 1, then it would be about noon at KSC.  (Or if it started at 6:00, then it would be just a few minutes before sunrise at KSC.)  I'd have to study it, but I think it might be possible to change the start time using Kronometer.

(edit)  I think I like the idea of starting at 6:00 UT.  That way the player gets treated to a nice sunrise just as the game begins, and then he has a full day of sunlight ahead of him to perform the first day's activities.  I'll have to see if I can make it work.  I'd have to change both the clock display and the initial rotation.  It could mess with some saves, however.

Edited July 25, 2019 by OhioBob

[Barzon]

why not just move the prime meridian?

[OhioBob]

1 minute ago, Barzon Kerman said:

why not just move the prime meridian?

That would require offsetting all the textures, and it's too late for that.  We're committed to what we currently have as far as the textures and terrain are concerned. 

[OhioBob]

13 hours ago, Starwaster said:

So change the epoch

That's effectively the same as changing the initial rotation.  It would put universal time out of sync with the solar day (unless the initial rotation were changed to compensate, and then we're right back where we started).  And it would have save breaking consequences because it would change Kerbin's starting position in its orbit.

Edited July 23, 2019 by OhioBob

[Stone Blue]

37 minutes ago, OhioBob said:

  I'd have to study it, but I think it might be possible to change the start time using Kronometer.

(edit)  I think I like the idea of starting at 6:00 UT.  That way the player gets treated to a nice sunrise just as the game begins, and then he has full day a sunlight ahead of him to perform the first day's activities.  I'll have to see if I can make it work.  I'd have to change both the clock display and the initial rotation.  It could mess with some saves, however.

So, would this be a hardcoded absolute, or would there be a setting or settings file <or kronometer>, that users could edit/use to change startup time as they wished?

[Snark]

48 minutes ago, OhioBob said:

I don't like the game starting at sunset, but I'd be even more put off if 0 UT didn't occur at midnight on the prime meridian.

Yah, different people are into different things. 

For example, I can totally see how that would bug you... on the other hand, it doesn't bug me at all, even slightly, because I've been playing KSP for five years and to this day I still have not even the foggiest inkling of what longitude KSC is at.  It's simply not a thing, for me.  Longitude simply isn't relevant to my gameplay and I don't even notice it.

In my own KSP universe, any statement of the form "But then UT would be <any assertion at all>" simply isn't a thing. 

To me, UT in KSP isn't a global time standard like it is on Earth.  It's simply a measure of "how much time has elapsed since I started this career".  I don't have any notion of it being tied to any geographic location.

Put another way, to me, UT in KSP isn't a timestamp, it's a stopwatch.

[Superfluous J]

21 minutes ago, Snark said:

To me, UT in KSP isn't a global time standard like it is on Earth.  It's simply a measure of "how much time has elapsed since I started this career".  I don't have any notion of it being tied to any geographic location.

I'm the same. I remember about 5 years ago checking via timewarp if the sun rose at KSC at different times throughout the year. I was curious if a Kerbal day was siderial or solar. Turns out it was siderial, which I guess makes sense for them as they're so obsessed with space. From that moment on, I decided "what time is it?" literally didn't matter for surface operations. All it mattered for was encounters and windows.

I believe that the siderial/solar thing was changed. Perhaps in 1.0. I don't know. I've never bothered to recheck.

Edited July 23, 2019 by 5thHorseman

[OhioBob]

1 hour ago, Snark said:

For example, I can totally see how that would bug you... on the other hand, it doesn't bug me at all, even slightly

My inner astronomer doesn't like things like that not being correct.  Something else I did in JNSQ was to make sure all the tidally locked moons have their prime meridian facing the planet.  It's a little thing that most people wouldn't notice, but to me it's important.  That's the way it is in the real world, so that's the way it is in JNSQ.

In GPP we took a different approach with the clock.  It gives the local time at KSC.  So 0:00 is midnight at KSC, 3:00 is local noon, etc.  Of course I would have liked to change it from reading "UT" to something like "LST" (local standard time), but we never made that work.  For JNSQ I kept it universal time.
 

1 hour ago, Stone Blue said:

So, would this be a hardcoded absolute, or would there be a setting or settings file <or kronometer>, that users could edit/use to change startup time as they wished?

At this point it's just an idea, I'm not sure I'm going to do it.  But if I do implement it, the settings would be in Kronometer.cfg.  The end user could edit the settings (either directly or via a MM patch), provided they know what they're doing.
 

43 minutes ago, 5thHorseman said:

I believe that the siderial/solar thing was changed. Perhaps in 1.0. I don't know. I've never bothered to recheck.

It's been changed.  (Stock) Kerbin now has a 6-hour solar day.  Sunrise and sunset should occur at the same time every day.
 

Edited July 23, 2019 by OhioBob

[Snark]

16 minutes ago, OhioBob said:

My inner astronomer doesn't like things like that not being correct.

I totally get that.

It's just a question of who you want to be your target audience:  astronomers?  or people who care about when it's daylight at KSC?

I would contend that the latter vastly outnumbers the former.  On the other hand, speaking as a modder myself, I'm totally on board with this ain't a democracy (nor should it be)-- the prime directive of mod design is that the author has to be happy with it, first and foremost.

So if the folks working on JNSQ like it this way, that's all that matters, really. 

(And it's not that big of a deal to me, I'm still gonna enjoy the heck out of this mod.  Sorry that this topic seems to have derailed the thread to such an extent-- when I mentioned it, I didn't expect so much debate to spring up.  I've said my piece, so I'll pipe down on this topic now.)

[Brigadier]

1 hour ago, Snark said:

(And it's not that big of a deal to me, I'm still gonna enjoy the heck out of this mod.  Sorry that this topic seems to have derailed the thread to such an extent-- when I mentioned it, I didn't expect so much debate to spring up.  I've said my piece, so I'll pipe down on this topic now.)

LOL, a self-moderating moderator (eventually)

[Ericwi]

Do Scanning Arm's work with JNSQ? I can ram into the trees but not scan them.

https://ibb.co/9VWQrCc

[Galileo]

1 minute ago, Ericwi said:

Do Scanning Arm's work with JNSQ? I can ram into the trees but not scan them.

https://ibb.co/9VWQrCc

 

[Snark]

Apologies if this has already been asked before, but... I'm currently in the Minmus Highlands, and came across a BG-style scatter on it (a big, potato-shaped boulder, perhaps 10 meters across, has a collider) that's floating several meters above the surface.

I can land on it and stand there, looks kinda neat but I suspect was not intentional. 

Known issue?

(I'm at 4d 43' 50" N, 147d 39' 42" W, if that is helpful or relevant).

[4x4cheesecake]

Just now, Snark said:

Apologies if this has already been asked before, but... I'm currently in the Minmus Highlands, and came across a BG-style scatter on it (a big, potato-shaped boulder, perhaps 10 meters across, has a collider) that's floating several meters above the surface.

I can land on it and stand there, looks kinda neat but I suspect was not intentional. 

Known issue?

It's probably related to the terrain detail settings. If these are not set to "high" (or JNSQ_High? not sure though), a few visual issues will appear. Probably worth a try if different settings will affect the levitating bolder

[kerbnub]

So I've been loving the mod, and was kind of low-key wondering how managed to make the moons so much more realistic looking than stock and still interesting on the ground when I possibly stumbled across the answer. When landing, I noticed that the textures used when farther away actually don't correspond that well to the actual terrain on the ground. This is particularly jarring if zoomed out and moving the camera, the transition between the layers is quite obvious.

Here's what I mean (high terrain detail); I just needed to change the camera angle a tiny bit to make it clear:

With this in mind, I have two questions:

1. Is this working as intended? I want to make sure I'm not looking at something broken at my end first, but I could imagine it's an intentional compromise. If the actual terrain was as flat as it appears in the far view, it would probably be pretty boring to explore. But it simply looked like the near view, then it would be pretty ugly from a distance. Did you guys decide to sacrifice consistency for beauty at both ends?

2. Is this actually so different from stock? Did I just discover something everyone know already? I know stock uses at least roughly the same system, is it just not as obvious because the difference in quality is lower?

It's not a huge deal and I'll enjoy the hell out of JNSQ either way, but it kind of blew my mind and I'm just curious.

[Galileo]

@kerbnub we use a perfectly round mesh in scaled space for most bodies. That’s why it looks flat. Works as intended. It gives the bodies the look of being bigger than the actually are. I’m not of a fan of the cartoonish, deformed look of stock sized bodies. While the transition can look a bit odd at times, I think it’s alright. 

Edited July 25, 2019 by Galileo

[Jognt]

A (probable) fix for the (probable) bug in Kopernicus has been posted over in the Kopernicus thread! Crossposting it here because it may be a good idea to incorporate it into JNSQ until the bug can be properly squished!

The (probable) bug is excessive garbage creation and severely reduced performance on bodies like Mun when ROCs and/or Terrain Scatter is enabled. Garbage creation per frame is in the 10-20MB per frame according to MemGraph and the framerate is reported as 12-25 but feels and looks more like 2 seconds per frame with Kerbal walking animations consisting of basically 2 frames of 'standing on left leg' and 'standing on right leg'.

An example of the bug at its worst can be observed here https://youtu.be/znriOxMEExA?t=518

(It should bring you to the right point in the video, 8:38, to witness the performance shift)

See the below posts for information into what in the code causes this (4x4's post) and what helps to remedy it (SkyRex's post)

 

Edited July 25, 2019 by Jognt
Added detailed description

[Snark]

23 minutes ago, Jognt said:

A (probable) fix for the (probable) bug in Kopernicus

For those of us who don't necessarily have full context, could you mention briefly what "the" bug in Kopernicus may be, and what gameplay consequences it's causing?  Would be helpful.

 

Also... I'm running into a bug, but it's not clear to me where the bug is, was wondering whether anyone else is seeing it.

• The situation:  I've just scanned Mun and Minmus for resources with the orbital scanner.  First I did Minmus, then the Mun.  I haven't been to any other planets yet.
• The trigger:  It appears to be scanning the Mun for resources that set off the bug.  I don't know whether it's because it's the Mun per se, or whether it's because it's the second one I scanned, or what.  All I know is that the problem started right after I scanned.
• The symptom:  Any time I try to select the Mun in planetarium view (either in the tracking station or in map view while in flight), it generates a NullReferenceException and the resources-overlay UI is either empty or the button to show it is missing entirely.
• Workaround:  I don't know of any.  Saving and re-loading the game doesn't solve the problem, so as far as I can tell, my career save is borked and I have to just avoid the Mun for the rest of this career.

Here's the error that's getting logged when the exception happens:

[ERR 11:22:44.191] Exception handling event onPlanetariumTargetChange in class KnowledgeBase:System.NullReferenceException: Object reference not set to an instance of an object
  at ResourceMap.GetResourceItemList (HarvestTypes harvest, .CelestialBody body) [0x00000] in <filename unknown>:0 
  at KSP.UI.Screens.KbApp_PlanetResources.CreateResourceList () [0x00000] in <filename unknown>:0 
  at KSP.UI.Screens.KbApp_PlanetResources.ActivateApp (.MapObject target) [0x00000] in <filename unknown>:0 
  at KSP.UI.Screens.KnowledgeBase.ActivateApps (KbTargetType targetType, .MapObject target) [0x00000] in <filename unknown>:0 
  at KSP.UI.Screens.KnowledgeBase.OnMapFocusChange (.MapObject target) [0x00000] in <filename unknown>:0 
  at EventData`1[MapObject].Fire (.MapObject data) [0x00000] in <filename unknown>:0 

[EXC 11:22:44.193] NullReferenceException: Object reference not set to an instance of an object
	ResourceMap.GetResourceItemList (HarvestTypes harvest, .CelestialBody body)
	KSP.UI.Screens.KbApp_PlanetResources.CreateResourceList ()
	KSP.UI.Screens.KbApp_PlanetResources.ActivateApp (.MapObject target)
	KSP.UI.Screens.KnowledgeBase.ActivateApps (KbTargetType targetType, .MapObject target)
	KSP.UI.Screens.KnowledgeBase.OnMapFocusChange (.MapObject target)
	EventData`1[MapObject].Fire (.MapObject data)
	UnityEngine.Debug:LogException(Exception)
	EventData`1:Fire(MapObject)
	PlanetariumCamera:SetTarget(MapObject)
	KSP.UI.Screens.SpaceTracking:SetVessel(Vessel, Boolean)
	KSP.UI.Screens.SpaceTracking:OnSceneLoadRequested(GameScenes)
	EventData`1:Fire(GameScenes)
	HighLogic:SetLoadSceneEventsAndFlags(GameScenes, Boolean)
	HighLogic:LoadScene(GameScenes)
	KSP.UI.Screens.SpaceTracking:BtnOnClick_LeaveTrackingStation()
	UnityEngine.EventSystems.EventSystem:Update()

 

I don't know whether this is a problem with, 1. the stock game, or 2. Kopernicus, or 3. JNSQ itself.  I'm guessing it's not the stock game, since I've scanned resources in a non-Kopernicus career in KSP 1.7.3 with no problems.  However, this is the first Kopernicus-based career I've tried playing since 1.7.1, so I don't know whether this is a Kopernicus thing or a JNSQ thing.

The reason it occurs to me to wonder whether JNSQ may be involved is that I gather the mod does something special with resources, so perhaps there's something involved there?  Maybe there's some code somewhere that's leaving a list member as null, rather than initializing it to an empty list as consumers expect, or something?

Has anyone else run into anything like this?  Conversely, has anyone successfully scanned both Minmus and Mun for resources with no problems?

[Jognt]

11 minutes ago, Snark said:

For those of us who don't necessarily have full context, could you mention briefly what "the" bug in Kopernicus may be, and what gameplay consequences it's causing?  Would be helpful.

Good point. I've updated my above comment with a (more?) detailed description. If I missed something and you'd like to know more, feel free to ask. (or skim the last few kopernicus thread pages )

Edit: Since I haven't actually played KSP since asking about this stutter problem here a while back I have no experience with Mun scanning/errors, but I'll probably do a backup of my save before I send that scanning probe that was sitting on the pad.. Hopefully someone else can help you with the problem you encountered

Edit 2:

Quote

The reason it occurs to me to wonder whether JNSQ may be involved is that I gather the mod does something special with resources

JNSQ is bundled with Rational Realistic Resources (mod) that is basically a remake of the entire resource system. I've read a few pages back that the bundled version is several commits behind the 'standalone' version though, so maybe updating RR from it's own repo will fix it? (or remove it alltogether if the stock resource system suits your needs)

 

Edited July 25, 2019 by Jognt

[Snark]

25 minutes ago, Jognt said:

JNSQ is bundled with Rational Realistic Resources (mod) that is basically a remake of the entire resource system. I've read a few pages back that the bundled version is several commits behind the 'standalone' version though, so maybe updating RR from it's own repo will fix it? (or remove it alltogether if the stock resource system suits your needs)

Thanks, that's helpful to know!

If possible, I'd like to try playing with RR enabled, simply because I gather that that's playing JNSQ "as the authors intended", i.e. overall game balance of the system with the new bodies and so forth.  I trust their design skills, and would like to simply place myself in their hands and experience the solar system as their imagination has constructed. 

Besides... part of being a player using a mod like this one that's still a WIP is to help flush out any bugs that are there in development, and I suppose I'm probably a more helpful guinea pig if I'm using the full mod.

[Jognt]

2 minutes ago, Snark said:

Thanks, that's helpful to know!

If possible, I'd like to try playing with RR enabled, simply because I gather that that's playing JNSQ "as the authors intended", i.e. overall game balance of the system with the new bodies and so forth.  I trust their design skills, and would like to simply place myself in their hands and experience the solar system as their imagination has constructed. 

Besides... part of being a player using a mod like this one that's still a WIP is to help flush out any bugs that are there in development, and I suppose I'm probably a more helpful guinea pig if I'm using the full mod.

 

Good point.. I initially removed RR because I wanted to tackle one 'new' thing at a time. But now that I'm used to JNSQ I guess I have room to tackle a new 'new' thing so I think I'll reinstall it

Edit: Oh, and you're welcome.

Edited July 25, 2019 by Jognt