Jump to content

Akira_R

Members
  • Posts

    678
  • Joined

  • Last visited

Everything posted by Akira_R

  1. So I am using a mod that must be doing something funky with it's meshes that is causing some wonky voxelization, I know this isn't a FAR problem but I figured some one could tell me what is being done weirdly and then I can pass that info along to the mod author. Pics: Basically some parts are showing up as hollow and have next to no cross sectional area. I am using the latest FAR dev on 1.2.2 and all up to date dependencies.
  2. http://wiki.kerbalspaceprogram.com/wiki/CFG_File_Documentation https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook Those pretty much contain all the info you will need to learn, I would suggest opening up one of the stock part cfgs along side that first link and just figuring out what everything in the file does, it shouldn't be to hard to figure out. I would stay away from the SSTU cfgs for awhile until you get a handle on the stock way of doing things. As the SSTU parts are a bit more advanced and complicated lol. You can open .cfg files with any standard text editor like notepad, however I highly recommend Notepad++ and I'm pretty sure any one else on the forum will as well lol, it is free and is an excellent tool.
  3. @eddiew and anyone else that is interested here is my 3.2x rescale config that I use with GPP, it keeps mountains at a reasonable height and extends the atmosphere to around 84km I believe, the last 10km or so are very thin which makes reentries a bit more natural. Also if you are using the SVE configs or anything else that adds clouds this will make sure your clouds are at a reasonable altitude and not up at 30km
  4. If you are going to be playing with part mods and complex mods like RO/RSS/RF etc. I would STRONGLY recommend getting familiar with .cfg set up and Module Manager syntax. It's really quite straight forward and easy to learn when you get down to it, you don't need to know any programming, and by knowing these things it makes identifying bugs like this and fixing them fairly straight forward. I don't use RF and so I don't know if they patch part by part or if they are utilizing a batch patch method targeting resources and MODULEs. My guess would be they would have to do it part by part, if that's the case then somewhere in your GameData folder should be a patch specifically for SSTU, it should be easy enough to find it, find where it is targeting the soyuz parts and see what they are doing wrong.
  5. Are you using, Real Fuels, RP-0, RO? Sounds to me like a borked MM patch from another mod causing problems than a bug with SSTU.
  6. Also I just read an earlier comment of yours regarding the 3.2x scale and the huge mountains, I would suggest using the features in SigmaDimensions to scale down the terrain, I can't remember off the top of my head what I use but experiment and try and get the mountains to reach a reasonable height, and don't scale the atmo up to much, at least for realisms sake and to avoid crazy reentry heating and stresses lol. I can post the SD config I use if you wanna take a look at it.
  7. I have a 3.2x GPP career game that's been going for awhile now, looooots of mods and lots of my own configs and tinkering, I've also rescaled my atmo so that it ends around 84km but the last 7km or so are super thin. I have mostly deleted all of the stock rocket stuff and use SSTU parts for all of my rockets, I can easily put a 1.25m command pod into high Gael orbit with a 1.875m lifter with dV to spare. I personally love Near Future, one of the many mod-suites I use, works fantastically with MKS and EPL for doing long crewed missions if you are using a LS mod. Is it needed? probably not, this is KSP you could build a huge ugly monstrosity with lots of droptanks that will get you out there, but I hate that kind of thing, I prefer playing with a bit of realism in mind.
  8. Sorry for continuing the off topic but if you haven't already I highly suggest familiarizing yourself with KSPs cfg set up and MM syntax etc. there is actually a lot that can be done just with the configs themselves and no writing of additional plugins, or utilizing already made plugins. The only time you really need to write code is if there is some kind of specific functionality that is missing from the game.
  9. Yeah it's sort of a fight club type situation, first rule of FAR dev build is you don't talk about FAR dev build, in order to keep the flood of "it's broken you suck!" posts on the FAR thread to a minimum, but it can be acquired from the ksp_update branch on the FAR GitHub, it's been very stable for the past month or so and I've only had a few instances of craft reentering the atmosphere with zero drag lol. But you didn't hear it from me sorry for the off topic Galileo.
  10. With the current dev version of FAR for 1.2.2 and GPP every thing is working fine one my end. As @OhioBob said FAR makes use of whatever atmosphere is present, it doesn't really change the atmosphere but change how parts interact with the atmosphere.
  11. I also rather like your optional patches, maybe move them outside of the game data folder in the download?
  12. Unfortunately I think this can only be fixed by changing the meshes of the planet themselves, basically the texture and the collision mesh were always slightly off, in stock this is not noticeable (you might notice the boots sink in by a very tiny amount) but when you resize the planet the discrepancy is magnified.
  13. @Probus So I was lamenting the inability to easily edit the part placement in the tech tree in a thread I made And the topic came up again in the SSTU thread where shadowmage pointed me to your GitHub page that there was something there called Techtree Editor!!! But he hasn't used it and so I was wondering if you or someone could explain how it works and tell me if it is able to help you edit part placement or only placement of nodes? Thank you!
  14. Oh man I sure hope this is what it looks like!!! Off to the ETT thread to find out!!! Thank you!!! Probably wont actually be able to check it out until like next week some time though I've got a big chemistry final tomorrow that I should probably study for tonight and my girlfriend is walking for her first degree tomorrow as well so it's gonna be a long weekend hanging out with her parents *sigh*
  15. Nice!!! Now we just need some re-textured medieval suits for use with Texture Replacer and like a steam punk mod or something... There's the Vertical Propulsion Emporium but it hasn't been updated in awhile and it's more like Renaissance style, so maybe a reskin for it to.
  16. This is one of the reasons why Procedural Fairings is the be all end all for fairings, in my opinion. There are a few limited situations where the stock style fairings are more advantageous, but they are very few and far between, again in my opinion. EDIT: Yesterday it was showing I quoted @tenvelden today I was now quoting @tater's post... what the heck forums....
  17. I've had lift off speeds between 30-40m/s but I was using KAX, and AirplanesPlus, and they weren't little micro drones, but they had top speeds of like 200m/s which made it so they were only useful thanks to KerbinSides extra runways all over the place, even then it was annoying getting to contract locations. I usually only use mk1 structural parts and clip a couple mk0 fuel tanks into the body for fuel as the mk1 fuel tanks have just obscene amounts of fuel and are so heavy, really need to look into seeing if fuel wings is still a thing... but I'm lazy....
  18. This is the exact problem I always face when trying to set up a career game, from the sound of it what you want out of a tech tree is exactly what I want, ETT is way to much, stock is well stock, CTT just extends the tree and SETI is to restrictive/focused. I usually settle with CTT and spend weeks rearranging things until I get it in a state that I am ok with playing. This annoying process is why I proposed this:
  19. Woot!! I just found this, I've been so frustrated building planes early in the career with FAR, the stock limit for the level one SPH of 30 parts is ridiculous, now I can finally change it instead of cheating me some money and upgrading the SPH early. Thank you @sarbian for all your awesome contributions to the community!!
  20. As DoctorDavinci said licencing is one reason, however another reason is that for many FAR is way to hardcore. The stock system is much "easier", more forgiving and "intuitive" (easier and intuitive are relative here) for the average player. I highly doubt we will ever see anything like FAR become stock because of this. While to us FAR is obviously better in every regard we are actually in the minority when it comes to the overall KSP player base, and not having FAR stock is perfectly fine and the right decision in my mind, it keeps KSP accessible for a wider audience. However it does have the drawback of no guarantee of being updated whenever KSP updates, and while the day that ferram4 stops developing for KSP will be a dark dark day for this community I have faith that the talented members of our community won't let FAR die so easily.
  21. Being discussed in the Kopernicus thread, the situation they are having is directly related to Better Burn Time but the actual root cause of the problem that they have found could crop up with other mods and a fix is being worked on.
  22. That is kind of what I assumed as well however looking at the documentation in the OP it says that "building size is multiplied by this parameter" not multiplied by the Resize parameter so a setting of 1 shouldn't resize anything? if I'm understanding that correctly that is. One thing to note is that at a 10x rescale that hill and island should be absolutely massive compared to the KSC, however that hill appears fairly similar in size compared to the KSC as in a 1x, this is something I noticed in my 3.2x as well. Having the resizeBuildings set to 0 says this is "automatic" mode and will only resize the buildings if we are shrinking the planets, but maybe something is getting borked with GPP? One other thing that I noticed is that with 0.7.0 and GPP it appears that the KSC is shifted to the north, and ending up under that hill, instead of being on the nice flat area to the south of the hill like it is supposed to be.
  23. I had the same issue when using SigmaDimensions 0.7.0 and GPP in a 3.2x rescale. I reverted to SigmaDimensions 0.6.3 and everything is fine and hunky dory again, I didn't try messing with it but maybe try setting the resizeBuildings parameter to 1?
  24. Hey @Shadowmage so I was playing with this and a very much still in-development not intended for public consumption version of FAR that works for 1.2.1 and I just wanted to let you know that currently FAR falls flat on it's face when one of these wheels is used, otherwise everything is fine. I don't expect any kind of support obviously as like I said, not at all an official FAR release, I just wanted to bring it to your attention as a possible issue in the future and see if you are interested in looking at any of the logs.
×
×
  • Create New...