Wallygator

Hmmm perhaps a bit too esoteric for most. Sorry for the interruption. Is there a dev who can explain the current logic behind the existing setting? Roverdude ? I think you wrote the original .cfg for the fuel cell, yes?

Even of it is not "multi-monitor" it would be nice to have "multi-window" whereby you can detach various info and display elements to float in separate windows that you could position on any one of your monitors. I'd buy that for a dollar!

Space exploration is also concerned with exploring undersurface seas on other planets/moons. Condemning a suggestion to include hydrodynamic parts is slightly luddite in my opinion. Its a good idea... just needs to be balanced and aligned with the concepts of space exploration rather than naval conquest.

Having just gone through a bit of exploration regarding how Fuel Cells operate in the game I have a few observations and a suggestion: Typically, in real life a Fuel Cell is a self contained device with fuel and generator in one. It consumes its internal resources and outputs electrical power and water (assuming its an oxygen and Hydrogen unit). In KSP we obviously are not dealing with H and 0 but some other magical propellent mixture - but regardless it assumes that "burning" it in the right mechanism can generate electrical output. I'm OK with that. Its a game-ified solution that works ok in my opinion. What doesn't work for me is that regardless of where you place a fuel cell, it will consume propellent mixture from the farthest reaches of your vessel - including the inner tanks of a complex landing craft. And what's worse is that there is no way to regulate it or control where the fuel cell device draws its fuel. So after exploring the "Flowmode" variable, I have discovered that a minor change in the Fuel cell part config will allow a player to either use fuel cells as the currently work AND if desired (by placing a crossfeed blocking part in the correct place) you can create an isolated fuel cell which once it consumes its allocated fuel, will not consume any fuel from the vessel (of course you can transfer fuel to get it going again). The change I have tested relates to the Flowmode setting for LF and Oxidiser resources in the Fuelcell cfg file. Specifically, Changing flowmode from "STAGE_PRIORITY_FLOW" to "STACK_PRIORITY_SEARCH" allows this type of behaviour. My suggestion to the DEVs is to make this change stock. Alternatively, if they added a tweakable setting which allowed the user to switch flowmode for a fuel cell part in game, that would be completely and totally awesome. Sure, I could be off-base here, but thanks for listening. Cheers, W. PS> yes and for the record I know USI has fuel cells - very nice. I'm talking here about a stock part which would benefit from a reasonable and very very very minor change. PPS> Thanks to you who know who you are for contributing to my exploration in another thread!

IRL RCS engines ARE used for minor course corrections. In the instance of Apollo, if a course correction was required which was less than (I think) approx 20m/s then RCS was used in favour of the Service Engine. Having RCS on any vessel is generally a good idea. Having way too much RCS propellent is usually not a good idea. New players typically carry too much propellent as insurance. I did early on. With experience, you can gradually get off the sauce and only take what you need for the mission.

Fair enough, I will check it out. However, with this small config file change (I like to think it is a correction) in the two stock fuel cell parts, I can now create an isolated fuel cell from stock tanks. It still allows them to operate normally as I think the devs intended, but they now behave properly when a docking port is present and crossfeed is disabled.

Thanks, yes I recall the RSC issue now that you mention it. I would really like a functional analogue fuel cell. I think that having created a workable standalone part config, then the best action now is to take it for a spin. I will need a new part mesh at some point, but repurposing the OscarB tank .mu is sufficient for these purposes.

EUREKA! Ok, found it. There is a value for flowmode = STACK_PRIORITY_SEARCH. This seems to restrict flow to/from a resource in the moduleresourceconverter. In the instance of my ideal fuel cell, when flowmode is set to "STACK_PRIORITY_SEARCH" for an input resource (LF and OX in this instance), then any resource connected to the fuel cell is consumed and it is NOT replenished from the vessel's resource stack that lies outside the bounds of a crossfeed disabled part. So after Frankensteining the part configs from the OscarB and small fuellcell I was able to muck around with flowmode to construct a test mule part which performs as I intend. EDIT: What actually happens is that the part will draw resources from an adjacent resource BUT a crossfeed part (Clamp jr. or decoupler) can now be placed between the fuel cell and the rest of the vessel and prevent resource flow in. You can still allow the fuel cell to pull vessel resources by enabling cross-feed on the docking port. I might be able to just hack the fullcell config and not have to make a part model. Joy. Am I correct here? Now on to learn Blender. lol.

OK, I had one last try with what SHOULD work (in my perhaps naive view), I isolated a stack of three oscars and a fuel cell from the rest of the vehicle via a Clamp jr. docking port and then turned off the cross-feed. And... Still Failure :-( Nothing I can do in the stock game allows me to isolate tanks attached to a fuel cell from the rest of the vehicle. I can't create a standalone fuel cell which is disengaged from the wider ships propellent systems. I find is beyond the realm of understanding that a crew would have to turn off ALL the propellent systems in their vessel just to properly isolate a fuel cell power generator and let it operate properly. Funny. Not a deal breaker but definitely a head scratching moment.

It's likely not a "bug" persay, but it really doesn't operate like a real fuel cell which is a unitized self contained source of electric and water. Everyone who contributed gets a big thank you and rep if I can give it. (Sorry red, my rep to you is blocked so please accept sunshine, wine, cheese and positive rays...)

Doesn't work. commented out the lines for both oxy and liquid tried with and without fuel lines - still draws resources from all tanks. Grrrr... That grr is for the module, not for your assistance ;-) Are there any other values for FlowMode? EDIT: just saw your edit. give me a bit of time. I'll test again... EDIT2: And.... no. still draws from all over. Reinstating the "Grrr" :-)

