Jump to content

[Early development, 0.24] Kopernicus Planetary System Modifier

BryceSchroeder

By BryceSchroeder
in KSP1 Mod Development

 Share

Recommended Posts

Teknoman117

Teknoman117

Posted
Posted
Looks awesome!

I'm assuming you can modify the water colour as well?

Anything that can be configured we will try our best to provide configuration options for. As far as water goes, we know of options (from the shader at least) for color, opacity, color from space, specular color, and specular power. The planets have even more options, such as textures for different situations, like steepness, altitude, latitude, etc. Most of the stock worlds don't actually use a color map texture, but rather a procedural blend of tiled textures.

Link to comment
Share on other sites
braininator

braininator

Posted
Posted

Wow that looks amazing :)

Once everything is done and you have the cfg system do you plan on documenting all the different variables exposed in the cfg? I know planets are more documented then when PF was released, but documentation would still be appreciated :)

Also my dad helped me program a java program that formated PF CE cfgs. If you can get me an early blank CFG file (with all variables put in there... but blank...) Dad and I can probably adapt it for this purpose.

Link to comment
Share on other sites
BryceSchroeder

BryceSchroeder

Posted
  • Author
Posted
Wow that looks amazing :)

Once everything is done and you have the cfg system do you plan on documenting all the different variables exposed in the cfg? I know planets are more documented then when PF was released, but documentation would still be appreciated :)

Also my dad helped me program a java program that formated PF CE cfgs. If you can get me an early blank CFG file (with all variables put in there... but blank...) Dad and I can probably adapt it for this purpose.

We were just talking yesterday about making a documentation wiki yesterday. It does seem like an important practical aspect of the project...

Link to comment
Share on other sites
antgeth

antgeth

Posted
Posted

just wanted to pop in to say that what you guys are doing is amazing; i wait with bated breath. i hope that once this is released it gets the attention of some really good planet designers. for me, one of the biggest downfalls of PF was that so many of the planet packs added very little new content; just more same-size gas giants with rocky moons. hopefully the fact that now planets will need to be designed from scratch will force more creativity.

(i am, however, a bit concerned that the MET in that screenshot up there seems to have a negative value!)

Link to comment
Share on other sites
Yargnit

Yargnit

Posted
Posted

A bit of feedback from the pre-alpha u sent me.

Laythe's Atmo might be a bit of an exaggeration, it has no o2. ;P

The visible terrain doesn't seem to line up quite right with the actual collision mesh when trying to glide down a plane, i sink about 3m under the visible surface before instantly blowing up regardless of having gear down. (Rocket vertical landing works fine and the terrain mesh is correct)

The time control http://forum.kerbalspaceprogram.com/threads/69363-0-24-2-Time-Control-7-27-14-v12-1-HyperWarp-oodles-of-other-new-features mod doesn't appear to work on Kopernicus, but dynamic warp does so I'm not sure where that fault lies.

It seems like a ship exploding on the surface creates a bit more lag than normal? But hat could just be me)

Parachutes react as if the terrain were all at 0m absolute rather than to actual terrain level. (So they won't deploy until you are at their deploy range from sea level)

Kerbal Engineer can't read the slope angles until you are just barely over the terrain. (it does read altitude to terrain correctly even though parachutes don't)

The texture subdivision lines are quite noticeable and frequent on the surface, it looks like a checkerboard of 5x5 dotted white outline when viewed from a camera angle close to the terrain.

All that said, it handles map view much better than planet factory ever did, and exhibits none of the bouncing off the orbit or hyperedit issues that plagues PF (especially the CE version) You guys have done an amazing job so far, and I look forward to continuing to toss you guys feedback.

Link to comment
Share on other sites
braininator

braininator

Posted
Posted

I am unsure what you put hte radius to be, however, in Kittoptech, PF, PF CE, and possibly also RSS that the radius of a planet only has so much accuracy to the number. IIRC it was about 2 significant figures. This also had the standard issue of the terrain not meeting the mesh in each of them...prompting me to believe it is in the core game. HTH :)

Link to comment
Share on other sites
Teknoman117

Teknoman117

Posted
Posted

I think I may know why the time control mod isn't working. It hard codes the standard warp altitudes for all the bodies. See https://github.com/Xaiier/TimeControl/blob/master/TimeControl/TimeControlSettings.cs and note the "public static string[,] standardAltitudeLimits = " variable has as many hard coded values as worlds. I may change that to a dynamic lookup and submit a pull request.

