sumghai

+1 Rep, subscribe AND Five star rating for actually having a WIP model already in-game. While these parts aren't exactly to my (usual) tastes, I'm looking forward to seeing how these pan out, especially Wanner364's Flightline Mk 2 - it is very Cosmo Falcon-esque.

Not if he keeps treating the forums like a chat room. Nah, I'm quite happy with my thread going dormant at times whilst I make real progress, not hype.

Not only had I obtained permission from him, but I also created a wide range of variants from scratch. My beef with these threads is that they are all talk and no show. I showed my progress visually in many, if not all of my posts and I do not promise release dates until I am merely moments away from uploading them to Spaceport. If that's how you feel, then excellent!

Interestingly, all this time you guys are defending him, he still has nothing to show for it. My point still stands.

YOU are the one that needs to learn to be patient and not generate false hype over WIPs you are not ready to show. In my FusTek thread, I only respond to answer very important questions or to post significant progress. If I fix a tiny bug, I wait until I've done a whole bunch of other stuff before posting them altogether. The only things I've seen in this thread are how you planned on taking other people's models without permission, making a cube fly with every single KSP cheat and a pointed stick that hasn't even been put into the game.

Don't keep telling people that there is an update coming, just show the update itself.

If that's possible, then it would be fantastic! Please, do tell (if and when you figure out how to do so).

Krag's Planets and Scaled Space thread is probably the tip of the iceberg. I see this all too often in the LEGO Fan community as well - you get one or two rockstar LEGO builders, usually adults with the money, time, skills and patience to pull off something big. This is then followed by literally hundreds of pre-teens with none of the above, but who want a piece of the action and the fame that comes with it anyway, so to speak. These kids start of by talking about how they're going to "maek da bestest laygoez eva", hype up other kids, and then post mediocre updates mostly consisting about how they couldn't do anything due to various real-life events. Substitute "LEGO" with "KSP mods", and you can see the exact same pattern. Now, I'm not saying that only adults are allowed to build good LEGO models or make KSP mods - I personally know of a very small handful of pre-teens capable of doing so. The fact of the matter is, wannabe modders need to put pictures of substantial work in progress out there first, to show that they are actually putting their money where their mouths are. Speaking from experience, that's probably not the best way to do modelling for KSP. As a postgrad with an engineering background, I am well-versed in SolidWorks and Pro/Engineer, which work in a similar manner as Autodesk in that they use parametric or feature-based modelling (i.e. you draw a sphere and specify dimensions that constantly get rebuilt by the software as you modify it). That's great for engineers, but very inefficient from a computational standpoint compared to software like Blender, which uses mesh-based modelling (i.e. you deform polygons together to make a sphere with whatever surface detail you want). When I first started developing my FusTek Station Parts Expansion, I did some very early mockups in SolidWorks and imported them into Blender for clay rendering. What I found was that models made in SolidWorks, Pro/E or Autodesk result in horrifyingly complex imported meshes for even a simple cube, cylinder or sphere - Engineering CAD software hides the complexity behind a facade of Engineering-friendly GUIs. I resolved to learn to use Blender properly, and in less than thirty minutes I had perfectly replicated fusty's original modules from scratch using the highly efficient mesh tools in Blender. Yes, Blender has a confusing interface and steep learning curve, but once one crosses that threshold, making efficient meshes becomes second nature.

I'll think about it.

That's pretty much how I play KSP as well - it a payload doesn't fit inside a KW Rocketry fairing, I either redesign it to be smaller, or break the assembly down to more manageable subassemblies. I had that in mind originally, but it seems that one cannot do animated interiors, at least from my understanding. Besides, the Kupola Cockpit variant will have slightly different geometry - in addition to not having the bottom taper, there will also be an actual, intentional emergency escape hatch on the side like the stock PPD-12 Cupola - this is so that the Kupola Cockpit could be used by itself as a minimal lander crew compartment, or mated to other fuselages as pressurized exploration vehicles / rovers. At some point (probably in R0.05a) I definitely want to make some foldaway landing legs that allow these modules to be laid down horizontally, but as a separate set of parts rather than built into the bulkheads. However, my present dilemma is that I also want to make some crab-steering rover wheels, designed such that if one module had landing legs and one module had the wheels, the wheeled module would be able to line up perfectly and dock with the module with the landing legs. On top of that, I'll need to make both fit inside a expanded 2.5 m fairing. One of my more successful attempts involved placing one module atop of a special lander base (consisting of a large probe unit, a flat fuel tank and lots of tiny engines). After landing vertically, I extend the module's own legs, retract one of the lander base's legs to tip the whole assembly over, then jettison the lander base. The now-horizontal module can now wait for a KAS crane truck to come pick it up and dock it to the rest of the Mun base. My biggest challenge right now would be building a very compact heavy-lift crane truck, again one that could fit inside a fairing.

