NovaSilisko

The term 'dry workshop' was invented after the wet workshop concept was decided against, I think. It specifically referred to the retrofitting of an S-IVB for Skylab.

The Idea: I've long had an interest in the Wet Workshop concept. For the unfamiliar, I'll give an abridged summary from Wikipedia's info on the subject... Kerbals have no qualms about living inside huge metal shells that reek of kerosene, so they certainly won't mind living in a fuel tank. Test version 0.1 download: https://dl.dropboxusercontent.com/u/575558/KSP/wetworkshops-0.1.zip Plugin source: https://dl.dropboxusercontent.com/u/575558/KSP/ww-source.zip Usage instructions included in readme.txt. At this early stage I'm just looking for testing its robustness, trying to break it etc. (Development info below, disorganized as usual) The plan: The idea is that there will be two part modules, WetWorkshopTank and WetWorkshopRefit. WWTank is what you might expect, a special fuel tank designed to be reworked into a living area. WWRefit is a module jammed full of instruments and equipment and air fresheners which can be docked with the aforementioned tank and used to convert it into a habitable area. This would remove the ability for the tank to store fuel and oxidizer, and enable the airlock to allow your Kerbals to enter the module. The refitter also requires at least one Kerbal to operate, to move things around and hang up the air fresheners inside the tank. Refit modules would work wherever they are on the vessel - we can just assume that Gregski EVAs all the stuff over while the process is going on. Speaking of which, ideally the process isn't immediate - it would take perhaps a day of game time, and the refit module would require occupation until the process is complete, which means that, unfortunately, you can't keep working on the conversion after you bail Greg out upon the realization you're not actually in orbit. However, the refit module can't be used if there's still fuel in the tank selected, so WWTank has a built-in valve that vents the stored propellant off into space, with accompanying unwanted thrust. A refit module can only be used once, and it's fairly heavy. You can either launch it with the first vehicle containing the refittable tank, or launch it on another vehicle. Game-wise, it would be fairly simple - right click on the workshop tank you want to convert, hit the "convert" button, and it grabs the first available refit module and begins the process, shown by a progress bar either on the staging icon or the context menu (not sure if such a thing can happen with the context menu, more research required). Due to technical limitations I don't know if it would be possible for the process to work when the vessel isn't active. The plugin work comes tomorrow, though. Tonight, I started on the models: The refittable tank. Holds somewhere between an orange tank's worth and a big silver tank's worth of fuel. Weighs a little more than a standard tank of its size would due to the windows and hatches and stuff. 2.5m diameter. The refit module itself. Weighs a little more than the big capsule. Also 2.5m diameter. I hope tomorrow to make a prototype plugin with the bare essentials. I've got a general idea of what needs to be done for code, though there most definitely will be unexpected technical hurdles. We shall see. __________________________ Update: Textured the fuel tank

I'll take "things likely to get you investigated by the FBI" for 400, Alex.

Erm. It's a 1-in-1 chance of flying past mars. Only a 1-in-120,000 chance of actual impact. http://en.wikipedia.org/wiki/C/2013_A1