Link to comment
Share on other sites
Yargnit

Yargnit

Posted
Posted (edited)

I got to thinking, I dont think the terrain thing is a "terrain scale" issue at all. Rather I'm thinking that maybe the airplane landing gear just aren't interacting with the terrain at all. The height is just about right for the collision to be happening when the rest of the plane interacts. I'll do a bit more testing, but I have a theory for the cause.

Edit: Nope, it's not that. i dropped the landing gear straight down and they worked fine. Will do some more testing.

Edit 2: So it's not landing gear specific. Rather it has to do with when you're ship rolls from one ground 'tile' so to speak to another. Collision is not rendered with the terrain on the second tile. I've confirmed this with plane and rover wheels so far. Going to try a Kerbal next.

Edit 3: On foot works the same. Furthermore, if you make a complete stop every 70 meters or so you're good. But if you go somewhere between 70 and 85 meters (it tends to vary) in a single direction you'll fall through the world and explode immediately. (Also of note the planet is extremely "grabby" meaning it's basically impossible to slide an I-beam/metal plate across the surface compared to on Kerbin)

Edited by Yargnit
Update
Link to comment
Share on other sites
Teknoman117

Teknoman117

Posted
Posted (edited)

Interesting. I've just confirmed the bug with the airplane (I added oxygen) and the rover. Very interesting - and confusing. I've have a couple of theories.

1) I may have goofed the physics material for the surface. This certainly describes the "grabby" aspect, as the physics material used it from Dres, which probably is made more grabby to help land in the vacuum.

2) The "maxLevelAtCurrentTgtSpeed" and "maxQuadLengthPerFrame" variables might cause the terrain to not update rapidly enough at speed. I currently have quad lengths per frame set a lot lower than stock because of something I saw in RSS, but, as the tiles are larger there, this could be having adverse effects.

3) The build I sent you has experimental detail presets. This might describe the lag, as Kopernicus uses a detail preset 4x greater than the "high" setting for the rest of the planets (more subdivision, this might explain the fracturing of the terrain textures).

Edited by Teknoman117
Link to comment
Share on other sites
Yargnit

Yargnit

Posted
Posted (edited)

Well the "speed" doesn't appear to matter. it can be a plane landing at 50+ m/s, or a Kerbal waddling at non-running speed. All that appears to matter is if you come to a full stop before u move far enough to fall off the current ground tile you're on. I'm currently flying out there without Hyperedit to confirm that nothing I was seeing was Hyperedit related, though I don't expect it was.

Edit: Confirmed ground glitch is the same when not using Hyperedit

Edit 2: And quickloading that lander I lost the ability to click the EVA or the ladder to extend it. When I went to the tracking station and back to it the entire thing exploded and shot into the air. Note I was landed on quite the slope.

Edited by Yargnit
Confirmed
Link to comment
Share on other sites
Teknoman117

Teknoman117

Posted
Posted (edited)

