[1.8.1-1] [PLEASE FORK ME] Kopernicus & KittopiaTech

[Galileo]

5 hours ago, Sigma88 said:

if they are PQSCity mods you cannot move them with kopernicus.

unless they are movable by default in KSP (I haven't checked) you will not be able to move them.

 

(well, you could move them if you used a dll, but I doubt I could be able to help with that)

So it wouldn't be like moving the SpaceCenter?  If I cannot move them,  could I at least remove them?  I have a second planet that uses a Kerbin template. It also has the CommNetDishes but I don't want it to. 

Moving them would be nice though.  The dishes being on the bottom of the ocean in RSS is likely to bother some people lol.  The functionality is there so I suppose it's not all that bad

Edited October 24, 2016 by Galileo

[Sigma88]

2 hours ago, Galileo said:

So it wouldn't be like moving the SpaceCenter?  If I cannot move them,  could I at least remove them?  I have a second planet that uses a Kerbin template. It also has the CommNetDishes but I don't want it to. 

Moving them would be nice though.  The dishes being on the bottom of the ocean in RSS is likely to bother some people lol.  The functionality is there so I suppose it's not all that bad

I think you can remove them yes

Try using removePQSMods = PQSCity

[CaptRobau]

@Thomas P.

We noticed an issue with HyperEdit 1.5.3 and Kopernicus latest. New bodies freak out when both are installed. My way to reproduce it:

Quote

This is how I could reproduce it just now.

1. Have nothing installed but Kopernicus 1.2.0-2, Outer Planets Mod 1.2 and HyperEdit 1.5.3
2. Load up a sandbox save
3. Launch or goto a vessel on the pad
4. Warp this vessel to Hale (15k orbit is safe)

For good measure, I ran the Windows 64-bit version of KSP on Steam.

 

 

And the HyperEdit dev did some testing:

Quote

 

I was able to confirm this.  It goes away when one zooms out far enough from the body.  It also goes away permanently when one switches to another scene and back.

This appears to be related to the graphics in the Outer Planets mod and/or Kopernicus, as we've not had any reports of this in a stock install.  I recommend you ask one or both of them if they have any insight.

Additionally, the fact that it goes away after reloading the scene, makes me wonder if there may be some way to address it in HyperEdit, but I have no idea how.  Let's hear what the other mod's folks have to say.

Hale graphics glitch:

 

 

 

[Thomas P.]

To be honest, I would blame the rapid loading of the planets here. This is nothing the stock game, and its planets were designed for.

I have no real idea how I could fix this in Kopernicus

[Galileo]

4 hours ago, Sigma88 said:

I think you can remove them yes

Try using removePQSMods = PQSCity

Unfortunately I already had that in my template and it didn't work I'm guessing. Man,  that is poopy. 

[Beetlecat]

Say -- is that tiny "offset" issue with craft and waypoint markers still present?

I remember it being a thing with waypoint contracts, etc. and craft in the space center scene would appear a few dozen meters to the north, for instance.

I've just fired up a relatively new game with Kopernicus, and noticed a recently launched (but not moved from the end of the runway yet) craft appeared to be way off into the grass. Switching to it revealed that it was just where I left it on the runway. Switching back to the Space Center view revealed it in the right spot again.

Weird.

[Streetwind]

I'm curious about the "reparenting Kerbin causes issues" thing. Reading back through the thread a bit, it seems to still be an issue with the latest version.

What actually causes that bug? Is it something with the layered camera scenes KSP uses?
And, is this bug fixable (if whatever development time that requires were actually available), or are we stuck with it until stock KSP makes a change?

Edited October 25, 2016 by Streetwind

[Sigma88]

40 minutes ago, Streetwind said:

I'm curious about the "reparenting Kerbin causes issues" thing. Reading back through the thread a bit, it seems to still be an issue with the latest version.

What actually causes that bug? Is it something with the layered camera scenes KSP uses?
And, is this bug fixable (if whatever development time that requires were actually available), or are we stuck with it until stock KSP makes a change?

did anyone actually test the issue in 1.2? I was under the impression that this bug would have been solved with this patch.

but I haven't looked into it yet

Edited October 25, 2016 by Sigma88

[Streetwind]

I didn't test it - I'm not near a computer capable of running KSP right now, sadly. But I've seen more than one post in the last couple pages advising people that this issue exists, and the changelog doesn't mention a fix. In fact, the opening post still has the warning about this bug right below the changelog.

But if it was fixed, that would be terrific news

[Sigma88]

27 minutes ago, Streetwind said:

I didn't test it - I'm not near a computer capable of running KSP right now, sadly. But I've seen more than one post in the last couple pages advising people that this issue exists, and the changelog doesn't mention a fix. In fact, the opening post still has the warning about this bug right below the changelog.

But if it was fixed, that would be terrific news

as far as I can tell, the bug was due to a quirk in KSP rather than Kopernicus. KSP 1.2 shoul have fixed that "issue" and so now kopernicus should not cause that reparenting issue.

warnings are still there most likely because noone got around to test and confirm the issue was completely solved

[Streetwind]

Well, I certainly know what I'll be testing tonight when I get home, then!

[Streetwind]

Okay, back home, and testing.

Because I have no idea how to use Kopernicus properly, I downloaded New Horizons for this. Only four things installed: Module Manager, ModularFlightIntegrator, Kopernicus, and New Horizons. All in their latest versions.

The result? Well... it's kind of... worse than before. In 1.1.3 I at least got to see the space center screen, even if the sun was stuck unmoving. Right now? Black screen at best, or this at worst. I could still enter buildings and such via the interface buttons, so I was able to launch a KerbalX. As soon as I got into the flight scene, everything worked perfectly, no glitches there. But that was already the case before.

After putting the rocket into a 85x85 km orbit, I went back to the black space center screen and timewarped for a month. Result: spacecraft ejected into an random, eccentric solar orbit.

 

Space center bug? Check! Unstable orbits bug? Check!

Now mind you, New Horizons hasn't had any work done on it for 1.2 compatibility, so it could be possible that this can be fixed on KillAshley's end via some newly introduced feature or other but... right now it looks like the same issues as before still exist, except a bit worse.

Edited October 25, 2016 by Streetwind

[Sigma88]

yeah, kerbin reparenting has some work needed before it is viable. should be doable tho

[barfing_skull]

Hi all,

I'm still having that problem with barred textures with some planet packs.  Outer Planets has it, but Extrasolar Planets does not.

 

EDIT: Just a note that things seemed to work fine up through 1.1.2 (OPM was fine), but broke in 1.1.3 and now 1.2.

 

Linux Mint 17.1, KSP 1.2.  I remember hearing it might be something with the graphics drivers, and not sure if this is a common issue?  I had to set "useOnDemand = false" to get some celestial bodies to show up at all, in both mods.

 

 

I'm wondering if it's a PNG vs. DDS thing?  Both mods have files of both types, but I'm not exactly sure how they're being used in each case.

Not sure if it would help to try and convert the .dds to .png, though I wouldn't know how to tell the mod to use the converted png instead.

There are some [WRN] in the logs, that only look mildly suspicious, as they happen for both bodies with the issue and those without.

I know debugging issues like this can be difficult when developers don't have the same environment to reproduce the issues, so if there's anything else I could try/provide that might be helpful, I'd be happy to do so.

Any other ideas?

Thanks again for the time and effort put into these mods.

Cheers,

-BS

Edited October 26, 2016 by barfing_skull

[Galileo]

15 minutes ago, barfing_skull said:

Hi all,

I'm still having that problem with barred textures with some planet packs.  Outer Planets has it, but Extrasolar Planets does not.

 

Linux Mint 17.1, KSP 1.2.  I remember hearing it might be something with the graphics drivers, and not sure if this is a common issue?  I had to set "useOnDemand = false" to get some celestial bodies to show up at all, in both mods.

 

 

I'm wondering if it's a PNG vs. DDS thing?  Both mods have files of both types, but I'm not exactly sure how they're being used in each case.

Not sure if it would help to try and convert the .dds to .png, though I wouldn't know how to tell the mod to use the converted png instead.

There are some [WRN] in the logs, that only look mildly suspicious, as they happen for both bodies with the issue and those without.

I know debugging issues like this can be difficult when developers don't have the same environment to reproduce the issues, so if there's anything else I could try/provide that might be helpful, I'd be happy to do so.

Any other ideas?

Thanks again for the time and effort put into these mods.

Cheers,

-BS

I fixed this for linux and mac user in SVT by switching all my Color maps, Normal Maps and Height Maps to PNG. Something about OpenGL doesnt play nice with .dds textures.

to tell the mod to use the new file extension, you will have to go into each planet cfg and change each file directory that ends in .dds to .png 

[barfing_skull]

2 minutes ago, Galileo said:

I fixed this for linux and mac user in SVT by switching all my Color maps, Normal Maps and Height Maps to PNG. Something about OpenGL doesnt play nice with .dds textures.

to tell the mod to use the new file extension, you will have to go into each planet cfg and change each file directory that ends in .dds to .png 

Hmmm....sounds like a job for a shell or Perl script or something.  ImageMagick will apparently do the conversion on the command line.  If there's not something like that out there, I might look at creating one.

Cheers,

-BS

[Streetwind]

11 hours ago, Sigma88 said:

yeah, kerbin reparenting has some work needed before it is viable. should be doable tho

Okay then. Who do I need to bribe, and with how much?

*eyes @Thomas P. and his donation button*

[barfing_skull]

7 hours ago, barfing_skull said:

Hmmm....sounds like a job for a shell or Perl script or something.  ImageMagick will apparently do the conversion on the command line.  If there's not something like that out there, I might look at creating one.

Cheers,

-BS

This actually worked pretty well, I scripted all the conversion and replacing strings in the .cfg files.  Things are definitely better, they look perfect from orbit and right on the ground, however, there's one glitch....

The height maps for OPM wouldn't convert.  Normal and color worked fine.

convert.im6: image type not supported `./GameData/OPM/KopernicusConfigs/UrlumMoons/PluginData/Polta_height.dds' @ error/dds.c/ReadDDSImage/346.
convert.im6: no images defined `./GameData/OPM/KopernicusConfigs/UrlumMoons/PluginData/Polta_height.png' @ error/convert.c/ConvertImageCommand/3044.
 

I'm guessing the height maps are in some format that convert doesn't understand, might be a deprecated DDS format.  What did you use to convert the height maps?  Would that cause the mid-altitude issues like the below?

 

Cheers,

-BS

 

[Galileo]

2 minutes ago, barfing_skull said:

This actually worked pretty well, I scripted all the conversion and replacing strings in the .cfg files.  Things are definitely better, they look perfect from orbit and right on the ground, however, there's one glitch....

The height maps for OPM wouldn't convert.  Normal and color worked fine.

convert.im6: image type not supported `./GameData/OPM/KopernicusConfigs/UrlumMoons/PluginData/Polta_height.dds' @ error/dds.c/ReadDDSImage/346.
convert.im6: no images defined `./GameData/OPM/KopernicusConfigs/UrlumMoons/PluginData/Polta_height.png' @ error/convert.c/ConvertImageCommand/3044.
 

I'm guessing the height maps are in some format that convert doesn't understand, might be a deprecated DDS format.  What did you use to convert the height maps?  Would that cause the mid-altitude issues like the below?

 

Cheers,

-BS

 

No that is caused by the rapid loading of Celestial bodies with hyperedit. I don't think you actually have to convert the heightmaps. I use photoshop to batch convert all my photos

[barfing_skull]

2 hours ago, Galileo said:

No that is caused by the rapid loading of Celestial bodies with hyperedit. I don't think you actually have to convert the heightmaps. I use photoshop to batch convert all my photos

Ah, so it is.  Needed HyperEdit to test things out.  Looks like just going back to the Tracking Station and reloading the craft does the trick.

I did end up writing a short Perl script do make the changes, along with the ImageMagick 'convert' utility.  My Perl is rusty.  Dunno if this would be useful overall, or if planet packs might have or include a Linux/Mac friendly version that uses png instead of dds?

Any idea what the impetus behind using dds in the first place is?

Cheers,

-BS

 

[Galileo]

1 minute ago, barfing_skull said:

Ah, so it is.  Needed HyperEdit to test things out.  Looks like just going back to the Tracking Station and reloading the craft does the trick.

I did end up writing a short Perl script do make the changes, along with the ImageMagick 'convert' utility.  My Perl is rusty.  Dunno if this would be useful overall, or if planet packs might have or include a Linux/Mac friendly version that uses png instead of dds?

Any idea what the impetus behind using dds in the first place is?

Cheers,

-BS

 

I don't know what the issue is.  It took me forever to figure it out because I don't use Macs or Linux.  I made 2 versions for my planet pack.  One for macs and Linux and one for Windows.  The only major downside of having to set everything as Png is the amount of ram they use. 

[komodo]

I'd be curious to find if it is a Linux/Mac thing, or an OpenGL thing: does the same issue happen on Windows when forced to OpenGL?

(I'd have used a sed regex, but to each their own  )

[Galileo]

11 minutes ago, komodo said:

I'd be curious to find if it is a Linux/Mac thing, or an OpenGL thing: does the same issue happen on Windows when forced to OpenGL?

(I'd have used a sed regex, but to each their own  )

yes it also happens when you force dx11

Edited October 26, 2016 by Galileo

[komodo]

1 hour ago, Galileo said:

yes it also happens when you force dx11

... Unexpected. So dds textures for planets only works in dx9? Curious.  Weird too... Thanks for the update though, I had no way of testing that one. 

[Galileo]

6 minutes ago, komodo said:

... Unexpected. So dds textures for planets only works in dx9? Curious.  Weird too... Thanks for the update though, I had no way of testing that one. 

That seems to be the case but what is even stranger is that ground textures can be dds.  

Edited October 26, 2016 by Galileo