I guess I need to now conduct a test. EDIT: Test conducted, I placed a small decoupler between the three oscar tanks and the cubic strut. No effect. The fuel draw continues to pull from the farthest tanks in the fuel flow/staging sequence.

Hmmm... But since I can't shut off a tank via an action group that would mean I need to right click on EVERY tank in my vessel to set its fuel access. I don't like that option. Perhaps there is an action group mod that can handle that? need to check... - - - Updated - - - The Fuel cells clearly draw fuel from the farthest tanks in the fuel flow chain (from what I can see). It would be nice to be able to specifically designate any fuel tank as "FUEL CELL ASSIGNED" and these tanks would be the only ones that any fuel cells would draw from. Here is my current predicament... Inside the CSM service bay we have two groupings of oscar tanks each with a small fuel cell - these two units represent a couple of fuel cells. Ideally a fuel cell would ONLY draw fuel from three oscar fuel tanks aligned to it. Once the tanks are empty, the fuel cell is spent. Make sense? Would a part without crossfeed work to isolate the subassembly? or would that also prohibit electric charge pass through?

UPDATE: I think I found the answer (see Post No. 14 please) Specifically, can you restrict the tanks they draw fuel from AND still allow full recharging of all vessel electrics? Any experiences? Thoughts? Best practices? It could be completely obvious - So I might have a bit of a mental block ;-) Many thanks in advance! W.

I would try the rover with an open-up bay idea. I would also use hyperedit in a test save to prove it could work first. The real problem is when the object will load and how fast will you need to be traveling to catch it once it touches the surface. Otherwise... (actually simpler idea)... Change your terrain settings until the part loads onto the surface correctly, then run your recovery mission, and then return your settings to their previous values. This is a surface mapping problem - so its fair to use the settings to address it IMO.

Well done! Regardless of design or approach the Jool challenge it a lot go work and effort - nice! I've not attempted it myself yet, but have built a few crafts - your's are quite a build!

I think there is an opportunity to create a specific subforum for accident reviews - that could be interesting - a specialised area where we can all go for a sort of formal review of accidents. Just a crazy thought. It might never happen. My first real accident came with my initial launch and recovery of a MK1-2 pod. it was .25 and I hit the water under time acceleration. Condolences were sent to Mrs. Kerman, Mrs. Kerman and Mrs. Kerman. The ARB shrugged and then went out for a coffee.

True, but i only would like the COM fixed to the vessel, and not linked to the camera view point.

RCS placement should be aligned to the vessels centre of mass. Sadly, the COM indicator floats around when you pan your view in the VAB, so your RCS can never be placed perfectly. <----- SQUAD PLEASE FIX: COM should be static and locked to the vessel not the camera viewpoint.

Every crew that has flown to space in real life has had some form of automated flight control system on board. So... any complaints about having voluntary access to an automated flight control system in a sandbox game is without warrant.

Holy Crap! another "Mechjeb or Not" thread! already 12 pages long.... No mechjeb here -> KER only. The only reason I don't use it is that I like my screen a bit more clear. I do not hate Mechjeb, nor do I hate people who use it. If we had multi-screen support, maybe... but only maybe... If Mechjeb had a vintage DSKY option, then I might consider changing my mind. All this said, I have never downloaded or installed Mechjeb. Never used it, yet have visited and landed on all bodies. (OK, I've not launched from eve yet, but that day will come soon - and likely without mechjeb) But it would be nice to have accessible mission event programming and scripting as stock. Seriously.

KSP rides an extremely fine line between game and simulation. It's actually on the knife's edge IMHO. and wow! i am so glad. There are no other platforms out there that even attempt this. Now... IMO Removing dV does not add to the game, rather it detracts from the simulation. Squad would be well advised to more effectively align their vision regarding their melding of a proper simulation (which they are very very close) with a game "wrapper" (which they are very far way) - AND communicate it clearly to the community, the critics and the industry. Hell, even if it ultimately is implemented in 2.x who cares... as long as the vision is clear, we can support it and Squad along the way. From what I can observe, the KSP core community seems more aligned to the simulation aspect (since the game and the community has evolved from sand box) yet are supportive of having a fun and engaging game wrapper. Sadly, the wrapper is and must be everything about "Career" and the tycoon aspects of managing a space program. Squad had not placed much focus on 'fleshing the career bit out' - rather (and quite rightly) they are focused on stabilising the simulation core first of all. This is of course my own opinion - I do not force anyone to believe it.

Brotoro is a pioneer IMHO. His dedication to continuance of his original save is an inspiration - I will patiently await his reappearance and feedback on the impact of 1.0.4 on our Duna heros...

Rep to you sir. A job well done.

This. The number of players who do not want dv info is dwindling. Yes, there are a few who remain. I suggest a mod be designed for future versions of ksp whereby any dv info is wiped from vision. Let these players use that mod. I guess a simpler approach would be a small piece of black electrical tape strategically stuck to the screen. Those of us who use KER choose to remove said electrical tape. Seriously though, it seems to me that this never ending dv debate has finally arrived at its moment of lunacy.