Terrain bug fixed (at least reduced? "Fixed" makes a claim which I can't truly know the answer to)

A combination of theory #2 and theory #3 were the answer. As you increase the maximum LOD level, you must increase quadLengthsPerFrame. Essentially, I bumped up quadLengthsPerFrame and my rover no longer fell through the ground at high speeds, but the plane still crashed. I dropped the maxLevel and the plane lands properly.

Why the speed matters is that the game is generating tiles at a slower rate than you are moving over them. Eventually, you just get past the computed physics zone. This is fixed in the latest commit and I'll send you a new build. As it turns out, I discovered a bug with time warp. When coming out of it the planet would reverse along its orbit... UpdateOrbit() is no longer safe to call during PQS creation now that we are a true prefab. The removal of this fixed time warp.

I just checked out Kerbal Engineer's source code. Its got the same issue as the time warp mod. All the worlds in the mod are hard coded. After I figure out the terrain bug, I'll play around with them and see if I can modify them to work.

https://github.com/CYBUTEK/Engineer/blob/master/Engineer/CelestialBodies.cs

Edited by Teknoman117
Link to comment
Share on other sites
Yargnit

Yargnit

Posted
Posted (edited)

Anything with the parachutes only detecting absolute sea level as opposed to relative ground level? (Not sure if u missed that part)

That's actually funny, I hadn't noticed any issues with time warp myself.

Edited by Yargnit
Link to comment
Share on other sites
Teknoman117

Teknoman117

Posted
Posted

Maybe something I did fixed it, but i didn't address it directly. Just did a test, and a drogue 'chute set to deploy at 2500m deployed at 3100m ASL over terrain. Do you have RealChutes installed? It might be messing with things. Like the two other mods you use won't be compatible without modification to them.

Link to comment
Share on other sites
Yargnit

Yargnit

Posted
Posted (edited)

Negative, no real chutes here.

Full mod list atm:

Editor Extensions

Kerbal Engineer

Hyperedit

Dynamic Warp

Module Manager

& Kopernicus

Running the 32bit version of KSP, haven't tried it on x64 yet.

BTW if you'd like to add me on Skype for easier feedback/conversation feel free. Same name as the forums.

Edited by Yargnit
Link to comment
Share on other sites
NathanKell

NathanKell

Posted
Posted

maxQuadLenghtsPerFrame is actually a divisor (and the typo is correct). The lower the value, the higher the number of quads that can be shown per frame. A value of 0 means to not cap them at all (and makes timewarp essentially impossiblly chuggy with a PQS displayed).

Link to comment
Share on other sites
Yargnit

Yargnit

Posted
Posted

So Tek got the terrain bugs all sorted out. :D I've tested x32 and x64, both work well. I also did a science test mission and science reports properly including the repository. It's looking really good all around here, you guys have done an amazing job.

Link to comment
Share on other sites
Teknoman117

Teknoman117

Posted
Posted
maxQuadLenghtsPerFrame is actually a divisor (and the typo is correct). The lower the value, the higher the number of quads that can be shown per frame. A value of 0 means to not cap them at all (and makes timewarp essentially impossiblly chuggy with a PQS displayed).

Hmm. Well, I think I may have discovered the initial problem as a side effect of the other issues (such as Kerbal Engineer). Even with the quad length set at 0.001f as it is in RSS, if the maxLevel is too high (had it set at 14), something broke about ray casting. This is probably why physics glitched out as well. And why the PQ nodes weren't showing up in the debug log....

Link to comment
Share on other sites
Teknoman117

Teknoman117

Posted
Posted (edited)

I've written a patch for Kerbal Engineer that allows it to provide VAB and SPH flight stats for custom worlds. The patch finds planets dynamically, so any planets you may set up or any planets Squad may add in the future would be discovered.

Hopefully they accept my pull request.

https://github.com/CYBUTEK/Engineer/pull/11

Edit: I've gone back and patched the *current* branch of Kerbal Engineer (missed the big 1.0.x release banner. I need to sleep more...)

https://github.com/CYBUTEK/KerbalEngineer/pull/2

Screenshot.2014.08_04_15.29.24.small.png

Edited by Teknoman117
Link to comment
Share on other sites
biohazard15

biohazard15

Posted
Posted
I've written a patch for Kerbal Engineer that allows it to provide VAB and SPH flight stats for custom worlds. The patch finds planets dynamically, so any planets you may set up or any planets Squad may add in the future would be discovered.

Can you (or anyone else) do the same for MJ?

Link to comment
Share on other sites
Padishar

Padishar

Posted
Posted (edited)

Love what you've done with this so far.

Kerbal Engineer can't read the slope angles until you are just barely over the terrain. (it does read altitude to terrain correctly even though parachutes don't)

I wrote the slope detection in KER and it simply uses a RayCast so that it can get the actual surface normal:

if (Physics.Raycast(vessel.CoM, -rad, out hit, Mathf.Infinity, 1 << 15))  // Just "Local Scenery" please

...but I suspect that the layer mask may need some tweaking. Originally, it didn't use a mask at all and it sometimes hit the vessel but I didn't exactly do a lot of research to come up with 1<<15, just looked at a list of layers somewhere on the forum, tried 1<<15 and it seemed to work in the situations I knew of that were broken. It usually works up to a considerable altitude but I presume this simply depends on when the PQS decides to start generating polygons...

As for the altitude to terrain, this uses:

vessel.mainBody.GetAltitude(vessel.CoM) - vessel.terrainAltitude

There is some "TERRAINTEST" conditional code in KER 0.6.x.x that displays various extra readouts for terrain height related stuff. Building a version that includes this code may help to give insight into what is going on.

Edit: Doh! I should've read to the end of the thread first, I see you've already worked most, if not all, of this out...

Edited by Padishar
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...