Patrick Kerbivan

Aw shucks... Please, save the complements for when (if) I ever get this working. I'm still in the very early stages and am quickly comprehending how much I'm going to have to teach myself to make this happen. Of course! I'm still pinning down the exact mechanics and and making sure I can do what I want to without breaking other stuff, but supporting mod-added experiments is a big priority. If it can work out the way I'm hoping then mod authors should be able to just include a little tag in their experiment definitions to dictate how the points get split between the disciplines. The breakdown to disciplines is still up in the air, and will be an easy thing to tweak once the mechanics are operational. I was leaning towards a biology/medical discipline, but it seems to be the least relevant to the majority of techs. Even for players with life support in the mix that's still a rather small fraction of all the tech to be unlocked.

After putting some more thought into it I realized that some of the science stuff could be worked around by not directly interfering with the generic science collection. The plan is to keep the same science values with all experiments, just split those points among the categories (in different proportions depending on the experiment), so the stock science points would be equal to the sum of all the new categories and could still be consumed when a tech node is unlocked. If I just monitor for the transmission/recovery of experiments (maybe just by tracking changes to the science archives?) then I can trigger the addition of the points to the category totals. I'm betting if I look at Kerbal Construction Time's delayed research feature I can figure out how to control research node unlocking to also require the designated amounts of subcategory points. Since mobile lab research doesn't return its science as a result of a particular experiment (does it?) that would be a trickier one to deal with. An easy solution would be regularly comparing the stock science totals to the category totals, then adding equally to all category totals until their sum matches stock points again. If I could capture and maintain a list of experiments that are added to labs as data I could at least create some sort of weighted distribution ratio to be used in those checks. The part I have the least idea how to approach is presenting the relevant information in a useful way. For experiments maybe I could use something like Module Manager to automatically add "Experiment yields X% Chemistry, Y% Physics." to the results description? Indicating the category point requirements on the research screen is even trickier, though I could perhaps use the same approach to insert the requirements in the node description. In my imagination there would be little icons for the categories that show up where the stock science requirement appears now, but I'm betting that would involve hacking that whole interface, as suggested. - - - Updated - - - That certainly sounds like what I'm looking for when it comes to capturing returned results... And that definitely looks like another solution. Thank you!

Sarbian... Sarbian... Sarbian! ...nope, nothing. Seriously though, I don't feel entitled to directly pester one of the masters when I'm just a fledgling who's probably aiming way too high. The reddit crowd liked my idea, but I've gotten zero feedback from the post I made about it here, so I'm not as optimistic that it's worth the effort anyway. Nevertheless, I'll keep poking at things on my own and see where I get.

I've set my sights on what I suspect is a rather ambitious project, and I'm hoping someone can point me in the right direction to get started. I've got some hobbyist-level coding experience and in the past I've created a few new parts for KSP, but I've never been this deep "under the hood" before. The core function of the mod is to split the generic Science resource into 4 new categories. Experiment results will be converted into varying amounts of points in these sub categories (which categories get the points depends on the experiment), then different combinations of these points will be required to unlock different tech nodes. A more thorough explanation of the idea has been posted here, though some of the fancier features will of course wait until I get the basic framework handled. Breaking it down, I'd appreciate any suggestions or links to code examples from other mods that would be relevant to the following tasks: Add new persistent career-wide resource types like funds, reputation, and science. Intervene in the process of experiment results being recovered/transmitted and converted into the science resource so that the points can be distributed to the new kinds of science points; this would need to be sensitive to the type of results so the distribution of the points can be modified based on the source. Modify the cost of unlocking research nodes to require the new kinds of science points. Thanks in advance!

