aquilux

Another way is to have the engine also consume the resource you want it to spit out. But instead of drawing a positive number of resource, use a negative value. When the program subtracts the value from the tank, it'll be subtracting a negative, and will effectively add that resource in according to fuel flow rules.

Actually, considering that KSP itself has RAM leaks, listing how much RAM something -SHOULD- use will become inaccurate immediately after loading. I think it's perfectly reasonable to have a small display somewhere that indicates in Mb, to a few decimals, how much ram KSP currently has allotted to itself so that users, even with otherwise stock games, can see when their game is consuming too much memory and is about to crash.

Ah, I was looking for that and didn't see it for some reason. Thank you for the help. - - - Updated - - - Hmmm. So the idea has floated around before. Is anyone interested in making a new version? I doubt those will work today.

Is there no interest in developing a mod such as is outlined here?

I'd like to request a mod that adds the functionality of adjusting landing legs after landing to deal with slopes either by new gear that fill all the current niches or (optimally) by appending the ability into any existing gear using it's own retract/extend animation. Idealy, this would work off of pitch/yaw inputs after the craft has "landed" instead of context menu slider per leg, though that would be acceptable; toggling via context and action group would be greatly appreciated. This would allow one to land on a significantly sloped surface and correct one's pitch to point as is deemed appropriate. The intent is to assist a situation such as this: - - - Updated - - - Oops. Mods, could you... I accidently the title. It should have been "[REQUEST] Adjustable landing legs for landing on slopes." Could someone assist somehow?

While this mod demonstrates resource consumption, this is not what I am proposing for the on-rails behavior. I do not propose that some aspect of the craft's off rails physics be stored, only that it's final effects are emulated in a simple and reliable manner. And while the timewarp rotation fix looks rather promising in it's scope, it does not appear to have any effect on the craft's orbit, nor does it appear to cover any other points in my request other than the limited resource consumption.

Kind of but not really. It'd probably have to work in the same way hyper edit works, but I don't want it to be any more accurate than the game's on-rails calculations are, those are good enough. The issue is the floating point errors when physics is applied makes it impossible to get a perfect orbit, but I don't even want to get rid of that. My ultimate goal is to keep my satellite constellation from drifting out of position while: Not using something cheaty like hyper edit. Limiting it's performance to that of the user's ability. Not making it an unlimited, global solution. As I described in my first post, this would be accomplished by: Requiring the player to achieve the desired orbit within a maximum error range. Causing it's duration of effect to be dependent on the player's ability for accuracy. Limiting it's effect to craft that have achieved an assigned target orbit. In addition to these goals a few more I include for realism and usability, these are: Effect duration dependent on available ∆V resources (LFO, RCS, Xenon, ect...) and these resources are depleted over time. Accuracy additionally dependent on force magnitude (the smaller the thrust to weight, the more accurately you can burn) and can have an effect on how much the satellite needs to correct itself, accelerating it's resource consumption. When a satellite runs out of it's resources it can no longer maintain its orbit as it has and begins to drift (accomplished by applying a small bump to it's orbit that is proportionate to how much it was needing to correct itself), requiring a resupply if you don't want it becoming trash. Ignore systems & resources that have been deactivated/locked for the purpose of keeping a reserve for final disposal and diminishing it's TWR to make it's motions more accurate.

Is there any possibility for compatibility with Deadly Reentry for the heat shield, and Ferram Aerospace Research with the cowling on top to shield the docking port?

There was at one point a fuel balancer mod but I think it's dead now unfortunately. I also would like a mod to manage my center of mass, though maybe if the coder is ambitious they could make an interface similar to that of the on screen mouse control to let us move our CoM live in flight and maybe even set new presets live.

Is there anyone willing to assist with this concept?

Exactly, I wanted a solution that required me to have the requisite skill to put the satellite in the orbit I want as accurately as I want it to be without it being unrealistically perfect and lasting indefinitely, while also being able to handle the satellite being off rails and having it be nudged around by miniscule physics forces, without me having to save-quit-edit save-reboot every time.