It's more to do with an old EVA hatch bug. The original intent for the Karmony modules was to not have any EVA hatches at all (with the exception of the dedicated airlock modules), and have people use the Kerbal Crew Manifest mod to move crew internally between modules. Since not everyone would want to use certain mods, I decided to put EVA hatches anyway. Fusty's original Mk II Node models had a emergency escape hatch located on the side, which I found to be somewhat unrealistic, so in R0.01a and R0.02a, I instead reassigned the EVA hatches to the forward hatch mesh on the modules, where they would be covered up by docking ports. In KSP, an invisible collider box is used to determined the bounds of the airlock area where the Kerbal on EVA would spawn in - this collider also checks to see if the hatch is being obstructed by other objects, and if so, prevents EVA from that location. Stock KSP and most mod command pods have their EVA hatches very close to their part origins (<1m in-game). Because I assigned my EVA hatches to one of the ends of the full-length 3.75m module, this puts the hatches 1.875m away from the part origin, and as a result, the airlock collider boxes in my modules didn't work properly - at that point, a Kerbal would be able to EVA out of a blocked hatch and cause entire space stations to explode. As there was no other way of fixing this issue, from R0.02.1a onwards I decided to simply move the part origin up closer to the airlock, which allows the hatch obstruction checking colliders to work normally again. Obviously, it did have the unfortunate consequence of causing modules in already-launched vessel to shift their positions, resulting in many ruined flights for people. Most people here on the forums are (reasonably) understanding, compared with the vitriol I get from certain Spaceport users.

Stealth patch for R0.03a uploaded CFG change only - this lowers the SpareParts quantity in the Warehouse module down to 100, as the original 200 was too OP for the standardized size of the Karmony series module. If you do not wish to redownload the whole pack just for this fix, you can edit the Warehouse module CFGs to use the new (lowered) value.

Stealth patch for R0.03a uploaded CFG change only - this lowers the SpareParts quantity in the Warehouse module down to 100, as the original 200 was too OP for the standardized size of the Karmony series module. If you do not wish to redownload the whole pack just for this fix, you can edit the Warehouse module CFGs to use the new (lowered) value.

I'm not too sure about that - the Utilities is intended for resource monitoring and waste processing. By the looks of things, I'll probably do a stealth patch just to lower the SpareParts count, and let people attach Spacedock identifiers to whichever Docking Modules they'd like.

Gotcha. From 200 down to 100 it shall be. Should I just discreetly patch the files, or announce it as a R0.03.1a update? I'd like to think of the Warehouses as just that - bins for parts. Instead: - Players could add a Spacedock Identifier part to a Kirs Docking Module - Alternatively, I could hard-code the the Identifier PartModule into the Kirs Thoughts?

A bit of a shameless plug here, but for those who use OC and are leery about having re-purposed fuel tanks as SpareParts storage, R0.03a of my FusTek Station Parts Expansion includes a 2.5m diameter Karmony Parts Warehouse Module with a capacity of 200 SpareParts:

I share your sentiments regarding the confusion that would result from the original OrbitalConstruction Redux mod reusing stock models. A flat-ended version of the Kupola will be available at some point in the future, but not as a station/outpost component - instead, it'll be a lander / rover cockpit with its own IVA configuration and flight instruments. But that's for another parts pack.

R0.03a released - see announcements thread for download link R0.03a 22 July 2013 --------------------------- Features: - New Parts - Karmony Parts Warehouse Module - Karmony Node Cover - Karmony Node Cover - Viewport Variant - Kirs Docking Module - Kuest Legacy Airlock - Kupola Observation Module - Karmony Parts Warehouse Module is designed for use with the OrbitalConstruction Redux mod, and can store up to 200 units of SpareParts - Kirs Docking Module acts as a 1.25m diameter standoff for docking space stations with vessels that are unable to approach closer - Kuest Legacy Airlock is functionally equivalent to the standard Kuest Airlock, but is cheaper and lighter, at the expense of not rated for use on planetary surfaces - Kupola Observation Modules come with animated blast shutters to protect occupants from space debris. Most of the time. - The FusTek_Sumghai.dll plugin, specifically compiled to handle multiple animations per part, is now included in the pack - This was developed with the assistance of Snjo, and uses portions of his Firespitter.dll code Fixes - Tweaked rendering and collision meshes - This should greatly reduce the "freeze-on-drag" issue some users experience in the VAB and especially in the SPH - Model file sizes have consequently been reduced by up to 50% - Reverted to using PNG textures, which reduces texture file sizes and memory usage (according to some users) - Those responsible for sacking the people who have just been sacked have been sacked - Lowered ElectricCharge rate of Utility Modules to 15.0 / min - Older value was far too overpowered and had made Solar panels useless - Newer value now forces players to add their own solar panels and/or RTGs if more than three other modules are connected in the same structure Bugs/Known Issues - All crew-capable modules currently STILL use either the default generic "UniKarmony" or the stock KSP Cupola internal model - Work on module-specific unique internals will begin in the next version (R0.04a) - Karmony Parts Warehouse Module will be outfitted with animated cargo bay doors and internal payload magazine rack once nothke finishes making his KASPAR mod