I posted this on the KSP subreddit last night and got some positive feedback, so I thought I'd bring it over here for a little more persistence. With all the mods available to increase the depth and realism of KSP, I feel like the system of unlocking tech with general-purpose science points has some potential for improvement as well. What if science points were broken down into categories for different types of knowledge such as physics, chemistry, materials and engineering, and planetary science? Different experiments would yield points for the relevant disciplines: Mystery goo could yield chemistry points. EVAs and surface samples could yield planetary science points. GRAVMAX would yield physics points. And so on. Nodes on the tech tree would then require relevant combinations of points to unlock: Rocketry would mostly need materials and engineering. Ion engines would need more physics with a splash of chemistry. New experiments, scanners, etc. would require planetary science and a bit of whatever type the experiments themselves yield. And so on. To retain a degree of flexibility in this the scientists could have added field specializations so that when they remove results from an experiment the proportions of the points are skewed a little more towards their field. Don't have any more chemistry experiments available yet, but you need more chemistry points to unlock a new one? Send a chemist to run a planetary science experiment and get a chunk of the points back in chemistry instead. Possible additions to this could be: Scientist levels increase the amount the results' points favor their discipline. Specialization could either be a random predetermined attribute, or every level a scientist gains could grant a point that the player can then assign to a discipline. A level 4 multidisciplinary scientist would be able to get points for all 4 fields from an experiment that otherwise only covers one or two fields. Rather than having a materials and engineering specialist, engineer kerbals could function as specialists for that field. Mobile labs would have their science output type influenced by the specialization of the crew on board. Contracts could also be modified to respect this system as well: Part tests would distribute their science yield according to the unlock costs of the tested part's tech node. New satellites would yield planetary science, and if a particular instrument is required on the satellite then also some from the discipline that instrument's experiment yields. New stations would yield materials and engineering with a dash of planetary science. To further adjust the balance of science points there could also be new strategies similar to the financial bailout, allowing an instant exchange of science from one field for a less amount from another. There could be a monetary cost as well, with a higher commitment costing more funds but increasing the amount of science you get back in the other field. Ideally this wouldn't really be necessary if I get the experiments' outputs and tech node costs balanced properly. Speaking of balance, my intention would be to balance the disciplines' points around the stock tree, but as a heavy user of mods myself I would have every intention of enabling support for the Community Tech Tree and any other popular tech tree mods that come along. My plan is not to mess with the overall number of points produced and required, just to divide them between disciplines, so an experiment that yields 30 science in stock might yield 18 planetary science, 6 chemistry science, 3 M&E science, and 3 physics science. This is all just an idea at this point of course, and all the fields and part/experiment associations are just examples. I'm sure this would be a pretty massive undertaking to implement, but if enough other people find this idea as exciting as I do then I'd definitely be up for taking a crack at this and/or recruiting as necessary to make it happen!

I'm on the latest version of FS (that I can find - 7.1.3 hopefully).

I was just playing around in sandbox making a small quadrotor with the smallest model of ducted fan and tried out the hover mode with unfortunate consequences. The craft was basically just a probe core, a battery, a bunch of heavy RNGs from Near Future Electrical, and the fans. I don't know what was happening "behind the scenes" but as soon as I hit the action group to turn on hover mode all four fans shot up in temperature and exploded in under a second. Without using hover mode the same craft can fly at max throttle for several minutes before anything overheats to the point of exploding, and it's the probe core that two of the fans are attached to in that case.

I can confirm that KSP doesn't use SLI; when I look at my video cards' load monitor while running KSP there's only load on one card. This is while using the optimized profile for KSP as applied by the NVIDIA GeForce Experience application. Someone with a bit more advanced knowledge might know of some trick for forcing SLI, but I agree with KrazyKrl that KSP's performance is generally going to be limited by your CPU performance rather than your video card.

I'm familiar with the EM drive and for real-world spaceflight it's a very exciting possibility, but I don't think it would play well in KSP because of the burn lengths that would be involved. Every discussion I've read about applications of the EM drive are talking about how its potential comes from the ability to run it constantly through a mission, propelling towards the destination for the first half then slowing down again for the second. With the mechanics of KSP as they are you'd have to run all your missions in real-time...

I made another thread for this already, but I'd like to toss one in for the career category: Add planetary exploration (orbit, science from orbit, reach surface, science from surface) to the automatic contracts we now have for milestones like speed, altitude, and distance. The current system of those exploration contracts never appearing if you've already reached the destination feels like it penalizes players for being efficient enough to get there earlier than expected; I took a contract for a Mun flyby that appeared before the full exploration contract did, and when I managed to turn that flyby into a landing I deprived myself of the usual exploration contract rewards that really jump-start a budding space program.

