Tiron
-
Posts
939 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Tiron
-
-
My game has been far less stable than past versions, but it was mostly due to having far too many parts added. I reinstalled and only added mods that were light on the part count, and now the game only crashes occasionally. It's easy to deal with now in comparison to before, but it would be nice if I could play with B9 and Firespitter again
The problem's not Part Count, it's the textures. Unity massively inflates the size of the textures when it loads them into system memory for some reason: ISA Mapsat's maps, for example, are taking up about 600mb worth of memory with an average file size of 2.11mb for the completed maps, and 32kb for the blank placeholder.
Somehow it's using ~20MB per map, when even an uncompressed 32bit bmp is only 8mb at that size...
I suspect this is probably part of why the loads take so long: It's doing whatever horrible thing it does to inflate the textures and loading them into the system memory.
-
Interesting. I've seen this bug before but this is the first time I've seen someone able to duplicate and document the process that spawns it.
So it's placing a singular, bugged article on the first click and then all of them on the second. That's interesting...
-
I managed to make this work, finally. Instead of having a folder in GameData, I just plopped the Plugins, Parts and PluginData into the empty folders of the same name under KSP_win. Also, they're in aerodynamics. Huh.
Uhhh...huh. Not really supposed to install it that way...You didn't have an old install lurking in said folders while you were trying to install to gamedata did you?
Also, 'They're in Aerodynamics'? There's no 'Aerodynamics' folder...
-
After having Mapped Kerbin, Mun, Minmus, Duna, Ike, Dres, and then Kerbin AGAIN...
567 Days, 20 hours, 50 minutes, 5 seconds. Unfortunately the other flight log stats seem to only be for this session, or something, because the Distance stats are barely 3 times the altitude difference between Kerbin and Dres, and the Maximum Altitude is definitely 'this session only'. Which is irritating.
-
Correct me if I'm wrong, but isn't the main problem with ISA MapSat is that it loads every single map texture it has into memory? The mod seems to work fine when I first start using it, and make my first map of Kerbin, but the longer I keep using it, and the more planets I map, the worse the performance gets. Last time I was using the dev build, I had mapsats around Kerbin, working fine, Mun, working fine, Minmus, working fine, Moho, starting to drag, and Duna, um, oh dear... and I was forced to uninstall the mod and go back to 3.3.4 to stop my game from crashing constantly. Sure, any mapping mod has to have a big texture around for the body being mapped, but it doesn't need a huge texture around for every single body in the universe at all times.
Also, were you switching probes while checking for memory leaks? I never had any problems with MapSat gradually consuming more and more memory while I just left it running, mapping a body. It did that without problems just fine. It was just when I was switching back and forth from mission to mission that things would start going south and eventually lock the system or drag FPS so low it was essentially useless... if MapSat wasn't leaking memory on mission switches, I'm not sure what else might have been, but I suppose it could be some other mod, and the increased memory use of MapSat just aggravated the issue that was actually caused by something else leaking memory.
No, I was mapping Dres, and consequently had it sitting focused on the one probe (the only thing I had up with mapsat even ON it.)
I do kinda tend to focus on one thing at a time, so I usually don't do a lot of craft switching.
And so far as I can tell, it actually loads ALL the maps into Memory, including the blank ones, when you load a craft which has an ISA dish/GPS on it. The PNGs on disk have an average size of 2.11mb for the ones I've completed. There's a total of 30 map textures, two for each planet, which would lead to an extrapolated total size of about 63.3 MB for all the maps. Somehow, when the game loads them, they're taking up TEN TIMES that much memory. Even 32 Bit BMPs at that size are only 8MB each, so it's clearly something more than that. I first started hearing reports of PNG textures having incredible memory use a version or two ago, and also heard complaints that it still doesn't get scaled down if you drop the texture quality.
When you get right down to it, the question is not so much 'why does it load all the maps at once when you load a vehicle with Mapsat', it's 'Why is Unity using 20mb per 2mb map'.
I also have yet to observe any increase in the size of the memory usage as I map stuff, either. It's pretty constant around 2,400,000 for me. With occasional excursions into the 2,500,000s and rarely edging on 2,600,000, most likely because I fairly recently added Modular Multiwheels to my repertoire(Dem landing Gear.) I've turned on the peak working set column to help me monitor changes in the amount of memory it uses, and so far I've seen nothing of note.
I'll set up a test for some ISA and Non-ISA ship swapping later, to check for those memory leaks. If there's anything particular involved I'd love to hear it as it'd help set things up (IE: Is two craft enough or do I need more than one? Does it matter if they're within physics range of each other or does it need to go through a scene load to get it?)
-
Well known issue, you're going back into the central stack after going out from it, big no no.
I dunno, some of my old designs did that, and it handled it fine...if and only if the symmetry coming out was exactly the same as the symmetry going in. 2->1->2? No problem. 2->1->4? Problem. 2->1->3->1->2? Problem.
I think they did mess with the logic since then though so I'd have to check.
-
The wheels aren't starting, i made sure the wheels are powered wheels, i also have engines and i supplied them with the correct resource. I also tried redownloading the mod but it is still not working. Could anybody help me?
EDIT: NVM! The first page LIED to me, you had to physically put the engine onto the wheels, awesome mod though
Actually you don't, but if they're liquidfuel powered engines the engines have to be attached to the fuel tanks, either directly or with a fuel line/crossflow capable parts. Monoprop and electricity propagate automatically throughout a craft, liquidfuel does not.
-
Thanks I have just tried it again on the run way and still same message I am using kerbal ver 0.21.1.276, I also do not see a grid on the moon mun
If there's no grid, something isn't installed right somehow. Remnants of an older version or something. Or I once put it in gamedata/gamedata/kethane by accident. It...almost worked.
Assuming you've hit the 'show grid' checkbox on the little green config window, that is.
-
This is kind of an old bug, I noticed it in MJ2 awhile ago, but never remembered to report it (just like I still haven't remembered to hack the hacked kerbals from the stupidity test out of my save, grrr.)
I've seen this twice, with the same basic setup: An 'inert' (no engines) probe on top of a 'lifter', with the MJ unit on the lifter. I Frequently end up with fuel left over in the last 'lifter' stage once I get to where I want to dump the probe at.
Trick being, when I dump the probe? The 'Lifter' loses the ability to calculate Delta-V. Turns into just NaN from then on. I suspect it has something to do with the probe having the root part, but I'm not sure.
-
Hi thanks to the info but I am in a polar orbit and the elect power is 1600 + and not reducing at all
I think with the new system it actually only drains power when it fires a scanner pulse...which it only does when it passes over a segment it hasn't mapped yet.
I think.
-
The above posters give good information. I would only add that since fuel lines tend to snap to the next part instead of past it, I have only been able to get past this (no pun intended) by connecting a line from the tank to the part that is in between it and the target, and then connect a separate line from that in between part to the target. It works, but you end up with more parts, more drag, a small bit more mass and something that may not look pretty. I try to tuck these things under wings or otherwise where they are least noticeable (if possible).
I'm pretty sure fuel ducts don't actually have mass or drag, much like struts. Also, you may not NEED the second fuel line if your target is connected to the part that intercepts the fuel line: Fuel lines attached to a part make it able to pass fuel, even if it normally isn't.
Attach some launch clamps and do a static test, it might actually work anyway.
-
Nuclear Engine. Bill
-
Since the duct is external, I'm not understanding how the decoupler is blocking anything. I've gotten around this by using the smaller TR-18D decoupler that doesn't fully extend outward, so the two tanks will link up via ducting. But this can't take a lot of stress, and really, I physically shouldn't have to do it, since external ducting should extend around the plane of any decoupler.
It seems to be a problem, since decouplers of course don't automatically pass fuel through, so a fuel line to a decoupler would be useless, (I am thinking anyway).
And I want to remove the engine and fuel tank once I'm in upper orbit, as the 2 big orange tanks are meant to connect to a fueling station.
(But I've had this issue with other designs where the decoupler in the middle of the stack blocks fuel ducts from tanks further up the stack. So this odd design shouldn't really be an issue. I am still learning of course.)
It works like the struts: the duct is drawn in a straight line between the two attach points. If something gets in the way of that line, it attaches to that spot instead of where you clicked. It can't 'route around' anything.
-
I named it after a Relevant NASA probe.
-
KSP is a single player game and the enjoyment each player finds in playing with or without certain mods is entirely subjective. That said I'm with Mihara, ISA is not worth keeping in my game if it performs as described by many others. Fortunately I have no life and I've gotten pretty good at balancing my mods. I'm currently running 45 mods including KW Rocketry, Universe Replacer, and ISA X4r1 (I'm only counting mods with textures). I've trimmed some mods and done many of the things others have suggested to get my game running around 3.2GB. For this effort I rewarded with a KSP that only crashes about once every ten hours or so. Still KSP gets very unhappy anytime ISA is even thought of not to mention the other bugs Mihara doesn't get to see. Sorry Tiron but Mihara's right. ISA is still available if you can get it to work but we need a new plugin.
Actually what we need is a way to get Unity not to convert the textures to uncompressed bitmaps, thus massively bloating the memory usage. And a 64 bit build that's stable. Both Unity problems (although there's speculation there may be a way to use a plugin to use DDS textures.)
And seriously, I'm NOT seeing increasing memory usage as the game runs, it's very near constant. If you're seeing increasing memory usage over time it's likely that one of your installed mods has a memory leak. And a bad one, if it's burning up 700+ MB in a few hours.
After running the game constantly for a bit over 26 hours, I saw less than a 150mb increase in memory usage, despite the fact I was actively scanning every time I checked it.
Edit: With 1 ISA Mapsat equipped ship in the air that I haven't focused yet in this instance, I'm running just shy of 1,900,000 KB. Most likely because it hasn't loaded Mapsat's assets yet.
The problem is not Mapsat, it's Unity bloating the textures, probably mostly the map textures themselves.
Edit2:
I should further note that any Mapping mod is going to encounter the same texture memory bloat problem, because you HAVE to have a texture for the planetary maps, and it has to be fairly large if you want any kind of detail.
Edit3:
Yep, when I loaded the craft in question, the memory usage blew up to around 2,600,000, with the game exhibiting symptoms of 'waaah you alt-tabbed', like it was late in my Dres mapping. I'll try a quick further experiment, no idea if it'll work or not.
Edit4:
Surprisingly, it did. I stripped every single texture ISA had, the GUI, the parts, everything, except for the map textures. And the 'Sun Textures', which he's apparently loading Dynamically off the NASA website, which is actually kinda cool.
Note the white dish and the lack of any GUI at all other than the box itself and the text, which are both built in features.
Memory Usage? Peaked at 2,466,508. Maybe I'll try blipping the models too, but I doubt that's going to have much effect.
In any case, it looks like almost all of the memory usage is...the maps themselves, bloated by Unity converting them to Bitmaps from PNGs. Either that or the 'pull the sun images from the interwebs' thing is using a LOT of memory.
Edit5:
I don't like telling people things that are actually wrong, so I went and figured out a way to test it: With all the textures gone, I created a 8x8 square of red pixels in png format, and then laboriously copied and renamed it as if it were the map textures, replacing both ISA and Polars for every planet, as well as noterrain.png, blankmap.png, and mapbg.png (I think the last was unneccessary). I did all this because I thought that part of why memory usage was so high is that it was creating/loading blank textures of the appropriate size (2048x1024) for all the blank maps and holding them in memory, if not saving them to the hard drive like it used to.
Basically, I tricked it into loading very small textures so it wouldn't try to create new, big ones (which is what it's designed to do, that's how it works after all.) The result?
Upon loading the ship with the ISA dish (I wasn't able to delete the models, it pitched a fit), the memory usage spikes back up to about 2,400,000. And then immediately drops off...to 1,800,000 or less, about what it is without ISA installed at all(Almost like it's allocating the memory for the expected size of the textures and then realizing it doesn't need that big allocation after all.)
In short: the plugin itself uses very little memory: That hogging actually IS almost entirely the textures, specifically the extra-large map textures. If you really wanna cut the memory usage you could crush the resolution on the map textures down, at the expense of losing detail on the maps.(Make sure you use sizes that are a power of 2 if you do this. I don't know for sure that it's a requirement, but it's fairly likely that it is.) It'll probably still spike pretty high on initial load, but then drop off, which should still help if a memory leak from a mod is your problem.
Just as one final test, I gave it back everything, all the textures, except for blankmap.png and the topos. Memory usage: peak 2,444,160kb, fell down to: ~1,835,500
-
Parts hanging off the bottom of a multi adapter can be connected with struts, so can more parts hanging from those parts. So why couldn't the parts like this be connected with strut type bonds?
You mean like multidocking does with the 2nd and subsequent port pairs that lock together?
-
There is something in the VAB I'm having trouble with. I have no trouble attaching a radial part to something like a fuel tank, for example attaching a radial docking port to the side of an orange tank. I also don't have any trouble correctly attaching a matching radial docking port to the first one (with the correct side attached). However I can't seem to find any way to attach another orange tank to that - I basically want 2 orange tanks linked together by radial docking ports.
I've tried clicking and moving the orange tank onto the already assembled docking port pair and I've tried linking an orange tank with docking port to another orange tank with a docking port, both by dragging the orange tank and dragging the docking port. I've tried rotating but the tank always wants to fly around and attach somewhere else as soon as I bring it near the docking port.
Is there a trick to make this happen?
Not that I've ever found, unfortunately.
best you can do is like, use strut cubes to rotate the node connection. :|
-
Regular, constant, reliable out-of-memory crashes whenever I fly or launch, or even as much as remember that a vessel with a MapSat part on it exists. Without MapSat, it takes most of a day of playing before KSP's memory leaks finally catch up with it, with it, an hour is sufficient.
Really, what else could be wrong with it when I say "memory use is too high"? I'm honestly curious, I might be missing some other potential irritation that I don't see because my KSP process doesn't live to see it.
Well, there's why it works for you, and why it doesn't work for many other people -- by far I'm not in a minority here. For me, the information MapSat provides is not worth the inconvenience of playing without part packs.
My general thought would be that the problem is the parts packs, not Mapsat itself. Texture files are the number one user of memory, and parts packs have a lot of them.
But seriously, even with the other mods I *do* have, There's still nearly a gigabyte and a half of memory left for other things. That's a LOT of memory to play around with. If the parts packs you're using are hogging up that much, then the parts packs have just as much of a memory usage problem as Mapsat does.
The ultimate cause probably has to do with the many bug reports there's been recently about png based textures causing insane amounts of memory usage ingame, and it not being affected by turning the texture quality down. ISA uses PNGs for the maps...
And memory leaks? I've never noticed any substantial memory leaks. My memory usage has historically hovered around 2,400,000 for KSP, regardless of just about everything. The memory usage actually DROPPED after I made my previous post and ended up in the high 2,500,000 range, and this after having the game run continuously for almost 24 hours straight! (Mapping Dres takes FOREVER.) Could it be that one of your other mods has a memory leak and that's what's causing your problems?
Now then, I'm going to measure Mapsats' memory usage. I've removed the ISA folder from Gamedata, and manually edited persistent.sfs to pull the mapsat dish off the one probe that's using the part, to minimize the difference between the save files.
Without ISA, at initial load, I'm getting memory usage by KSP of 1,786,500 kb, or so. Climbs to a little over 1,800,000 after a bit.
With ISA re-added (and my original save with the dish restored) I'm getting 2,478,500...and then dropped to 2,462,400 after a bit. And back up again to over 2,488,000.
So Mapsat's using about 700 MB of Memory. That's quite a lot more than I would expect, yes, given the folder's only 26MB it's really a bit hard to fathom.
The key thing here though is your parts packs have to be taking up around a Gigabyte to even get near territory where you could get an out of memory error at all. Secondary, you've got the fact that my system with relatively few mods only had the memory usage about 100mb higher after a full 24 hours of mapping, so you're either right on the razor's edge to start with...or one of your mods that I don't have has a major memory leak in it.
Edit: Actually, it was more like 26 hours of continuous game running, since I posted that I'd just dropped into Dres mapping orbit at 8AM yesterday and posted this at 10AM today...
-
That's weird, but I have had similar things happen to me. I had a lander impact the Mün's surface at ~200m/s and it just bounced and flew off with no damage.
I've only had it happen with Mod-added parts that were, for whatever reason, completely invulnerable to impact damage. The old Bigtrak rover and its Cuttlefish lander for example.
I screwed up the setup on the Cuttlefish, or staging it, or something, and lost the engine. So I bailed the rover out and went down with just the rover, just for fun. I bounced, skidded, tumbled, and rolled my way to a stop on the Munar surface, having lost most of the parts attached to the outside of the rover. I went on to deliberately crashing the still-closed lander into the surface in a power dive. Did the same thing on Kerbin right off the launch pad. Tried crashing it into the water. Literally nothing would destroy those bigtrak parts.
Ran into this more recently with the super-large 'caterpillar tracks' module on a design one of my friends was having trouble with. I got it off the ground, but it didn't have enough lift OR thrust to fly, so it ended up in the water. Everything died EXCEPT the track module.
Try crashing that same plane into the ground, I'll bet the same bit of it survives.
-
Oh alright, nevermind then.
I'll try it with docking ports, see what works better.
I'd wager the struts: The docking port bit really works better when you're trying to build circular structures or something.
If that turns out to the be the case you can probably use just ONE decoupler, use the struts to keep it from flopping, and save a bit of weight. It'll unbalance the weight and drag very slightly, but the SAS should be able to cope with it. It'd also give you only one set of fairings instead of three, so you'd have six fewer pieces flying around at decouple.
If the mass/drag is a problem you could get the same effect with balanced mass/drag by placing the decouplers individually, on the tri-adapter instead of on the bottom of the engines(Except the first one, which the tri-adapter is itself attached to). That way they don't detach when you stage it.
-
You sure? Because I have tried it without struts. It just wobbled too much. I figured the struts would stabilize it. But I could get into orbit without the struts.
And the struts get deleted the moment I detach the orange tanker anyway.
Yeah. The game's not capable of doing node-to-node connections with multiple parent parts. Two of the stack separators aren't actually attached to the tri-adapter at all. They look like they are because of physical proximity, but there's no actual connection. That's why it flopped without the struts.
The struts form a physical connection that prevents it from moving. Docking ports like in my screenshots would do the same thing, although probably a tiny bit floppier than the struts.
-
I think I found the solution to this problem. Well, I'm not taking the credit. But docking isn't necessary, that's what I have found out.
See this thread: http://forum.kerbalspaceprogram.com/showthread.php/48147-Nuclear-engines-and-tri-adapters?p=624153&viewfull=1#post624153
As you can see, I had the same problem. I explained here how I solved it:
And here is the picture (note that the craft in the picture does NOT work. Please refer to the quote):
*Snip*
Again, it works fine. No exploding engines. They are all attached.
If you guys want, I can upload the .craft file. But I think the picture + quote speaks for itself.
If all you did was swap the decouplers for stack separators, no, it's not attached, at least on the bottom. You could in fact remove all but one of the stack separators and it would work exactly the same way it is now: The only thing keeping it together is the struts from the top section to the orange tank. This accomplishes essentially the same thing as using docking ports would.
-
One thing to note though is that because of the LV-N's high mass, for ships smaller than around 9 tons you can actually get better delta-v out of the 24-77 radial engine, or the 24-77s.
Hmm. I should investigate this for my mapping probe(The one I mapped Kerbin, the Mun, Minmus, Duna, Ike, and Dres with, and am probably going to remap Kerbin again with.) I can see why this would be the case though: The LV-N weighs 2.5 tons, the inline 24-77 is 0.1 tons. My upper stage only weighs 5.21 tons, so literally half the weight of the thing is the bloody engine. And that's such a massive weight reduction, I can see where it COULD have more Delta-V after. Though the prospect of using a tiny engine on a size 1 probe...heh.
Edit: Oh dur, it's only 2/3rds [Half (specifically 53%)] full...because I used it to get from Duna to Dres...But still. That's a huge fraction of the weight for the engine.
-
Remember, there's no friction. If you're moving in a direction, no matter how slowly, you will not stop or slow down unless you either: Hit something; Use your thrusters again.
As a result you need to do two things to fly around on EVA effectively:
1.) Be patient. Going faster makes it harder to be precise and uses more fuel.
2.) Think ahead. It takes just as much thrust, and therefore just as much time, to stop as it did to gain the speed in the first place. This means you need to be counter-thrusting to kill your velocity BEFORE you get to your target. How much before depends on how fast you're going, but it's exactly equal to the time spent accelerating up to that speed in the first place.
Loading is too slow, especially texture loading
in KSP1 Suggestions & Development Discussion
Posted · Edited by Tiron
Most likely it's caused by the fact that it does SOMETHING to massively inflate the size of textures:
ISA Mapsat's maps, for example, end up taking up about 600MB of RAM when loaded. That's 20MB *per Map*. Compressed, they're around 2MB each(Except the Blank, which is 38 kb.) Uncompressed, about 8MB each. Uncompressed with the Mipmaps in VTF format came out to 10.6MB. I have yet to see the memory usage vary substantially based on the number of completed maps, which is a good indicator that it's probably loading even the blanks as uncompressed textures.
This is a pretty good indicator that something really goofy is going on, like it's upscaling them AND uncompressing them, or something similarly stupid. No wonder it takes awhile to process.