Jump to content

OhioBob

Members
 View Profile  See their activity

  • Posts

    3,934

  • Joined

  • Last visited

 Content Type 

Everything posted by OhioBob

  1. OhioBob
    Well then, I don't know what the problem is with those mountains. If it's not the cache and it's not the orientation of the images, then I don't know what it is. I'm out of ideas. (Are you sure you rotated/flipped the images correctly?) Describe again the problem with the orbit line. I don't think I really understand what the issue is.
  2. OhioBob
    I usually I'll see stuff like that when I have an old cache. I don't know how it works exactly, but when there's an outdated cache file we can often get what looks double images that don't quite match up, or weird ghost images. In your case it could be the orientation of the images. I don't recall how Kittopia exports them, so they might have to be flipped or rotated. If you don't, then scaled space images won't line up with the PQS. If you envision what the image is suppose to look like in the game, then color and normal maps should be rotated 180 degrees from that. And height and biome maps should be flipped horizontally. And going from color/normal maps to height/biome maps requires a vertical flip. I use both Photoshop and GIMP, neither of which come with the ability to create .dds images. However, both do have .dds plugins that you can install.
  3. OhioBob
    Or you can set the path to something inside your mod folder, which is what most people do. cacheFile = Systended/Cache/Icio.bin
  4. OhioBob
    That looks a lot better. Those mountains in the background look funny, however. Maybe you need to delete/rebuild your cache file. I also see you added scaled version texture and normals. Some of those maps can be very particular about what kind of file format and compression you use. I'm not sure what result you'll get with .png color or normal maps. These are the recommendations that I always go by when creating maps: Color maps & other textures, no transparency: file format .dds, DXT1 compression, with mipmaps. Color maps & other textures, with transparency: file format .dds, DXT5 compression, with mipmaps. Normal maps: file format .dds, DXT5nm compression, with mipmaps. Height maps: file format .png, grayscale, 8-bit. Biome maps: file format .png, with indexed color palette. Most color maps do not use transparency, but an example of one that does is when a planet has oceans. In order to keep the land from having an ugly glossy appearance, the texture has to be split into layers: one containing the water at 100% opacity, and the other containing the land at ~10% opacity. Something like a ring texture will also be transparent in order to allow stars to show through it.
  5. OhioBob
    I also just noticed that you don't have any color or normal maps specified under ScaledVersion. While you can do PQS without maps, you need them for the scaled version. Since you don't have scaled versions maps, you're probably getting those of the template, Laythe. Which means you're transition from a Laythe image to your PQS. It's no wonder it's all messed up. We can talk about this more after I return from lunch.
  6. OhioBob
    As you move closer to a planet, you transition from a scaled space image to a PQS generated surface. So those weird colors likely have something to do with that. I've been told that you should make ScaledVersion/fadeEnd = PQS/fadeStart. You haven't done that. I suggest you tweak your numbers to see if that makes any difference. I'm taking a lunch break, but when I get back I'll try adding your cfg to my installation to see what I get.
  7. OhioBob
    I don't know what's happening with the orbit line. It seems you have several problems going on, which may or may not be related to each other. I'd like to see you make the revisions we've already talked about and then see what, if anything, changed. Let's see if we knock out the problems one at a time.
  8. OhioBob
    That's a problem, but it's nothing new. I can think of a lot of mods that won't work with others unless specific support is provided. For instance, a new engine pack won't work with Real Plume until somebody writes a cfg for it. Real Plume includes a whole folder full of cfgs to make it work with various engine packs. A Tellumo home world package would have to do the same. I started with just the stock engines, but over time support could be expanded to include other engines. And we wouldn't have to do ALL the engines. If an engine pack isn't supported, you just can't use it. Tough luck. Engine makers could also provide they're own cfgs if they wanted their engines included. Personally, I wouldn't like the idea of moving KSC up to an extreme altitude; it takes away the challenge. We were originally targeting something around 2,000-2,500 m because at that altitude the atmospheric pressure has dropped to about 5 atm. That's the same as Eve sea level, so some experienced players might already know what to expect.
  9. OhioBob
    The reason I'm not sure my engine package would be appropriate as a separate release is because it takes a different approach to the problem than I did with Eve Optimized Engines. EOE assumes that Kerbin is the home world (or a similar planet like Gael). All the engines in the inventory are designed for beings that make their home on Kerbin. There only needs to be a select few engines designed for other environments. EOE includes only six engines, which provides plenty of options for an Eve mission. However, the approach I took with my Tellumo engine package is that Tellumo is now the home world. The thought process behind engine design must change. All the booster engines are now designed with the primary goal of launching from Tellumo. If Tellumo engineers want to send a mission to the surface of Gael, they'll need to produce some engines that will work there, but just a few will do it. The bulk of the inventory takes a Tellumo-first approach. I also completely redesigned SRBs specifically for Tellumo.
  10. OhioBob
    Gael was designed to play just like Kerbin. We wanted to retain that familiarity. It differs from Kerbin in appearance only. The only thing we did to make it a little harder was to move KSC off the equator. Where we wanted to provide something different is with the other planets, so that's where we tried to provide some variation and challenges not found in the stock game. If you want something different from Gael but not as difficult as Tellumo, why not just make a mod that changes Gael. It would be very easy to change Gael's physical properties to give it just a little more gravity or a little thicker atmosphere, or whatever. We don't have to go all the way to Tellumo to make those changes. I just seems to me that the reason for switching the home world to Tellumo is for Tellumo, not for some modified version of Tellumo.
  11. OhioBob
    Changing the atmosphere defeats the purpose, I think, of making Tellumo the home world. In my mind the reason for making the switch is exactly because Tellumo has a thick atmosphere and high gravity. It provides a much greater challenge not found on Gael. I wouldn't want to make Tellumo the home world just for a change of scenery. That's why I planned to modify all the engines for a Tellumo home world edition. We shouldn't go and change the planet to make it easier, we should reengineer the parts so they work better on the planet we call home. The changes would have to be similar to what I did in the mod Eve Optimized Engines. All I did for EOE was to change the engine ISP curves and thrusts to what they would be if the nozzles were adapted for the high ambient pressure on Eve. The engines of EOE also work pretty well on Tellumo, so I would recommend it as a stop gap measure. In the meantime, I'll revisit the engine modifications that I made way back in January when we first talked about a Tellumo option. Maybe I can pull that information together and come up with some sort of Tellumo Optimized Engines package. I know I had a plan for what I wanted to do, I just have to try to remember what it was. Of course at that time we talked about placing KSC at an elevation of about 2000 m as I recall. Gordon has KSC closer to sea level, so that may changes things. @Gordon Fecyk, if I'm able to put together this engine package, do you think we could bundle it into your Tellumo download? I'm not sure how much sense it makes to release it separately because it doesn't serve much purpose without Tellumo being the home world.
  12. OhioBob
    I didn't save it, but I think it was this: @Kopernicus:AFTER[Kopernicus] { @Body[Kerbin] { %PQS { %Mods { %VertexHeightOffset { offset = -66 order = 100000 enabled = True } } } } }
  13. OhioBob
    Well this is interesting. I made a slight change to the syntax in the second cfg and I got it working, sort of. It looks like it lowered everything - land, water, everything - except for KSC. The entire KSC complex is now hovering above the ground. Let me go back to the first cfg and see if I can get it working. @Fireheart318, I'm sorry but I'm giving up. I can't get it to work.
  14. OhioBob
    I just tried the second cfg and it didn't work for me either. I'm checking into it now to see if I can figure it out.
  15. OhioBob
    I'm out of ideas then. For most planets I've worked on, both of those suggestions would have worked. Maybe Kerbin is immune to some of the usual tricks. If I get a chance I might play around with it a little bit to see if maybe there's a syntax error that's preventing it from working. In the meantime, maybe somebody else has a suggestion or can spot an error in my code.
  16. OhioBob
    Maybe my suggestion doesn't work with Kerbin. I don't know exactly how Kerbin is generated, it uses a lot of PQS mods that I'm not familiar with. It's also possible that there could be a syntax error (like maybe one of those @ symbols isn't needed). Give this a try instead. VertexHeightOffset should shift the terrain up or down by the number of meters specified. @Kopernicus:AFTER[Kopernicus] { @Body[Kerbin] { @PQS { @Mods { VertexHeightOffset { offset = -66 order = 100000 enabled = True } } } } }
  17. OhioBob
    Yep, that's all there is to it. Just make sure you give the text file a .cfg extension. And you need to install Kopernicus.
  18. OhioBob
    I suggest you try changing the VertexHeightMap offset. I believe its current setting is -1500. Using a larger negative offset will lower the terrain and raise the water level. For example, you might try something like this: @Kopernicus:AFTER[Kopernicus] { @Body[Kerbin] { @PQS { @Mods { @VertexHeightMap { @offset = -1566 } } } } } The grass around KSC has an elevation of about 65 m, the crawlerway is about 67 m, and the Launchpad is about 72 m. So changing the offset from -1500 to -1566 should flood the grass, but leave the crawlerway, runway, etc. above water. Obviously you can make it whatever you want it to be.
  19. OhioBob
    Eve Optimized Engines 2.0.0 This latest release makes no changes to the engines, they should look and perform exactly the same as the previous version. What version 2.0.0 does is change the way the engines are created. They are now copies of stock parts rather than entirely new parts. This eliminates the need to repackage the part textures, greatly reducing the size of the download and disk space required. Eve Optimized Engines has been reduced to simple configuration files.
  20. OhioBob
    If we do get around to making Tellumo the home world, one thing that you'll notice is that 1 atm now equals 1013.25 kPa. In other words, 1 atm is defined as the atmospheric pressure of the home world. Makes sense because to beings living on that planet, they're atmospheric pressure is the standard by which others are measured. So Tellumo and Gael will have atmospheric pressures of 1 atm and 0.1 atm respectively (though the pressure in kPa is unchanged). I don't know much about jet engines, but @Gordon Fecyk has already figured out how to modify their curves for Tellumo. We probably just need to package his JetEngineCurveExtender with the Tellumo home world edition.
  21. OhioBob
    EVE Optimized Engines works pretty well on Tellumo. Those engines are adapted for 5 atm rather than Tellumo's 10 atm, but the improvement gained by further adapting them for the higher pressure is only marginal. Since EOE is "good enough" I've never seen a reason to bundle up my Tellumo engines as a separate release. However, if Tellumo becomes the home world, then that's a different story. Now the thought process has to change. Operating on Tellumo becomes the new normal, and the engines have to be modified accordingly. All the booster engines need to be adapted for Tellumo's, high atmospheric pressure, and we need just a few engines for off world use (such as on neighboring Gael, which has only 1/10th the atmosphere of the home world, but still significant). The biggest change has to be to the SRBs (the existing SRBs are totally worthless at high pressures). I completely reworked SRBs to turn them into something useful. Using my engine modifications I found that it is actually fairly easy to launch from the surface of Tellumo, though with a significantly lower payload fraction than we are accustom to.
  22. OhioBob
    Ah, so maybe my engine modifications weren't for nothing after all. Maybe you mentioned at some point that you got it working, but I don't recall that. GPP has obviously gotten a lot more complex since we first played around with the idea. It doesn't surprise me at all that making a home world switch could produce all sorts of bugs and unintended consequences.
  23. OhioBob
    That is actually an idea that we played around with nearly a year ago. We wanted to provide a Tellumo Home World edition. For some reason @Galileo could never make it work. I don't recall the problems, but I know Galileo struggled with it for quite a while. I looked over the cfgs as well and neither one of us could figure out why it wasn't working. I remembering doing quite a bit of work figuring out some engine/SRB modifications to better adapt them to Tellumo's high ambient pressure, which ended up being all for naught.
  24. OhioBob
    @ApertureGaming, it's weird and I don't totally understand it, but basically we have the equation, invWaveLength = 1 / waveLength^4 and, waveLength = 1 / invWaveLength^0.25 Atmosphere colors are given as wavelength, but it is the inverse wavelength that gives us the proportions of R, G and B. For example, the color of your atmosphere is, lightColor = 0.42,0.74,0.92,0.5. In inverse wavelength that's, R = 1 / 0.42^4 = 32.1368 G = 1 / 0.74^4 = 3.3348 B = 1 / 0.92^4 = 1.3959 So as you can see, your atmosphere is actually almost all red, which is undoubtedly why we see a red atmosphere in the fourth screenshot. The part I don't quite get yet is that the RGB values of the inverse wavelength don't seem to be on a 0-255 scale. I haven't figure out yet how to convert a 0-255 RGB color to inverse wavelength. I've found that the best way to get the atmosphere color I want is to use KittopiaTech and edit it in the game using the sliders. After I've found a color I'm happy with, I just copy the values to the config. I've never actually used the ScaledVersion/Material/Gradient before, but from what MrChumley says, those are apparently wavelength colors as well. For now I recommend that you just delete the gradient and test your config without it (it should just use the gradient of the template). After you get things working correctly you can worry about adding Gradient back (or just go without it if everything looks OK, which I what I generally do).
  25. OhioBob
    @ApertureGaming, MrChemley makes a good point. There are also generally fadestart/end values in the PQS node as well. Since you haven't specified those, you might be getting the values of the template, which could interacting strangely with your scaled space values. Here are some typical values that we're using in GPP; maybe they'll work for you: ScaledVersion { fadeStart = 25000 fadeEnd = 30000 } PQS { fadeStart = 30000 fadeEnd = 120000 deactivateAltitude = 140000 }
×
×
  • Create New...