I'm not absolutely certain, but I had discarded a few contracts when the flyby contract appeared without the explore, and if memory serves the explore contracts would usually show up right away if they were available at all. I don't know what all the tweaks made to contracts in 1.0 are, but it seems like the exploration contract just wasn't available yet. Perhaps the flyby is now a sort of prerequisite, but if that's the case it seems like it's punishing the efficient to not allow you to take them both on in one flight.

I just started up a new career game on 1.0 this afternoon and accepted a contract for a Mun flyby. I overengineered a bit and wound up having enough fuel to not only fly by but also orbit and land, forgetting that in doing so I cheat myself out of the rewards for the standard exploration contract (orbit, science from orbit, land, science from surface). In .90 those exploration contracts for the Mun and Minmus were the low-hanging fruit that really got my space program off the ground, especially when I was playing on higher difficulties. Now that we have the precedent of those automatic rewards for more generic accomplishments, could we get the planetary exploration milestones included?

If all you're using is TAC Life Support (the other zip files in the dropbox are for other TAC mods) then you just need to extract the contents of the TacLifeSupport_0.10.1.1320.zip file and copy the contained GameData folder into your Kerbal Space Program directory, allowing it to overwrite any existing files.

With some minor alterations to scale and another pair of winglets it actually works quite well.

Ah, drat. Thanks though! Is there any sort of simplified summary kicking around that gives an overview of how FAR does what it does? I always had this grand vision of the overall craft model being tossed into a sort of virtual wind tunnel behind the scenes to determine its performance, but if one part doesn't block another's airflow then I'm assuming it's more like it's calculating the aerodynamic properties of each individual part then applying that force at the part's location?

I have a question about how FAR models aerodynamics - and specifically the potential for damage due to aerodynamic stress - that may or may not have been answered before. I did search the thread but didn't have much luck... So, I know that fairings and cargo bays will provide the "shielded" value to parts contained within, which I'm assuming zeroes out any aerodynamic forces applied to or created by those parts. I'm wondering if FAR's aerodynamic modelling actually goes far enough to essentially be able to fake shielding with an adequately protective structure. As an example, suppose that I have a delicate rover that cannot withstand the aerodynamic forces of reentry without being torn apart; if I build a shell of structural panels around the rover and reinforce the heck out of it will that shell actually deflect the oncoming atmosphere and reduce aerodynamic stress on the rover?

The new release seems to be working for me so far. No crash on entering the VAB at least. It seems to be doing bad things to icons and such being added by mods though. I may have noticed this once or twice before with previous releases, but definitely not to this extent: Edit: Found even more cases of this badness, including distortion of stock assets such as the icons for the different strategies in the new admin building.

Confirmed! Thank you!

Steam verifies build 403481 but main menu still reports 0.24.2.559. Even cleaned everything out and did a fresh install. Edit: Waiting patiently per instruction!

Just throwing in another confirmation of trouble. Steam says I'm on the new build number, but it's still 24.2.

That's why I was talking about just dealing in velocities relative to local targets like other craft, stations, and asteroids. Trying to use something like this to change your velocity relative to a large orbital body like Kerbin would indeed be a bit nuts. This is a "for fun" idea, intended for the players who might like to treat KSP more like a sci-fi building set than a realistic spaceflight simulator (and who are likely already using some of those tremendously overpowered mechanics you mentioned as introduced by other sci-fi themed mods).

