Justin Kerbice

Hi, not a surprise, and 400 parts is not very so low. I have also a similar performance issue with similar parts count. CPU is everything in this matter for now with KSP. If you can, and can afford it, a CPU upgrade may, or may not, improve this. On the software side, you can close as many programs as possible to reduce the number of software that require CPU care, the most CPU cycles KSP gets, the faster it will be able to calculate physics stuff. Or set affinity to other cores for others software.

Hi, when seeing this: I was quite surprised, this is quite weird and not very professional using mesh and MODEL at the same time could lead to issues if it's not already the case, calling a model "NewModel" is not very good and the weird rescaleFactor chosen + rotation and position in the config could lead to major headache if someone later has to work on it. There was a cleaning operation according to some devnotes, there's still work to do I guess. By the way, it doesn't have a ModuleTestSubject, so no contracts asking for testing it.

The Joker new crazy evil invention, don't smoke the gas behind .

Thanks . This is very interesting, to me. A lot more better than looking at upload bandwidth in use (I use the small perfmon4). EDIT: could it be possible to set up a dev website, as I see dependencies is quite a long list and I'm not use to set-up web server and website made with Python, it will make life easier for people who wants to add features or bug fixes. On the expense of make your life a bit less easier.

Good idea, reading you, I just imagine kind of a Simple Part organizer or PartCalatog for crafts, in term of UI. in fact PC style would be the best, a place where we could create folders and eventually tags, pick a craft and move it in a given folder, ... With the best bonus feature: a thumbnail of the craft. So we could sort crafts by mod used (automatically recognized, maybe as tag) or any other criteria.

A dummy tex could also be 2x2. Not fully true. Even the old (even obsolete) gMotor2 engine used in GTL/GTR2/GTR EVO/rFactor and a few other sim racing game can manage a lot's of material per mesh (usually between 4 to 7 or more) with 20000 polygons or more cars, many cars at once + the track itself with many materials too, lot's of tex, blending (like KSP bodies surface textures) without the need of a hardware which is not available yet. And as almost everything is limited by the CPU (the 1st core), GPU could have more duty to do, a lot more. Take a look at DX11 Nvidia demos, tesselation or Islands for example.

FireSpitter's FSfuelSwitch module allow such thing, take a look at the documentation, you just need to edit config file yourself or use a Module Manager "patch" to do it.

@TMS: great !! Thanks a lot . This might be added to the TODO list I guess .

Does someone know how to add an imgur album on mod description ? Thanks.

It would have been better if we have more than one ugly and big radial attachment point . Plus this mini cube and the rockomax hubmax may have some special mark on top/bottom face to let people know where it can be attached instead of either fighting to get the right face in the right place or just put all those parts in a big dump and melt them all for good.

That's liked to the mode EE use. In order to swtich from VAB to SPH or the opposite, it "cheats" a bit and play KSP to let believe you are in one or the other facility, making saving a VAB craft in SPH mode to have SPH in its data in the file (type = VAB/SPH at the beginning). This also make "revert to" going back to the facility linked to the chosen symmetry mode and not the actual building facility. But it looks like Nsomnia explanations are quite messy and tainted by angryness so not sure if it's helpful at 100%.

Nice, it could be even better by providing a grid with some scale value (dynamic or static), a major line every 100 MB, minor every 10 MB for example.

Without something new you can also use MJ case with mechanic_jeb something from GavinZac, I know a kerbal with a MJ case on his back, but you have all MJ feature as bonus (not sure how MJ will deal with that, better not to try !)

Thanks a lot, I have missed this one !! By the way, to get the right name for material/shader: in Unity editor itself, assets->PartTools->Shaders, properties (may be on the right side): "<name> Texture: <the name here>", is the one to use. (in my case I have: _Emissive Texture: _Emissive), both before and after "Texture:" seems to always be the same so any of them could be use. This should be added to your google document (maybe just the list, as it will not change soon enough I guess)

@snjo: using FStextureSwitch2 (FS version: 7.0.5283.33887) with a config like this: Make the dwing-emissive map use for all tex in the set, null-emissive tex (a 2x2 black tex) is loaded but in log there is only these kind of info: Which are not very helpful. Could it be possible to add more useful debug messages ? (map use at least) cause here, we can't see which map is used with which tex and 'map exists in db' is as useful as 'Parsing string/bool/int' from stock game !

I surprise no one already tried some Kraken-Drive thing like this: That's doesn't work very well (two sets of surface repulsors which push against each other), height 4 or 4.5 are ok, below, nothing, above: boom boom . This is not strictly speaking a kraken-drive thing but I'm sure some people could get something better than just with stock landing legs. There is my Rover 'N' Others parts, the next set, Y, have 8 and 16m long part, this last one looks even huge compared to the JB64 fuel tank. But they both looks "wheel" with your LargeWheels. T-2 and T-3 are good also to make mobile launch platforms (with EPL or even stock with a simple decoupler and something above it)

