Nertea

Well, here's how I see it: 1 Ec = 1 kJ. 1 Ec/s = 1 kW. So NFT and KSPI are actually quite compatible here, because 1000 Ec = 1000 kJ = 1 MJ. As I think I mentioned somewhere, there's another electrical metric (I think it's Realism Overhaul) which also uses this equivalency. So I don't think there's too much trouble to leave it at is. The problem that's surfaced is that the display in ORS at some point shows a MW value that should really be showing kW (or Ec/s). Generally KSPI runs all of its tech from the MJ resource because of high numbers, and the fact that having the dedicated resource allows a manager to run it without interfering with anything. I think Fractal at one point said that the Ec system represents the ship's DC electrical, and the MW/MJ system the high-power electrical system. KSPI reactors also generate Ec when the ship needs it from their own generators, and (I think) the capacity also exists to turn Ec into MJ. In NFT I try to stay away from specifying power use in kW, MW or anything. It's more player-transparent to show it in Ec/s, when the player may or may not be using other mods that use different names for the same thing. Aside: As I remember when I was originally setting it, looking at the stock parts such as panels, the PB-ION (pre-buff), the RTG, the lights... 1 Ec/s = 1 kW is approximately correct to RL when you average across everything. If you dig around in my WIP or my release thread, there should be some posts about it if you're curious.

That's more of a balance paradigm thing than compatibility. Given the tech that KSPI is running with, the MW numbers aren't ridiculous; given the tech I am running with, the numbers are fine. I wouldn't even consider unifying these - either way, one of the two mods would feel weird. Good to know. Is the ISRU stuff the only area where there would be a problem?

There are only a couple of specific conflicts, noted as follows. ArgonGas vs. Argon My ArgonGas has 1% of the density. I would argue that KSPI's is supposed to be gaseous, because most of the other definitions do specify Lqd in front of them. The reason the densities are so different is probably because of the LH2/LF problem... base your density calculations off one assumption and you get big differences like that. Because well, I've done a lot of work with NFT's argon storage tanks, I would say to use my density (which is based off stock Xenon and should be independant of the LF/LH2 problem). Also correct me if I'm wrong, but KSPI doesn't use argon much except as a plasma engine propellant, and lack significant tankage for it. (KSPI Nuclear Fuels) vs. EnrichedUranium Because nuclear fuel type is a key mechanic in KSPI, I don't think it can be unified. However we could unify on DepletedFuel vs DepletedUranium. I don't see any problem with changing mine, provided we agree on a density. LiquidFuel vs. LiquidHydrogen The big one, of course. Some of the bits of KSPI are I think highly integrated with this assumption, some are not. Not sure what to do here.

Hey WaveFunction... if you're going to fiddle with the KSPI resource distribution at all, what's your stance on working with me to unify a couple of the NFT/KSPI resource overlaps? I'm not sure how reasonable it is (that LF = LH2 thing is tough to work around), but I figured I'd ask.

Thanks guys Probably one of my favorite stockalike texture jobs yet (much better than that other command pod...). I think I'll have to redo the other one sometime Yeah, that's how the crew orientation's going to be, except I upgraded the capacity to 6. Two pilots, one on either opposite side directly facing out the windows, and four passengers arranged around the other two windows. It was feeling pretty empty for the size. I might have time to finish up a mocked up IVA in the next day or two; if so I'll release it then for testing.

I surprisingly had time to texture it! Normals to follow. Then I flew a pair to the moon! Performed flawlessly.

Yes, it would look better. Working pretty well ingame. Makes a very cute lander! Some tweaks since these pictures - better polygon flow/smoothing on the windows, ladder spacing adjusted to be more like the other two parts. It also has another attach node inset into the back so that a 3.75m part can be attached flush.

Glad ya like it. There might be changes to the windows too - my parts are in flux until I unwrap them, at which point I become highly resistant to change .

I haven't completely decided, but I think it will be quite spacious, with each of the 4 crew directly below a window. Maybe 2 control seats (throttle, etc) and 2 instrument seats (more screens and buttons)

Some very pretty texture work there Stevie_D .

I didn't see that post there, sorry. So, late answer! No, I'm not planning on changing the collision boxes. There will be a 3.75m reactor in the next NFE version, but I don't intend any 3.75m engines. It's time to get started on the results of the poll (Deep Space/Station Parts)! Well, technically that expanding solar array is already one. I'm going to start with the planned inline command pod. A confusing part, the IlCP will be designed for 2.5m stacks and provide good visibility, even when stuff is stacked in front of it. It will not really be designed for re-entry (warranty totally voided!) The model will probably get more details before I texture it. I'll be making the texture (and possibly the attach nodes) in such a way that it will look good both in a 2.5m stack and on top of a 3.75m stack, so it could double as a 3.75m command pod. It's about as tall as the Mk1-3, so I think I'll probably have it seat... 4 kerbals.

Near Future Technologies resources for your reference, if you need it. ArgonGas Cost = 0.25 Density = 0.00005 Flow Type = Stage Priority Flow LiquidHydrogen Cost = 0.75 Density = 0.0004 Flow Type = Stack Priority Search Polytetrafluoroethylene Cost = 1.0 Density = 0.000072 Flow Type = No Flow EnrichedUranium Cost = 50 Density = 0.005 Flow Type = No Flow DepletedUranium Cost = 0.0 Density = 0.005 Flow Type = No Flow StoredCharge Cost = 0.0 Density = 0.0 Flow Type = No Flow

Just a heads up - working on Jumbo-64 and Rockomax x32 sized 2.5m tanks as well to keep the styles common.

Not something that's going to get done for a few days, but here's the model of the 1.25m converter: The exhaust fan spins and the radiator plugs pop out and rotate when running.

I'd suggest actually using STAGE_PRIORITY_FLOW for Karbonite if possible. It is still all vessel, but it tries to at least a bit obey staging rules, so would make a staged craft with Karbonite engines easier to deal with.

I'm not 100% happy with some elements of the drill's texture (nor the ventral one really), so I think they'll get another pass in the future. But otherwise, I converted one pot of coffee into five models!

I'm not certain I'll be able to finish those parts before Sunday, but you can launch without them if you like.

Everything mirrored is instanced, so that's what I'm effectively doing . I prefer to unwrap at the end generally, it helps me lay out the texture sheet most efficiently for baking.

So I just kept detailing, and radiators, and then more radiators, then doors, then.... well, this is going to be an unwrapping pain. These are more boring, but still serviceable. They all match the stock 1.25m tank lengths.

Ok, I'll go for the drill then. Should be able to get it done... I have two other 1.25m tanks modeled but not unwrapped - I'll post pictures later today. Might be able to sneak them in by Sunday.

The FL-T800-sized 1.25m tank is pretty much done, could probably finish one more part before this cutoff time, if that's tonight. Would people like a bulky radial drill or the 1.25m converter?

It... might? Depends how scansat stores data. I'm sure it could be adapted. Gradient is the same thing - the biomes affect the procedural generation of deposits - for that example in those images, ice caps and ocean don't generate any deposits, and mountains generate lots.

I am cunningly not showing the polar pinching . I'm actually not 100% sure how ORS avoids this (I suspect it doesn't) as it uses rectangular maps also.

I did some coding-type stuff for ORS some time back, and just spent an hour making it actually kinda work. There's two components, an overlay visualizer for concentrations and a procedural deposit generator. The first draws a large sphere over the planet and maps concentration values to a color value pulled out of a color bar (specified per resource, showed two examples below). The transparency of the overlay is pulled from the color bar's alpha, so it can be transparent at low concentration, as I did in the pictures. The second one generates perlin noise deposits with an option to use biomes to control the distribution (can specify biomes that have less concentration). Still tweaking these values, but works pretty well so far. Currently it's just a Unity prototype, but it works pretty well and the deposit map generation isn't too slow. I'll clean up the code in the next few days and give it to RoverDude, see if he can make something out of it.

Ok, RoverDude, if you want to add this to the first post so that people know and there's no duplication of effort, I am working on... FL-T400 and FL-T800 sized 1.25m tanks Large radial drill Small radial drill 1.25m converter Small radial detector dish Karbonite jet engine (though I'd gladly let nil2work take this one over for continuity with the rocket engines) Working on = has a sketch .