EatVacuum
-
Posts
233 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by EatVacuum
-
-
I don't know if anyone is working on an update of the community patch for HGR, but as I find the Radish capsule totally indispensable for those "save a stranded Kerbal" missions in the early-mid game, I've modded the part config to get it working in the 1.1 prerelease. The CoPOffset and CoLOffset are added in the version below and make the capsule quite stable on reentry, even with a few parts added on top (inline battry, parachute etc.). It sits a little high in the water perhaps so the centre of buoyance and centre of displacement may need tweaking.
It might be easier to just add the new values via a mod manager file, but for those who are interested, here's a complete new .cfg for the Radish...
SpoilerPART
{
// --- general parameters ---
name = Radish
module = Part
author = Orion// --- asset parameters ---
mesh = Model.mu
scale = 1
rescaleFactor = 1// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z
node_stack_bottom = 0.0, -0.5, 0.0, 0.0, -1.0, 0.0, 1
node_stack_top = 0.0, 1.05, 0.0, 0.0, 1.0, 0.0, 0
// --- editor parameters ---
TechRequired = flightControl
entryCost = 0
cost = 1000
category = Pods
subcategory = 0
title = HGR-57 "Radish" Command Pod MK2
manufacturer = Home Grown Rocket Parts
description = Designed to alleviate long lines at the launchpad, this pod has seen success as an upgrade to the MK1 command pod. It is also great for romantic dates and improvised rescue missions. Veterans appreciate having a hand to hold when things look grim.
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,1,0// --- standard part parameters ---
mass = 1.1
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.15
angularDrag = 2
crashTolerance = 21
maxTemp = 1400 // was 2400
skinMaxTemp = 2400skinInternalConductionMult = 0.625
heatConductivity = 0.1 // 5/6ths defaultbulkheadProfiles = size1p5, size0
//CoMOffset = 0, -0.2, 0
CoPOffset = 0.0, 0.5, 0.0
CoLOffset = 0.0, -0.35, 0.0
CenterOfBuoyancy = 0.0, 0.7, 0.0
CenterOfDisplacement = 0.0, -0.3, 0.0vesselType = Ship
// --- internal setup ---
CrewCapacity = 2INTERNAL
{
name = Radish
}MODULE
{
name = ModuleCommand
minimumCrew = 1
}
RESOURCE
{
name = ElectricCharge
amount = 100
maxAmount = 100
}MODULE
{
name = ModuleReactionWheel
PitchTorque = 7
YawTorque = 7
RollTorque = 7
RESOURCE
{
name = ElectricCharge
rate = 0.36
}
}RESOURCE
{
name = MonoPropellant
amount = 20
maxAmount = 20
}MODULE
{
name = ModuleScienceExperiment
experimentID = crewReport
experimentActionName = Crew Report
resetActionName = Discard Crew Report
reviewActionName = Review Report
useStaging = False
useActionGroups = True
hideUIwhenUnavailable = True
rerunnable = True
xmitDataScalar = 1.0
}
MODULE
{
name = ModuleScienceContainer
reviewActionName = Review Stored Data
storeActionName = Store Experiments
evaOnlyStorage = True
storageRange = 1.3
}
MODULE
{
name = FlagDecal
textureQuadName = flagTransform
}
MODULE
{
name = ModuleAblator
ablativeResource = Ablator
lossExp = -7500
lossConst = 0.1
pyrolysisLossFactor = 6000
reentryConductivity = 0.01
ablationTempThresh = 500
}
RESOURCE
{
name = Ablator
amount = 50
maxAmount = 100
)
)Enjoy!
-
8 hours ago, capran said:
@Fishbreath, can you provide a compiled DLL of your fork? I'm not a programmer and don't have an IDE (or know how to use one, really. I only tangentially delved into C and C++ over 16 years ago!) If it's there already, maybe you could be kind enough to provide a direct link?
Just download " KerbalAlarmClock-3.6.0-v1.1-provisional.zip" on that page, it is the ready to run version.
-
I am also extremely happy to hear that you are going to be updating this pack, I've beem [;aying since KSP was a teenager (release number-wise) amd IMHO the FusTek station parts were by far the best of the various station parts packs I've tried over the years.
On 2016-02-28 at 1:12 AM, sumghai said:The first thing I tackled was the issue of part variants. Personally, I like to build space stations by docking together numerous modules, each of which have the distinctive ISS/USOS-like shallow tapered ends. However, there are also those who like to build huge monolithic one-piece stations or ring, and prefer to use flat-ended modules. This meant that I had to maintain two variants for each type of module, which not only cluttered up the VAB/SPH parts list, but also increases my maintenance workload.
After considering a number of options, such as plugin-powered configurable parts or using the newly-updated stock animation module to make parts that can only be animated while in the VAB/SPH, I ultimately opted for the simplest of solutions that would provide the most flexibility to end users while being easy to maintain: just make all the modules flat by default, and have tapers as optional structural parts.
Personally I'm not too concerned about the number of parts in the part list, I'm more concerned about the number of parts in my space station.
A fantastic looking station is great, but if the frame rate is too low that takes away from the enjoyment, particularly by making EVAs and docking a pain. I do like the idea of having the end caps as they can be put onto other parts to make them more Fustek-like, but on the other hand I'd rather have one part per module rather than three (i.e. module + 2 end caps).
I don't know if it might cause some problems, but would it be possible to put two connector points at each end of a module, one that would allow normal end to end docking or attachment of docking ports etc, and one that's inside the module so that two parts could be fitted overlapped so that the tapered ends are hidden? That would satisfy the monolithic station builders, but it wouldn't allow people to opt for flat ended parts.
I'll be happy to get whatever you put out, but I thought I'd throw this out there for consideration. in any event, I guess if they are compatible with Ubiozur Welding I can make my own one-piece versions...
Additional -
On 2016-02-28 at 1:12 AM, sumghai said:Also, I invested some time this week into was updating the FusTek aesthetic - the hull panels have faux mounting rails between them where EVA handgrips could be plausibly fitted, EVA handgrip coverage has been greatly increase
Excellent!!! It's a pain in the @$$ trying to get a free floating Kerbal stationary for long enough to be able to carefully attach parts using KAS, so this is a great improvement. I'd gotten into the habit of carrying a mobility enhancer along when doing station modification just to give the Kerbal a convenient temporary anchor so they don't float off while I'm trying to get the new part aligned and fixed properly. More handrails will be very convenient for KAS users.
-
1 hour ago, curtquarquesso said:
I don't have a good way to back up "most users." I know a lot of people I used to see on this thread, are now over at Sigma, because it's being actively developed. Both add-ons are very similar, it's just a matter of maintenance and support. For one, it doesn't have an active download link anymore, so make sure you backup your install of it.
Sigma is able to handle terrain scaling, so the Kerbin isn't totally flat, which is really nice. I think it'd be great if he just moved over to Sigma, and handed it off as a 6.4x scale preset for Sigma, with appropriate balance patches for things like FAR, RealHeat, DRE, SMURFF or ROMini.
Ok, your reasoning makes sense, this forum has gotten a lot quieter. I was following SD for a while but it seemed to have a number of bug reports so I decided to let it mature for a while before seriously looking at it.
Regarding terrain scaling though, you can't raise the mountains much if you want them to be very realistic - Mt. Everest is "only" 8.85 km tall, and IIRC the "K2" mountain west of KSC is a bit taller than that. Ignoring realism, if you just scale terrain height up by a factor of 2 the mountains would be too high to fly over with the early jet engines but they'd still look boring because their width has been scaled up by horizontally by 6.4x so no dramatic mountain slopes. Much more and they might even get in the way of capsules trying to land at KSC. I tried playing with fixing the terrain by adjusting the deformation amount and it's not great. But that's just my opinion, your mileage might vary.
IMHO the only way to get good mountains, hilly highlands and grasslands that don't feel like you are an ant walking over a pool table in 6.4k is to add more terrain detail procedurally i.e. by using the various pqsmods. I would imagine it will be the same for 6.4x rescale under SD. But that's something that could be bundled in as part of the presets already proposed for 6.4x rescale under SD.
-
Paul does seem to have abandoned 64k, but on what do you base the comment that most users have moved on to Sigma Dimensions? Right now Sigma Dimensions is still in development and while it looks extremely interesting I see no reason to switch... at least not until I find out that KSP 1.1 breaks this mod. 64k doesn't really need anything changed right now and I like that it came as a single bundle with everything needed included. I've been playing with 64k, and before it 64x and the only things I've wanted to fiddle with is making the terrain more interesting. I'd been thinking of asking the OP if he would have a problem with me or better a community of users officially taking this over, but actually he made it public domain so that's not even legally required, just polite.
Only thing that's holding me back right now is my total lack of experience with Github and the (hopefully) not too distant release of 1.1
QuoteI found a problem. every time I go for re-entry from LKO I get the same problem. all my ablator is being used 70 per second. and that is before I go into the atmo at all. I don't know if it's on my half or in the mod but maybe worth looking into
Try tweaking the re-entry heat settings - I believe NathanKell posted an explanation of what to do some pages back in this thread.
-
I'd love to see procedural engines. My vision is to have two components, a procedural "engine" representing the reaction chamber, pumps etc. and a procedural bell. That would probably work best for modelling, but also for figuring out the important numbers,
The engine portion should take the fuel and oxidizer and convert it into "potential thrust", the bell would take the potential thrust and modify it formulaicly dependent on the current atmospheric pressure (or lack thereof) and the design of the bell into the "actual" thrust.
Engine size and tech would determine how much fuel could be processed per second, that and the Isp of the fuel would determine the potential thrust. Efficiency could be lowered somewhat by the technology of the engine - the Isp numbers available assuming ideal temperature, pressure etc. in the reaction chamber, but working pressure and temperature is limited by the available materials. Similarly open cycle engines are less efficient then closed cycle.
The radius of the bell's throat would be determined based on the engine specs, the bell's exit would be determined by player choice. The efficiency with which the potential thrust is converted to actual thrust is determined by the ratio of throat to exit and the ambient pressure at the nozzle exit. The length of the nozzle would determined by the nozzle exit diameter assuming efficient bell nozzle shape is followed. Players should be presented with a couple od presets for the bell - probably sea level optimized, vacuum optimized and intermediate, But they should also be allowed to choose any point on the scale - do I live with the weight and size of a fully optimized vacuum bell or do I sacrifice some efficiency to save on weight with a smaller bell?
Given the formulas for thrust, Isp etc. are well known, balance shouldn't be difficult. The one thing that would have to be worked out carefully is the ratio of engine weight to thrust. That is determined by engineering considerations, materials technology and so on, not as easy as calculating thrust.
-
On 2016-01-21 at 11:05 PM, HebaruSan said:
Does 64K+FAR do anything funny with parachutes? I'm trying to land a 2.68-ton craft with 13 parachutes and 6-8 airbrakes on Kerbin (full KER info in below screenshot, apologies for nighttime.) I have the chutes set to open at 5 km, and I'm staging them as soon as the icon says it's OK, which I think was around 14 km. The equilibrium descent speed near ground seems to be around 75 m/s. The old parachute calculator suggests that 9 radial chutes should do for a 4 m/s landing, and I'm sure that's out of date, but is it this far out of date? How many parachutes should be needed to land 3 tons safely? Do I need to install RealChute?
I tried adding a propulsive descent stage, and I timed it wrong and ran out of fuel too early, but I'd rather get the parachutes right if I can rather than retrying that.
Nope. I just launched a test vehicle 5km up and landed it at 5.3m/s using nine of the Mk 2-R radial parachutes. It weighed 7.07 tonnes on landing so definitely not a problem for me. I am using KSP 1.04 and FAR 0.15.4 but I doubt that makes a difference.
It might be some odd mod interaction, the only other thing I can think of is that the drag cubes for the chutes might be messed up. Look for PartDatabase.cfg in the KSP root folder. rename it to PartDatabase.txt. Then launch KSP and it should build a new PartDatabase.cfg file so all your chutes should have the correct values. Hope that helps.
-
On 2015-11-11 at 8:36 PM, Kagame said:
Hey, where's the author of this mod? It's 3 versions out of date (still compatible, just needs the version settings to be bumped), but it's so good...
Well, it's January and he hasn't been on the forums since October, so it is looking like this mod is going to die. Which makes me sad.
I tried sending him a message to see if he would be willing to turn it over to someone to keep it current but given he hasn't visited the forum in months, I doubt he'll read it any time soon. And given his legal terms for the mod state "All rights reserved -Permission to redistribute on CKAN" that doesn't leave any option to take it on without his express permission. So about all we can do is create MM configs to keep it up to date.
-
I don't see why this is could be considered cheaty. Just because you prefer to fly every launch manually doesn't make you a better player or more of a man. I could equally make the argument that those who do it that way are not playing realistically, everyone should be forced to preprogram a flight plan and live with the consequences. But how fun would that be?
I'll come out of the closet, yes I am a Mech-head and I'm proud of it! There, I said it. I use Mechjeb, I have an MM config to add it by default in all my capsules. And it's not that I couldn't WASD my way through every launch, but because I choose not to.
There is only one "right" way to play KSP. Everyone should play it the way they that they enjoy the most.
If this mod makes KSP more approachable or more fun for even one person then it is a good mod. So kudos to OverEngineer1.
-
22 hours ago, Mr Betelgeuse said:
Hmm, it sounds interesting. I wonder if you can make the mountains on Duna vertically taller to replicate Olympus Mons. I have a proposal for you: A Joint config for 64k. I'm working on the surfaces of Jools Moons and maybe we can put together our work into a piece that maybe @Paul Kingtiger could even implement into his mod!
Anyway, keep us up to date with your work on Duna/Eve. I'll do the same for the Joolian system.
I'd be good with that. It'll be a while before I likely do Duna... and then Eve's next on the itinerary so it would be a looong time before I got around to
screwing around withimproving the terrain for Jool's moons. It would be easy to manage a joint effort, even if several jump on the bandwagon as Kittopia puts each planet/moon into a seperate cfg file.Another thing I'd like to do is get the missing anomalies back. I mentioned in an earlier post that the ones on Kerbin aren't accessible, at least not in my current save. I just got an anomaly surveyor contract to investigate the arches, so I'll be landing near one soon...I wonder if they will be there? At first I was thinking that the ones that are working on Kerbin (KSC, island airport) have PQSMod_MapDecalTangent to adjust the terrain around the buildings and the missing ones (monoliths, ufo) didn't, so I was going to add map decals. But then today I noticed another, more likely correlation and one that would be easier to try, which is the "reposition" settings.
Accessible sites have;
PQSCity
{
name = KSC
debugOrientated = False
frameDelta = 1
repositionToSphere = True
repositionToSphereSurface = False
repositionToSphereSurfaceAddHeight = Falsebut the missing (or buried?) monoliths have
PQSCity
{
name = Monolith00
debugOrientated = False
frameDelta = 1
repositionToSphere = True
repositionToSphereSurface = True
repositionToSphereSurfaceAddHeight = FalseI bet changing one or the other of these will get the monoliths back. I'll likely do that before getting back to Duna.
And speaking of map decals...
17 hours ago, Tellion said:It is also possible to use MapDecals to apply high detail to a certain area via a specific height- and colormap. Borisbee's Sentar Expansion does that, even with Olympus Mons iirc. Granted, that would hardly make every part of the planet interesting, but it might be of interest to you nonetheless.
Funny you should mention that, on my list of things to (probably never actually) do was to build a really big, high mountain, but on Eve. Larry Niven was a favorite author many years back and on first visiting Eve (back in KSP 0.20 days) it occurred to me that it needed it to have something like Mount LookitThat...
(hopefully I'm not breaking any rules reporting the image from this site - http://news.larryniven.net/concordance/main.asp?alpha=M)
"The colony world itself is a Venusian type planet with a dense, hot, poisonous atmosphere. It would be otherwise uninhabitable, except for a tall monolithic mesa that rises 40 miles up into a breathable layer in the upper atmosphere.This gives the planet a habitable area about half the size of California. The Captain of the first colony vessel named the feature Mount Lookitthat (from his interjection at first sight of it), and the colony became known as Plateau."
Quoted from a Wikipedia article ( https://en.wikipedia.org/wiki/A_Gift_from_Earth )
But having said that, you're right, Duna needs it's mega-mountain too, or I guess mega volcano. Now should it be 16 miles/25km high or 64% of that...
-
22 hours ago, CatastrophicFailure said:
That's exactly where it happened the first time.
I'm sending a mission to Eve shortly, to see if it is indeed from the extra configs or something native to 64k.
Ok, I didn't keep notes on what I did, but looking back on pg. 26 and checking the configs themselves here's what I have;
For Minmus I only increased the terrain deformity (by a factor of three or so) to get bring the existing height/slopes to something midway between what they were in stock and the extremely gradual slopes and flattened plateaus and hill tops of the original 64k version. For anyone who wants to play with them here's the snippet of code to look for in Minmus.cfg;
PQSMod_VertexPlanet
{
name = VertexPlanet
seed = 23123
deformity = 15000
colorDeformity = 15000...
I didn't do anything else using other PQS mods that would add additional "lumps and bumps" or alter the surface in any other way. There are references to other deformity values in the file, but they are put there by Kittopia automatically, and (I assume) were gotten from the stock planet info. So that said, I can't see that the bottoms of the flats would be changed by anything in the config, their base height is zero, deformity doesn't impact them.
And in case it comes up for the Mun, I did the same thing, i.e. picked a higher deformity to bring back some of the steepness of slopes and large crater sides without making the high terrain so high that ships couldn't safely orbit at 40-50km height. I might have also deepened the procedural craters (i.e. the small ones scattered all over the Mun that first appeared back in KSP 0.21) a bit. The pqsmod for those is "PQSMod_VoronoiCraters" and there is it the "deformation" value.that controls the max possible depth of the craters.
-
On 2015-12-31 at 2:17 AM, Mr Betelgeuse said:
Any updates on the surface configs for the rest of the planets?
I got to Duna this weekend and it does look pretty flat, but I only landed in one area and that was in the lowest ground I could find to make it easier. I made a pre-landing save though so I can use that to try other sites to confirm. Given how thin Duna's atmosphere is I don't think increasing the vertical scale of the terrain ( terrain deformity) is a good idea - chutes are barely useful now and making highlands and mountains higher will only worsen things from that point of view. Eve should be easier from that point of view.
Adding the really rugged terrain on Duna like I did for Kerbin's mountains also potentially adds to the height, perhaps too much. So that leaves only adding the smaller lumps and bumps similarly to what I did for highlands and plains on Kerbin. I'm open to suggestions. Or if anyone else has already modded Duna let me know the results.
-
30 minutes ago, CatastrophicFailure said:
@EatVacuum yup I've got terrain cranked up to the max. I did notice that in the map view, anything landed there does appear way above the surface too. The probe was indeed on legs, but the two mini-probes are not, and they're just fine. Single parts sitting on the surface. One probe I landed on the Mün is also still fine (I think), while another got eaten.
Dang, those two ideas were my best shot. Has anything fallen through the terrain on the flats on Minmus?
-
On 2016-01-15 at 4:22 AM, CatastrophicFailure said:
Well this is annoying. I'm using the configs a fellow on this thread made up (user name escapes me) to restore some bumpiness to Minmus and the Mün, but it seems I cannot switch away from most landed vessels. If I do (like return to the tracking station), it's immediately deleted and I get the "crashed through terrain" entry in the log. But some vessels seem to be fine (the non-important ones, of course). Anyone else having an issue with this? Only tested on the M&Ms so far.
Hmmm, never had this happen and I've been using this (or an earlier version made by Raptor, or was it Regex for 6.4x) for about a year now. I do occasionally lose flags, but that happens on high time warp while waiting for a launch window, not on switching to a craft.
I did warn everyone to make a backup before trying this, but the reason was because this does change the height of the surface so anything that was landed on the original surface, before installing my configs, could end up underground or in mid-air with potentially craft and Kerbal killing results. But it should not happen for anything landed later.
Rescaling everything by 6.4 times does increase the "height error" for surfaces or the things on them by 6.4 times as well. In stock KSP if you look closely you will see that Kerbal feet and landing gear sometimes are sunk a few inches into, or float just above the surface. Scale that up by 6.4 times and you end up with Kerbals sometimes standing waist deep in the ground or floating a foot above the ground.
Have you by chance lowered the terrain settings to minimum to save memory? I know that has caused problems even in stock scale in the past. Try setting your terrain settings to high and see if it solves the problem. The only other thing I could think might be a problem is ground clearance for your craft. Given the increased height error I mentioned I wonder if parts of your craft other than the landing gear might be appearing under the ground by enough that the KSP engine is interpreting it as collided with the ground and causing the error. I did have that happen with a base I built on Minmus when playing 6.4x using Raptor's terrain mods, When I detached landing gear and set the base parts down on their bases it seemed okay, but when going back to the base later... BOOM! Since then I've left ground bases on landing gear.
-
On 2015-12-23 at 2:28 AM, Mr Betelgeuse said:
Thanks for the help! I really want to make some configs for the surfaces of the rest of surfaces because they really make 64k a lot nicer and in my opinion better. However, how much trouble was it to create the surfaces for Kerbin, the Mun, and Minmus? Did it take a long time to make? Any advice for me making the rest of them?
There's two parts to it, and the first is simple, the second not so much.
Step one - you just have to figure out how much to increase the vertical scale to get it appropriately "lumpy". Originally I would have thought 6.4x higher would work for all planets, but then you get issues like Kerbin's mountains being so high that you can't fly over, or sometimes even between them as the atmosphere height is only scaled up a little bit, so the air is two thin for flight. So for planets with atmospheres, that didn't work so well, which led to...
Step two - figuring out how the PQSmods for altering terrain work, and then using them. NathanKell posted some good starter info here --> https://github.com/NathanKell/RealSolarSystem/wiki/PQSMods-supported-in-the-cfg. There's a couple of other relevant posts on that github that might help.
You can just write the PQSmod code directly into a .cfg file, but using Kittopia provides a GUI interface that is (sort of) user friendly but more importantly you can use it dynamically, in game. I don't have my notes here but when I do I'll try to translate them into something useful and post them up here for anyone who's interested in knowing which PQSmods are most useful for terrain "improvement".
-
On 2015-12-31 at 2:17 AM, Mr Betelgeuse said:
Any updates on the surface configs for the rest of the planets?
Sadly no. Between social commitments, a couple of viewings of The Force Awakens, release of British tanks in War Thunder and new game distractions resulting from the Xmas Steam sale I barely advanced my own KSP campaign at all over the holidays. My usual method is to go there, look around and then figure out what needs to be done and I haven't reached Duna yet.
-
On 2015-12-27 at 0:03 AM, NathanKell said:
There being a prior conflation in this very thread between 64bit and 64K, and all mentions on this page being ambiguous, I felt I ought to mention it. Apologies if it's not releveant.
You're right, the 64k name for this mod has caused confusion on prior occasions. But Mr. Betelgeuse did mention that another problem he had with the KSC buildings was probably caused by the 64 bit workaround. I couldn't recreate it after redownloading and installing the configs I posted, so I don't think there's anything wrong with them. Betelgeuse still had it after changing them, so I was speculating that the colocation problem might also be caused by the workaround.
Certainly no apologies necessary, rather considering how active you are in the forums on so many topics I want to say thanks for all you do. You've given a lot to this community and actually, you taking the time to help me figure out some PQS complexities in the old thread was what led to me dabbling with improving the terrain in 64k in the first place.
-
On 2015-12-23 at 3:46 PM, Mr Betelgeuse said:
Regardless, I change them, but to no prevail, the KSC is still at the island airport. I'm not sure why this is happening...
I'm mystified, for now I am thinking it is 64 bit weirdness. Paul's original config had latitude and longitude coordinates, I wonder if substituting those into the Kittopia-generated Kerbin.cfg file might fix it? I'll try that when I have some time over the holidays.
-
11 hours ago, Mr Betelgeuse said:
Can I see those configs? I can't seem to find them, and I don't want to go diving through this thread... even though I will.
EDIT: Never mind, I found them. However, I must ask, will they work for every planet? And will they work for OPM planet pack? I ask this because I really want to play with 64k, but I don't want to experience flat boring nature of the game.
So I tried your configs out, and they seem to work decently. I mean, the only problem I have really is that the KSC is on the island runway, clipped into the actual runway. How can I fix this problem as seen here:
Also, you say that you are playing a career save. How do you upgrade your buildings without them bugging out like they do in the 64 bit workaround (level 3 buildings on start)
Also, I'm not sure if you know how to fix this. But OPM's Sarnus' and Urlum's rings are spawning inside of them. It seems like they didn't scale up.
Another issue I've been having with 64k is that the ocean's hate me. I get this really ugly flickering that is really distracting. Now I do have scatterer installed, but after uninstalling it, I still have the problem. How can I too fix this problem?
I can't wait to see if you make anymore configs for other planets, and I really hope you do the other ones like OPM and whatnot too. And if anyone could help me with the above problems, I might have to give 64k a long monthly (maybe yearly) try.
Just to clarify - I did not write those configs, I just generated them by using Kittopia to make the terrain more interesting, so I am a dabbler, not an expert in all of the various PQS utilities/tools etc. that are used to make the terrain.
I only generated new configs for Kerbin, Mun and Minmus, so any weirdness on other stock planets is not from my changes. I don't even play with OPM so I can't help much there either. I have been considering OPM though and I have this recollection that someone playing with RSS had the same problem with the rings and there was a fix provided. I don't recall if it was in the OPM or RSS threads but if your Google-foo is strong you might be able to find it.
I certainly have not experienced any of the problems you are describing. I wasn't aware there was a problem with the building upgrades, but if its because your playing with 64 bit then you are on your own, Practically every mod dev has a big "I do not support 64 bit" in their first post because it is so glitch.
For me KSC is on the mainland and the island airport is out on the island where they should be. But for interest I redownloaded my dropbox file onto my mini-laptop and looked through it. Each site (KSC, Island Airport, KSC2, monoliths etc.) has a "PQSCity" module and a "PQSMod_ MapDecalTangent module. As I understand it PQSCity overrides the stock settings for each site, i.e. defines the sites coordinates and height above the surface etc. PQSMod_MapDecalTangent is used to override the terrain - raise it, make it level so that the structures will be sited properly on the ground.
Unfortunately the coordinates are not stored as degrees of longitude and latitude, but as radial coordinates (or maybe offsets fromfrom their stock position? If anyone knows, I'd be interested to find out) and I'm not sure how to translate them. For KSC they are;
repositionRadial = (1009355.0, -8801.9, -3704960.0)
and for the Island airport;
repositionRadial = (186194.6, -16135.7, -570176.8)
Open your Kerbin.cfg file and see what coordinates you have for each site. If they are different than the above, re-download and replace the Kerbin.cfg file in your install. Hopefully that will fix the positioning problem, if not then it might be more 64 bit caused weirdness.
-
Has anyone else noticed that most of the anomalies are missing in 64k? And if so, has anyone got a config that restores them?
In my 64k campaign I added the anomaly surveyor contact pack and am not finding monoliths or the crashed vessel at most of the sites when I get the contracts. The monolith near KSC seemed to be missing, but then the contract waypoint was a ways off shore. The pyramids were there, but mostly buried, and there was no sign of the crashed vessel up in the arctic. I just got the contract to visit the Munar monoliths and I'd like to make sure they are actually there before dispatching multiple missions.
I did "fix" the terrain flatness as mentioned in previous posts, so I might have screwed them up myself (and for anyone who picked up my configs) in the process. So I thought I would ask around before delving back into Kittopia/Kopernicus again to see if I can get them back.
-
1 hour ago, Dermeister said:
I'm just using the ones that came with it.. I din't know we were supost to install textures. I'm not worried about ram so much since I don't use that many mods.
You don't normally need to install textures, the ones with 64k are fine.
Like some other users, I found the 64k planets very flat and boring as they seemed to have the same vertical heights as stock Kerbin while their horizontal dimensions are stretched by 6.4 times, resulting in a lot of visual flattening. I used Kittopia to produce new configs for Kerbin, Mun and Minmus that put more variety in the terrain without changing the overall heights of the mountains unrealistically, made hills and plains a bit more lumpy and restored some depth to the Munar craters and height to the Minmus highlands. But doing that results in a visible change when you get closer to the bodies unless you also generate new matching textures, so I created new ones in my download, hence my question.
I haven't visited anything outside of Kerbin's SoI since 0.90 (they keep upping the version just before I get there :D), but I imagine all the other planets and moons would experience the same flattening effect. I may get around to making new configs for them later, but it might have to wait until we have 1.1 and the raised memory limit before there will be enough available RAM for more files.
-
On 2015-12-19 at 11:57 AM, Dermeister said:
Are the textures for kerbin supost to look all smudgy? Perhaps I installed something wrong ?
Are you asking about the textures from my dropbox file or the originals that come in the 64k package? It's been a while since I put it mine together but IIRC Kittopia offered various resolutions for the scaled space files. Higher res files give clearer image but eat lots of ram, lower res files use less memory but are blurrier, for planet and part textures. Are you running ATM, that shrinks texture files from what I recall so that might be the problem. To me Kerbin is a little blurry in low orbit, but I use atmosphere and cloud mods so those are part of it. Munmus and Mun are clean for me.
-
On 2015-12-12, 7:14:41, TaintedLion said:
Ah thanks it works!
Also, for OP, everywhere just seems to be a bit flat now, like Minmus and other small worlds, and grasslands on Kerbin are almost perfectly flat. Any fixes to spice it up a little, get the stock bumpiness back?
Back on page 26 I posted a link to a dropbox file containing .cfg and .bin files that do just that. But you have to have kittopia tech installed, and go read the warnings, make a back up etc. or do not blame me for the consequences.
-
VTOL's aren't dead though. We can work around the new turbines, by mounting them on external thrust pods which hide them. We could use other engines. Hell, I can think of some cool ways to actually use those new turbines. They'd make a good aesthetic part, for sure. I can see people using them as exhaust ports and such. The greebling potential here is pretty high.
Easiest fix of all - back up the part folder and when 1.05 comes out just marry the new .cfg file with the old model.
A fantastic looking station is great, but if the frame rate is too low that takes away from the enjoyment, particularly by making EVAs and docking a pain. I do like the idea of having the end caps as they can be put onto other parts to make them more Fustek-like, but on the other hand I'd rather have one part per module rather than three (i.e. module + 2 end caps).
[1.0.2]HGR 1.875m parts(v1.3.0 released)
in KSP1 Mod Releases
Posted
Yes I suffered brain failure in my rush to get the desperately needed Radish pod back into my game. I should have checked Kerbas's Community fixes. Or posted it there if there wasn't any sign of a 1.1 patch being worked on.