The primary point of this mod is solving a problem most people don't notice unless they're playing with remote tech. That is that you can never get exactly perfect, and because of that you will never be able to keep a constellation of satellites in their proper position without frequent and tedious orbital corrections. What I propose as the core functionality in this mod is to automate the repetitive task of performing orbital corrections and simulate the average effects of those course corrections (never quite perfect, consumes ∆V over time, keeps proper position) and have the cost of those effects be based off of a few realistic conditions (lower t/w is more precise, the more accurate you try to be the more often you're burning, the further off you get the more it costs to fix, orbits too close to the planet are harder to maintain).

I'd like to request a mod that automates the process of maintaining a specific orbit while consuming a small amount of ∆V over time, requiring eventual refuel or replacement of the craft. It would take user inputs for the target period, apoapsis, and periapsis (pick two of the three), as well as desired accuracy. It would require the user to achieve the desired orbit within a certain margin on their own (Maybe it could generate a phantom target to facilitate setup). User could knock craft's orbit out of target range, requiring reacquisition before stationkeeping becomes active again. In turn: It would consume ∆V over time based on accuracy setting & orbit (too high or low accuracy would consume more ∆V, as well as being too close to atmo or dipping into it) It would monitor the craft's orbit whenever unloaded. It would vary the orbit within the accuracy range set over time, with the net effect of keeping it within the target orbit. This mod would be most useful when used with remote tech considering proper satellite constellations require active maintenance. And while people could keep switching through dozens of satellites to correct their position and period instead of time warping to their probe's arrival, I feel as though many find this overly tedious.

Yeah. Be patient.

Well herp a derp, can't believe I missed that. Truthfully though, all mods should be available through CKAN packages.

I request CKAN integration. It should make everything easier for everyone. http://forum.kerbalspaceprogram.com/threads/97434-The-Comprehensive-Kerbal-Archive-Network-Call-for-mod-participation

You mean like the soyuz clamps and umbilicals? (Launch at 1:18) I too would like this.

It looks like it's not going to be touched by anyone (last update was.23, licence is prohibitive). Fortunately, there appears to be an alternative. Check out the ATC mod, considering it was specifically designed to be a replacement for TreeLoader it might be a good fit.

I think that this mod is amazing, but inherently flawed in it's execution. It merely copies heading and acceleration, relying on RS to cancel out drift. Instead, each ship should be flying itself to maintain a fixed point relative to the leader, letting it steer and throttle to maintain that position and correct for the minute errors that become a big deal in a short time when flying so closely. This would negate the need for RCS, and would eliminate drift in atmospheric flight.

For some reason I never saw this reply, so here is my belated response. First, I only get crashes as I approach the ram limit with installed mods. Second, with on the fly loading it'd be near impossible to cram so many different parts in one 50k sphere that you'd get more than the stock ram usage even with 10gb of mods installed, that'd keep ram usage down so much that memory leaks and bits of code wouldn't even get you close to the ram limit. And the point of the graceful handling only being graceful compared to a crash statement is nothing short of being dismissive considering that's exactly what it's being compared to in the first place, there would be no need in most situations to post a high GB warning in startup because part loading would not occur until the parts are in a position of probable use. With the system I outlined earlier, it'd be rare to reach a point where you use as much ram as the stock game uses today. - - - Updated - - - Yeah I watched the video, excuse my language but it's a bul**** cop-out. A modded part can easily be made indistinguishable from a stock part in KSP, and I've already suggested how to handle part loading in a way that'd cause no hangups in an earlier post. It's another case of a major improvement being dismissed because apparently we have no idea what we're doing and everything we say is wrong. I hope to see someone decompile the game so that they can implement this system just to prove squad wrong like what happened with multiplayer.

The reason that this keeps popping up is that every time it does it gets dismissed with nothing but excuses. Before you say it, I'm aware of any response older than 3 months. They're excuses and dismissals with no level of thought behind them, and nowhere close to an actual thoughtful answer. It shall keep being brought up untill there is an actual thoughtful answer that doesn't amount to "I don't want to think about it." As we've seen with the multiplayer mod some larger ideas get completely dismissed until someone goes and proves squad wrong by actually doing it, but as I understand it the modifications required to fix this problem are actually illegal according to squad's terms.

So, a bit confusing. I change "RangeModelType" to "Root", and "MultipleAntennaMultiplier" to "0.25" and I'll get the behavior I spoke of? Also, will "MultipleAntennaMultiplier" boost range on craft with more than one antenna of the same type?

I have not seen this behavior yet. Does having a directional antenna on one side of the link boost the range beyond that of the omnidirectional antenna involved? If not then what I talked about is still not implemented. Having a directional antenna on one side of the link should increase the overall range because the directional antenna is capable of beaming the signal in a cone instead of letting it spread out, and in the same way it concentrates a signal originating inside that cone that would not be detectible by an omnidirectional antenna.

So here's a question, why is it that directional antennas are incapable of linking with omnidirectional antennas? I don't by any means expect to see anywhere near the same range with a directed/omni link as I would see with a directed/directed link, but you only have to search out ways of extending a WiFi network to see that there is an operational regime that is completely glossed over in this mod. (I'm not even talking about the DIY articles, there are plenty of commercially available directional WiFi antennas available on the market) I'm not sure about the actual math, but I imagine half the range of each, added together, might be a good rule of thumb for the current antennas in a directed/omni link. I also wonder if it'd be possible to see some more intermediate directional antenna types with much wider transmission cones such as helical antennas, Yagi-Uda antennas, Log-Periodic dipole array antennas, and Corner Reflectors before parabolic dishes. I was particularly inspired by this page while researching DIY directional WiFi antennas, and think it would add an enjoyable level of variety if some more antenna types were added and the prohibition of directed/omni links removed.

But how is that situation worse than it already is? At the moment we have to contend with random crashes and hangups already. If I knew I was approaching something large that had the possibility of crashing my game, it would be less disruptive when it crashed rather than how it is now where the game may crash randomly even when just switching from my ship to map view, or from VAB to the main complex, or from the main complex to the tracking station, or just randomly for no apparent reason. I'm never prepared for that possibility, there's no warning, and I'm derailed when it happens. Not to mention it could happen just before a save wiping out everything since my last one. Or heaven forbid, during a save, completely wiping out my save file. Yes I keep backups. Should I have to? No. At least in the scenario above the game would be allowed to gracefully handle the failure without crashing in a predictable scenario, while also giving me a warning that it's happened/about to happen, instead of hanging or dumping me to desktop at random times and requiring me to reload the whole game.