You're welcome. Here it is: (your mod deleted but I see a config file remains) For what it worth, I play only windowed mode in 1280x960. But I can only imagine such graphics issue comes from some dirty code or wrong assumptions (regarding screen size !! that's may be the trick !)

Tried it today: don't know if there is some dependencies issue or something else, lines goes outside the window on the left side and there is many stock toolbar icons added on every single launch. Interference with another plug-in ? (KSP 0.24.2.559, win7) + I really don't like the sticky controls, it makes things worth (they doesn't looks like to be fine as set, 1/4 looks like to create the same amount as standard key stroke) :/.

Because the z-100 "light" is not one, it's just bright yellow/orange colour. MJ case use a light.

So what you suggest regarding checking files and update only when needed is called 'rsync' and already used by patcher, there are even API to rsync I think. And yes, I've already made a terribly ugly heavy package with PAR for a big Perl project on solaris if it was not already enough and that's sucks a lot. Looks like language with "easy-and-fast" code have to be balanced by "ineffective-poor-bad" executable burden (except on unixes). Which is very sad because doing such features rich in "better-for-delivrey" languages is a lot more work. And I'm not sure C# have yet everything needed for easy and fast coding.

Great work SirCmpwn, it would be nice to add download size in mod display (just saw B9 is coming, I know it's quite heavy so...)

Sounds great, it would be great to have also the TimeOfDayController thing which seems to doesn't work on current Kerbtown version (razcheck wrote a few words about it in his thread but never see one single building with this) and the launch clamps issue is quite a "legend" As opposite to stock launch site, Kerbtown is a bit lazy and don't do the clean-up for us. There is also the camera issue: after adding a building camera move back and forth pulsing like a heart (I know it sounds weird, it's weirder to suffer from this issue ) A nice feature would be auto-align to the ground (set thing to ground level by default).

Light like the z100 may just have an emissive texture + KSP/Eimissive/something material in unity, eventually a small point light which will be always ON. Models SHOULD use more vertices/triangles as stock, as GPU wait most of the time the poor enslaved CPU (thank to single threaded physics from unity). Why making an ugly, (very) old school 24 sides cylinder when you can made a 32/48 sides one ? Search for High Poly Test Object there to see the result of using a lot of tri with a few physics instead of lot's of little polys with lot's of physics. Concave space is up to you if you want to allow "open spaces" or not. Yo get it, you need to create as much as colliders as needed but here, complexity REALLY MATTERS, as 3-6 colliders for one part is ok (but may not be so ok if this parts is used multiple time like seen with the stock Claw issue not so long ago with 8 of them at the same time). I tried 16 colliders on one part... KSP don't like it that's much (huge slowdown already in VAB/SPH). In fact here, it looks like Unity has been designed to make minecraft type game because when you read colliders' definition, they succeed to make colliders which don't collide at all (if not convex) ! Amazing, isn't it ? Why making collider, that don't collide ?

Warning : this comes from Skyhawk, not me, keks quotes him wrong and credit me for these sentence. I deny any involvement in this . If your concern is checksum, best is to use the fastest checksum tool available in each platform like: UNIX=md5sum WINDOWS=somethingsum MACOS=macsomething MD5SUM= one of these (it could be a hash for example) and a subprocess call like in Perl: $checksum = `MD5SUM file`; (with proper checks, before, while and after of course) C# is not the only one to allow you to parallel-ize your code. And before even thinking of language performance, thinking first and do smart things is a lot more better. Why calculating sum for EVERY files in GameData on update ? You only have to check mod X folder(s), and even less: only files that need to be checked. (Why for Jeb sake you'll have to calculate sums for files you don't care about like all stock parts/props/tex/... ?) And... I have a big doubt, do you mean this tool is suppose to run as kind of plug-in INSIDE KSP ? Whatever the language used, you can always made a executable which ship everything needed (Perl have the ugly PAR which make big, very big, executable from small scripts). I think you're going the wrong way and maybe think a bit too much, the best would be to define already something to work on with a minimal features set, but WORKING and USABLE, not the best tool on Earth and Kerbin which is just a wish in your mind. Iterative development model like KSP is great for complex projects.

Looks good, but the sticky/non sticky controls has to be added soon I guess, as it would be too annoying to add the exact amount of opposite roll/pitch/yaw to get back to zero. Maybe you could take a look into lo-fi's wheel/many things plug-in for smooth steering (made or rover control).