While there are plenty of mods that add various science-fiction-styled parts, I haven't seen anything to enable maneuvering in space as it is often depicted in science fiction. In most popular sci-fi settings when a ship thrusts in a certain direction it's as if its previous inertia is negated or redirected, allowing the ship to gracefully weave between objects by simply maintaining a heading towards the point in space it wishes to pass through. As we all know from experience it works nothing like this in reality (or KSP, at least). The best way to illustrate it I could come up with was this lovely little mspaint number here: What I'd like to see is a mod that enables sci-fi style spaceflight to go along with the various sci-fi style parts that have been added by numerous mods. One of the main concepts I think would be necessary for this to not be completely absurd would be specifically managing a relative vector; putting it in KSP terms, this would keep your velocity relative to a target aligned with your current heading. The more realistic option I can think of would be to just have a toggled flight control plugin that automatically uses RCS thrust to correct your relative velocity while maintaining your heading. This correction would almost certainly not be instantaneous, but could allow for some fun "drifting" maneuvers. It would probably be impractical for larger vessels unless you coated the body of the craft in vernor engines. The more sci-fi option, which could potentially be made to work for a vessel of any size, would be an actual "inertial redirection module" of some sort. I would imagine this to be something that consumes large amounts of electricity, with consumption scaled to vessel mass or applied force if possible, to automatically and near-instantaneously apply the necessary thrust to redirect your current relative velocity into line with your heading. In both cases it would probably need some protection mechanism that only enables use of the system when dealing with another craft, asteroid, or similar object. Trying to change your velocity relative to a planet would probably be futile with the RCS option, and should likely tear apart your ship with the sci-fi option. I suppose an absolute behemoth of a spacecraft (I'm looking at you, B9 builders) would potentially turn so slowly that the forces entailed in keeping its orbital inertia in line with its heading wouldn't necessarily snap it in half though. Anyway, a last bonus feature would be something like "space brakes", which would just be an option built into the system to automatically apply thrust as necessary to slow or even stop your craft (again, relative to a designated target) when the throttle is set to zero. Thoughts?

I ran into an issue that isn't really RemoteTech's fault, but I thought of something that would potentially help and was wondering if there's an easy way to accomplish it... (tl;dr at bottom) After starting a new game last week with RemoteTech added to my usual slew of mods I got to the point of having a rather large number of relays for the various planets I was visiting, plus some interplanetary relays. I had perfectly uninterrupted coverage set up for Kerbin, Duna, and Eve, as well as all their respective moons, which left me with 22 satellites scattered around the system, plus a handful of ships and probes floating around bouncing signals somewhat incidentally. This started to have a noticeable impact on the game's performance (whenever I went into the map I got the yellow "slowing down time" clock in the corner), and it's finally reached the point where upon visiting the tracking station the game just freezes. I'm not sure if the issue was simply the number of ships, or the large number of hops some connections required, but editing my save file to chop a few unnecessary ships out did get me playing again. I'm hesitant to launch any new ships or set up relays at any new planets for fear of breaking things though... So, I was thinking, I really like the game mechanics RemoteTech adds, but I was wondering if there's something in the settings that could be tweaked or added to allow communications to ignore planetary interference (no line-of-sight checks). I know this would abandon a fair bit of realism, kinda making it a "RemoteTech Lite", but being able to get away with one relay per planet sounds like a nice intermediate step and would allow me to drastically downsize my fleet of satellites... tl;dr: Can RemoteTech be tweaked to ignore line of sight checking for connections?

I've searched through this thread and picked up bits and pieces on the compatibility issues with TweakScale, but I'm hoping someone else can confirm or deny the following conclusions: -TweakScale's presence in your install won't alone cause any issues with B9. (My experience so far.) -TweakScale works as expected on a vessel that doesn't use any B9 parts. (Also my experience so far.) -Problems ranging from cosmetic to game-crashing occur when the scale is modified on B9 parts. (Haven't tried myself yet.) -Modifying the scale of non-B9 parts on a vessel with B9 parts should be okay as long as those parts don't have any direct interaction with B9 parts. (Also haven't tried myself yet.)

Would there be any chance of a future release including some sort of check that forces completion of a science parameter that can no longer be completed due to zero remaining science? I picked up a survey contract that wanted three different experiments transmitted/recovered, but I already had collected 100% of the science for one of those experiments (low mun orbit temperature, if it matters). I'm guessing that what happened was the contract was generated and available before I completed the mission that collected the science, then after completing that mission I accepted the contract with the now-outdated parameter. When I collected the report again (despite its zero science value) upon recovering the vessel I was presented with the same message you see when you've transmitted as much data as possible and need to return the experiment to KSC.