Some general concepts for changes and addition that are drifting around my head (not to say this is the way they'll be though, we've all gotta generally agree what to implement and this is just my take! Plus discovery mechanics and hence the rest of the system won't happen for many updates) Jool: Actually the second-smallest gas giant, with unusually large moons. All other gas giants would have objects smaller than or comparable to Moho. - Laythe: Very volcanic because of its proximity and the tidal forces from the other moons. Still oceans of water, but now with actual active volcanos with lava lakes (that destroy things) - Vall: Never liked the design of vall too much. I'd like to make it a bit more like eeloo, with large cracks in the ice and a more chaotic surface. - Tylo: Never liked this either, also needs to be redone. Perhaps turned into a highly-contrasting body like Iapetus. - More tiny moons: Just a bunch of small moonlets, at least 20. Probably would be nameable by the player or given designations (ex. J-17 for the 17th moon of Jool discovered) Gas planet 2: ~50% larger than Jool, with rings. Early version shown on a stream a while ago. - Eeloo: Relocated to orbit GP2, now with large geysers that can knock your ship around (prototyped several weeks ago, they function quite well) - Daphy: Unusually smooth and round ball of fluff. An asteroid which has accumulated material from the rings, practically no gravity. - Potatus: Small moon with relatively high inclination relative to GP2's equator. Composed of ices surrounding a highly dense core. Very rapid rotation (21 minutes) causes it to be stretched into an oblate spheroid (prototyped a while ago, the physics actually work and are really cool) - Fonso: Largest moon, ~300 km radius. Very mountainous, with a thick atmosphere that only extends partway up the mountains (as in, the mountain peaks are in vacuum, while the proper surface is at two atmospheres) - Tiny moons: Same case as Jool Gas planet 3: Perhaps not an actual gas planet, could be a 2000km rocky planet with a thick atmosphere (have fun landing under 6g and 30 atmospheres of pressure) - Moon with rings? Would have to be diffuse rings as well as recent, fully-formed rings wouldn't last long in that position. Gas planet 4: Who knows. Beyond: Who knows x2

Possible, especially after a recent collision. But emphasis on the "recent", it wouldn't stay stable for long. Eventually they'd either collide and smush together into a larger moon, or split up and start occupying the same orbit (either settling at L4/L5 or, as before, colliding)

I for one really dislike lens flares, and love the clean look of these pictures. Huge lens flares really really detract from something for me, so +1 rareden for not going down that road!

Perhaps add an "other" option, the first landing I made was on something that doesn't exist anymore...

Perhaps a boxed copy kickstarter could work... The money that goes into actually making all the physical copies of the game come from those who want the boxed copies in the first place.

Do you guys think you'll change your name if you get into orbital flight? Just cross out all the "Sub"s on documents and spacecraft?

Which TGA format are you using? TGA_Uncompressed is pretty big. Edit: Updated the TGA entry a little. TGA_Compressed isn't very big, TGA_Smallest is even more compressed but lower quality. At TGA_Compressed, a 1024x1024 texture is roughly 2.5 MB. The larger the areas of solid color in the texture, though, the smaller the file size - a normal map with large flat areas of color can be down as low as several hundred kilobytes. For example, a texture here is 1024x1024 but only 166 kb in size. I will admit that they are still larger than PNGs, but PNGs import insanely slow with this bug. Bobcat's soviet pack for example takes (and I timed it) sixteen minutes to import... It also depends heavily on the computer - an SSD for example will, naturally, load it much faster. I would rather have a relatively long one-time download than 16 minutes of loading time at every startup.

Can we say that for certain? We know water was on mars but don't have any hard evidence that life existed there, we haven't sampled any of the subsurface oceans of Jupiter's moons yet, so we really can't say that water = life just yet. That's not to say it's not possible, certainly not, but saying it "almost always means life" isn't quite accurate.

Not a clue, rob mentioned it had to do with the WWW asset loading inside unity but I don't know the technicalities of it or if it's being fixed.

It may have been claimed by some accident... Normally it'd spit out a "[Magic Boulder]: Orbit Started" line in the console and I'm not seeing it.

Yeah, there was a plan to start transferring all the stock parts either internally to the game, leaving the cfgs exposed, or just using the TGA textures. Dunno the status of it though.

Gonna be posting some random bits of info here that people might find useful - usually fairly obscure stuff. 1. FlagDecal Put simply, this module lets you put your current mission flag onto a part. You just need a specific mesh that's UV'd correctly. The flag textures are imported from 256x160 and scaled up to 256x256, so it's as simple as just importing a random flag texture and stretching it to fit on the target mesh. Then, put this part module into your cfg: MODULE { name = FlagDecal textureQuadName = the name of your mesh in unity } And hey presto, you have a flag showing up on your spacecraft. 2. Docking port IDs I haven't looked into many mod cfgs, but a number of the ones I have haven't taken advantage of this when it would be very useful. So, for docking port modules, the cfg entry looks like this: MODULE { name = ModuleDockingNode referenceAttachNode = top nodeType = size1 } See that "nodeType = size1" entry? That doesn't actually have to be size#. It can be anything you want, then you can make ports that only connect to ports of that same ID, for your own docking systems. No way to make non-androgynous (requires two parts, which can only attach to eachother) ports yet, though. 3. PNGs import VERY slowly, due to a Unity bug I strongly recommend using one of the TGA or MBM settings for your exported textures instead of PNG. TGAs are just as editable, but slightly larger. For TGA I recommend the TGA_Compressed setting, TGA_Uncompressed is almost as large as an MBM. Have not tested TGA_Smallest but I believe the texture quality of that is fairly low. TGAs import a lot faster as they're using the same compression method as unity does normally[citation needed]. MBMs are not editable and are mostly uncompressed, so are quite large, but import the quickest. However, I haven't done direct time comparisons, so that would help a lot if somebody could get some direct statistics on the loading times for these different formats! More shall come as they're thought of/remembered/invented! Feel free to suggest anything, yourself.

Don't know when I'll release orion. Stupid thing just spins while in orbit for no reason, depending on your current roll. At certain angles it will start spinning at something like 5 degrees/sec and others it won't move at all. And it spins on launch, and while using radial engines, for no damn reason. 0.2%...

Methone.

Do an initial burn to about 75% escape velocity incrementally then do the final kick with your manuever node. Don't do multiple burns for the same manuever node, it breaks if you burn at the node on different orbits (dV indicator going upward if you do it one orbit around for example)

The solar system would destabilize itself over time with no other gameplay implications. Kerbin weighs 52.91 quintillion tons. Even gilly weighs 124.2 trillion tons. You ain't movin' that.

That's the thing - the overheat animation wouldn't really be affecting the pusher plate. It's just the material being animated.

How feasible would it be to set up the parts to use the normal unity animation system, instead of animating the pusher plate through code? That'd be a lot easier to work with I think, plus you could animate the bottom section of the plate as well.

It has to be a mesh. Just a transform won't do anything.

F9R = F9 v1.1 They're redesignating it.

The 10MN charges are too powerful and the 3.5MN ones are kinda wimpy, so I'm augmenting its liftoff capability.