crasher, you really need to stop treating the forums like an instant messaging chat room. Only post if you have WIP screenshots or real progress to present. If you don't know what certain posters are saying, either ignore them, or look them up in your own time. All I'm seeing here is a lot of spazzing and keyboard mashing, and not nearly enough development.

R0.03a released - see first post for download link R0.03a 22 July 2013 --------------------------- Features: - New Parts - Karmony Parts Warehouse Module - Karmony Node Cover - Karmony Node Cover - Viewport Variant - Kirs Docking Module - Kuest Legacy Airlock - Kupola Observation Module - Karmony Parts Warehouse Module is designed for use with the OrbitalConstruction Redux mod, and can store up to 200 units of SpareParts - Kirs Docking Module acts as a 1.25m diameter standoff for docking space stations with vessels that are unable to approach closer - Kuest Legacy Airlock is functionally equivalent to the standard Kuest Airlock, but is cheaper and lighter, at the expense of not rated for use on planetary surfaces - Kupola Observation Modules come with animated blast shutters to protect occupants from space debris. Most of the time. - The FusTek_Sumghai.dll plugin, specifically compiled to handle multiple animations per part, is now included in the pack - This was developed with the assistance of Snjo, and uses portions of his Firespitter.dll code Fixes - Tweaked rendering and collision meshes - This should greatly reduce the "freeze-on-drag" issue some users experience in the VAB and especially in the SPH - Model file sizes have consequently been reduced by up to 50% - Reverted to using PNG textures, which reduces texture file sizes and memory usage (according to some users) - Those responsible for sacking the people who have just been sacked have been sacked - Lowered ElectricCharge rate of Utility Modules to 15.0 / min - Older value was far too overpowered and had made Solar panels useless - Newer value now forces players to add their own solar panels and/or RTGs if more than three other modules are connected in the same structure Bugs/Known Issues - All crew-capable modules currently STILL use either the default generic "UniKarmony" or the stock KSP Cupola internal model - Work on module-specific unique internals will begin in the next version (R0.04a) - Karmony Parts Warehouse Module will be outfitted with animated cargo bay doors and internal payload magazine rack once nothke finishes making his KASPAR mod

InfiniteDice has stated on YouTube and elsewhere that friendly vessels will require an IFF part to identify themselves as "friendly".

At the moment, I'm using the stock KSP Cupola internal, so yes, the Kerbals are lying on their backs. When I begin work on R0.04a, I will be making a proper Kupola IVA with room for three Kerbals to sit upright like in the real ISS Cupola.

Progress Report, 21 July 2013 Added EVA handgrips to frames of greenhouse windows and implemented the top shutters. Fig 26 - FusTek Kupola Observation Module - Final Testing Now, while I did intend for the top shutter to be an iris, here's what happened: - Non-overlapping irises tend to be space inefficient, such that the retracted leaves cannot be discreetly hidden within the thin ring-like frame - The Stargate iris has the annoying spiked area in the centre where the tips of the overlapping leaves curl up into some wacko metal flower - OHS said no. - An iris design where the overlapping leave are constrained to not stick out the middle, as per this, showed some promise to the extent that a working prototype was tested in-game. However, the overlapping leaves had such similar Z-positions that the dreaded twitching of textures (AKA Z-fighting) occurred, which had the potential to impact in-game performance. Another problem was that the edges of the individual leaves could not be discerned at all, resulting in what looks like a solid featureless plate with a expanding and contracting hole in the center. For these reasons, I decided to opt for simplicity and have similar telescoping shutters at the top window instead. Some of you may also recall that I was trying to obtain permission from Snjo to include his Firespitter animation modules into my pack. A few forum posts and PMs' later, he suggested I compile a private copy of his animation modules into my own plugin, which I have done so and tested to my satisfaction. All that remains for R0.03a is some documentation cleanup and folder restructuring before I release the new parts next weekend.

Now this is one of the few suggestions that I would approve of - a taxi runway and a parking area for reusable planes that one does not wish to terminate the flight of.

I was *just* about to say that I did...