SpacedInvader

Out of curiosity, what exactly is a degenerate triangle? As to the other issue, did you try removing the fairing and then adding it again? That seems to be where the issue crops up, as the correct curve / voxel placement is in place on the creation of the fairing, but then its removed and doesn't come back when reattaching the fairing again. On the other hand, it may already be fixed in the dev build compared to the release build, but I'm sure I was able to reproduce the issue on an install with only FAR and pFairings installed above stock... More pictures in a step-by-step format: http://imgur.com/a/svecD

So in poking around looking for a possible cause / effect of the above problem, I think I found an issue with FAR and Procedural Fairings. I had noticed that the debug voxels weren't showing up on the outer surface of my fairings when I turned them on, so, on a hunch, I exited the VAB, returned, and then turned them on, along with the cross-sectional area curve. This is what I got: Then I removed and then re-added the fairings and this is what I got: While both cases seem odd to me (shouldn't the voxels only follow the outer surface of the fairing and not completely fill its internal space), the latter is clearly wrong as it completely ignores the fairing, instead following the contours of the protected parts. The only way to revert the voxels to the former condition from the latter is to leave the VAB and return. Even this only works about 50% of the time by my estimate, as the other 50% of the time, attempting to show the voxels or the cross-sectional area curve lead to an NRE related to those activities. I have checked whether this can be replicated on a bare bones install (Stock + FAR + PF only) and it indeed can. FAR + Stock fairings are updated properly as you add or change each piece, but FAR + Procedural Fairing displays this behavior. Searching hasn't indicated that this is a known issue, but that doesn't mean I haven't just missed something along the way, but is there a way around this behavior and / or is this affecting aerodynamic characteristics at all?

That much I already figured, but I'm wanting to limit the physical size of the tank to match the contents. Some of my satellites need as little as 1kg of balance weight, yet the smallest tank I can make is 10x that capacity, so it ends up being much larger / harder to work with than it needs to be.

Hmm, I'm just now getting to a stage where I'm building big rockets again, so I guess I'll see if that has an effect on the situation, though so far it seems the answer is no and all rockets will need added drag at the bottom in the form of fins or wings. On a somewhat different note, I noticed my game getting choppy in the VAB whenever I open or close something meant to open or close in space (like a Universal Storage wedge or folding parabolic dish). Upon checking my KSP.log, I'm greeted with thousands of lines like this: Error in mesh triangle; triangle plane components are NaN or triangle is degenerate; FAR unable to use this triangle Is this an error in the part's model, or does it have to do with the way FAR handles moving parts? EDIT: After some additional poking, the errors are continuing to be thrown any time I do anything to the craft. So if its just sitting there, no new errors, then if I move the craft up or down in the VAB, thousands of new lines of errors.

I'm wanting to use PP tanks in combination with RF lead ballast as procedural balance weights, but I'm running into a problem where I can't make them small enough. I've tried reducing the minimum diameter, length, and volume through the configs, but I can never get the volume to go below 1L, which is still too big to be an effective balance weight. Is there a way to allow the volume to go below 1L?

[quote name='tetryds']@SpacedInvader: I cannot see any problems with how FAR would handle your craft and the COL is right where it should be. Before KSP 1.0 the transonic effects were not as accurate as they are now. Check the pressure distribution yourself, you will see a huge bump on that region. Just add some tailfins and you will be good to go. Real life rockets implement complex control systems and everything is precalculated. It's not because something changed that it's wrong, FAR only gets better and more accurate.[/QUOTE] I can give you that FAR is more accurate, as I would expect it to be, and if that's where the CoL is supposed to be, then I can live with that, but I've yet to fly a successful rocket in 1.0.5 where I didn't add fins which moved the CoL below the CoM. Where I keep having the disconnect is that I've never NEEDED fins in the past. Here is an example of a launch vehicle I used to launch around 15 missions last year in RSS on 0.90: [IMG]http://i.imgur.com/95B7R4N.png[/IMG] No tail fins, and only small reaction wheels on the payload that wouldn't be able to stabilize a vehicle of this size and mass, yet this rocket was always rock solid stable. I have tried to rebuild something similar, albeit smaller, on my new install and it can't get more than a couple of thousand meters into the air before it tumbles and tears itself apart.

Ok, so Stock only: [IMG]http://i.imgur.com/QvuDW1f.png[/IMG] Stock plus FAR only: [IMG]http://i.imgur.com/Xt4hDzQ.png[/IMG] Basically the same craft, with only a small variation in the fairing. I should note, however, that neither was able to hold an ascent without tumbling, but the Stock + FAR tumbled much sooner than Stock, beginning at ~65m/s compared to Stock's 150m/s or so. It seems FAR is definitely doing something strange with the CoL that is having some effect on the performance of craft, but where I'm lost is that this vehicle should fly, and in previous versions of KSP (0.90 and before), I've flown very similar rockets, not to mention the fact that most real life examples follow this profile... Thrust vectoring, while an improvement, doesn't overcome the tendency to tumble. So far, the only successful rockets I've been able to launch in 1.0.5 have had fins at the bottom...

[quote name='StoryMusgrave']Refuse Linux too eh?[/QUOTE] Yes... I've tried a dual boot with my current hardware and was never able to get Linux to happily run on my machine. I won't discount user error, but KSP is already finicky enough on its own when modded up the wazoo, so I really don't need to add an extra layer of complexity in Linux.

[quote name='Raptor831']First up, there are no pressure fed engines at the current moment. When RF added ullage and ignitions, that never got added to these configs. It's something I've been aware of, but I haven't figured out a good place to start with. It is built into RF, so I just need to add that into the configs. At this point, I'm probably going to just make all orbital engines pressure fed to start with. We can add/remove from there. I've seen those errors before. Which part are they in reference to? Usually that's the Mk1-2 Capsule and it's caused when you have TACLS, SDHI service module, RF/Stockalike installed. It's a weird order issue (in that case) that I can't ever seem to nail down. (Please never use :FINAL unless you have to...) If it's another part, then I'll need the part at least, but the full log would be useful.[/QUOTE] Hmmm... I already asked this on the RF thread, but it seems like it might apply just as much here, but how will making the engines pressure-fed affect ullage since Nathan has said that highly pressurized tanks will be subject to it? As for the errors, they don't seem to be attached to a part, but rather are thrown from the fuel-conversions.cfg during game loading. I do have all three of those mods, so maybe its the same thing you've already seen, though I'll have to do some digging to see if they are actually attached to a specific part. On a side note, I do use :FINAL for a few personal mods (mostly to remove tech restrictions from procedural parts / fairings), but I am curious about the potential negative effects of that? In going back through my KSP.log, I've been noticing hundreds, if not thousands of NREs which seem to be related to various mods, but I've never really been great at sorting out root causes for NREs... Maybe that has something to do with it?

[quote name='NathanKell']Welcome back! :) For the first few months of (my continuation of) RF's existence, I was under the misapprehension that highly pressurized ([B]highly[/B]--all tanks are pressurized, but only some are highly) tanks didn't have to worry about ullage. I was wrong. That's been correct for like a year or two now, so no, it's not very new. :] However, the myth persists... If you're not playing RO, then...yeah, you need a tech tree that works for you. If you _are_ playing RO, the only tech tree we support--the only career mode period we support--is RP-0.[/QUOTE] Thanks :) As for the pressurized tanks + pressurized engines = no ullage, I was definitely using this last year with 0.90 (I even fired up my 0.90 backup install to give it a try), though this was before the igniter functionality was wrapped into RF, so that may have been where the change was properly made? That all said, is RCS the best way to handle ullage on satellite sized craft? Also, when asked about the absence of pressure-fed engines in the config, Raptor831 mentioned in the stockalike configs thread that he was probably going to be making all of the orbital engines pressure fed soon, after which he'd add / remove from the list as needed. Once in place, how is this going to interact with RF and ullage? PS: I do want to get back to playing RSS + RO, but I just can't see it working without x64 support with all the mods I love to run, so I'll have to wait until 1.1 hits.

[quote name='Svm420']I too use SETI if that is the case with RCS consider strapping some small SRBs or just moving the RCS forward in the tech tree.. It's a single player game so that can't be cheating. Just a necessity for that level of realism. :)[/QUOTE] I might try moving some RCS blocks up in the tech tree, but SRBs probably wouldn't work for small orbit adjustments, both because such adjustments usually use less dV than the SRB contains, and because you can only use them once. I do find it a little funny that SETI placed reaction wheels before RCS blocks, but again, that's an issue with that mod rather than this one.

[quote name='Boris-Barboris']"Proper gravity turn" requires autopilot, it's not a task for human pilot. Precise and optimal thrust and pitch\yaw control is required. Least you can do is provide good control authority to counter the instability of the rocket, by using powerful gimbals (vectors), or fins. Most you can do is to learn KOS\C# and take a deep dive in control theory. If you're interested in fly-by-wire, wich will try to keep your rocket in controllability AoA region, you can find it in my signature - I implemented "Rocket mode" for my career save to solve this problem for me.[/QUOTE] In the old aero model, I used to be able to pitch 2.5-10 degrees at about 100m/s, turn off SAS, and the rocket would fly pretty close to a proper gravity turn, with only minor corrections needed, and no requirement for control fins. In the new model, the center of lift / drag / pressure sits in the nose of the rocket for some reason without the fins, so the above method always results in tumbling in one direction or the other. I do use MJ, so ascent autopilot is an option, but I have never really been happy with its implementation and have up until now gotten better results with the unguided method.

[quote name='Svm420']Can't say how it was before and I am not sure about pressure fed engines I use RFStockalike not full RO. Nathan has been trying to squash that myth for a while though pressurized tank should never had any effect on ullage. He could explain it, but that is the truth.[/QUOTE] It may be the truth, but it certainly presents a problem with my current mod setup as I'm using the SETI balance mod and RCS thrusters aren't included in the tech tree until quite some time down the line, though that isn't an issue with RF, but rather SETI. That said, I just want to be sure I'm not experiencing a bug rather than a feature. I also use RFstockalike, and even with that config set, there were pressure-fed engines in the past as I described. If you are correct, and I don't have any reason not to believe you, then the old way must have been deemed unrealistic and removed, which makes me a little sad as it was always nice to have at least a few "easy-mode" engines to allow for smoother orbital operations. PS: On a side note, and purely out of curiosity, what do you have against CKAN?

[quote name='Olympic1']1.1 will be in 2016 according to the devnotes[/QUOTE] I understand that, but I just can't see myself being able to run RSS with the high-res textures I want, plus all of the parts and visual mods I like without 64-bit support. And no, I won't do the hack as I've tried it 2-3 times in the past with 0 success and huge instabilities. [quote name='ZaPPPa']Use the Custom Barn Kit mod for that.[/QUOTE] Thanks.

[quote name='Svm420']Pressurized tank have no effects on ullage you still need rcs or solid motors to promote propellant stability. :)[/QUOTE] This appears to be new then... in the past a pressurized tank (service module) + a pressure-fed engine (orbital maneuvering engine) = no ullage simulation. As far as I can tell, there is no longer a distinction between pressure-fed and non pressure-fed engines in the configs, unless I'm missing something?

When 1.1 hits, I'm probably going to be give RO a try again, but I'm wondering if a way has been found yet to increase the pad / VAB limits to allow for the much larger / heavier rockets in career mode?

I'm experiencing an issue with pressurized tanks not always behaving as if they are pressurized. As a rule, I always use the service module tank type for my final stage tank so that I don't have to mess around with ullage when I'm trying to perfect an orbit, but I've noticed with the most recent version (both of KSP and RF since I haven't played since 0.90) that the service module tank type will often allow fuel to go into the "very unstable" condition, even though it is listed as being pressurized. This seems to happen most often after the craft has been coasting for a time and can usually be corrected by imparting some centrifugal force onto the tank, but unless something has changed that I missed, if the tank is pressurized, there should be no ullage simulation at all, right?

I've noticed since my most recent return that hypergolic fuel / engine configurations now have limited ignitions whereas in the past this wasn't the case. I've read a few pages back on the RF thread that Nathan mentioned on the same line that a: "Even hypergolic engines don't have inifinite relights", followed by b: "even hypergolic pressure-fed engines (which usually have effectively infinite relights) are still subject to ullage concerns". With those statements in mind, I'm left wondering whether I'm supposed to have infinite relights on hypergolic engines like the old days. In addition to this, I've noticed that there don't seem to be any more pressure fed engines like there used to be, forcing ullage simulation onto all engines even when using a pressurized tank mode like a service module. I'm wondering if this option even exists anymore as I'm not even seeing a reference to it in the configs. I'm really hoping both of these still exist in some form as having at least a few pressure-fed hypergolic engines with infinite relights made tasks like perfecting geosynchronus orbits or landing from orbit much less of a headache... Finally, on load I'm getting three MM errors with the stockalike config from the fuel-conversions.cfg: [LOG 12:02:20.167] [ModuleManager] Error - Cannot parse variable search when editing key volume = #$/RESOURCE[MonoPropellant]/maxAmount$ [LOG 12:02:20.168] [ModuleManager] Error - Cannot parse variable search when inserting new key maxAmount = #$/RESOURCE[ElectricCharge]/maxAmount$ [LOG 12:02:20.168] [ModuleManager] Error - Cannot parse variable search when inserting new key maxAmount = #$/RESOURCE[MonoPropellant]/maxAmount$ I've looked into that config, but my modding skills are pretty rusty and I'm not understanding where things are going wrong.

[quote name='tetryds']False, it is not bugged, it's just not enough data to build airplanes properly.[/QUOTE] So, this apparently brings me back to my original question...

[quote name='cantab']Don't trust the CoL ball, it's bugged in FAR. Check the static stability chart instead.[/QUOTE] An interesting thought... what would I be looking for there?

[quote name='Crzyrndm']Heavier payloads (CoM forward), increasing the size of the base relative to the front end (cone shape), and thrust vectoring. Fairings might (if well shaped and blending into the remainder of the rocket) be good for drag, but they do tend to interfere with that second concept (either by being the fattest/draggiest part of the rocket, or by being so long that the shape of the rocket doesn't matter)[/QUOTE] I wish it were that simple... I've tried expanding the body of the rocket out to 5m with the payload staying at ~1.5m and the CoL didn't budge at all. As for the payload, I can only make it so heavy before I'm just adding parts for the sake of adding parts. Also, the CoL is firmly planted on the center of the payload fairing currently unless I add fins on the bottom of the rocket, so I don't think it even possible to shift the mass balance far enough forward to compensate without completely removing the drive section of the rocket.

Could someone please advise me on how to build smooth-sided (i.e. no fins near the bottom for drag / control) rockets where the center of lift is below the center of mass. I'm guessing this is a result of the new aero system, but since installing 1.0.5 + FAR, I've not been able to build a smooth-sided rocket that has been able to fly a proper gravity turn, instead, they always begin to tumble at some point. I've identified this as resulting from a center of lift / drag which is placed near the top of the rocket where the payload and fairings are, while the center of mass is far below with the fuel and engines. So far, I've been able to counteract this tendency easily by adding control fins near the bottom of the craft, shifting the center of lift / drag down below the center of mass, but at some point I would like to move on to launching without fins. The problem is, however, that absolutely nothing that I've tried up until now moves the center of lift down from the top of the rocket except adding fins down below. Is there anything I can do to fix this issue? Thanks PS: I guess I should mention that I'm using procedural fairings rather than the stock fairings and the diameter of the fairing is only slightly larger than the diameter of the rest of the rocket.

So this is just an idea at this stage, but I'm thinking about trying to make a mod which would replace science farming entirely with contract driven science. The basic premise would be set all experiment rewards to zero and then instead have the science rewards come from contracts which would be generated based on current tech level and mods installed. My reasoning is that the current science farming system really hurts game immersion (at least for me) as there is no real direction beyond "go places and get science points" and comes with several significant drawbacks. First, its repetitive, basically consisting of stuffing as many different experiments onto a craft as possible, sending it to a new location, and then rinsing and repeating until the tech tree is complete. In addition to this, the system gives you no reason to return to any location (planet / biome) unless you get a new experiment somewhere down the line, and even then its often not worth the effort to send a craft there for just a single experiment when there are so many other locations where you could run all of the experiments. Finally, it has made rovers little more than toys thanks to the fact that, unless you land right on the edge of two biomes, rovers simply can't cover enough terrain to justify their use to get more science points. The contracts I'm thinking of would fix all of these issues, first by putting a story behind each mission / experiment, then by creating / enforcing variety in mission implementation. Individual contracts would require specific experiments to be run under specific conditions such as location, orbit altitude, or even day/night (if this is even possible), and could even include time displacement, so that the same experiment would need to be revisited after a month or a year. Rovers could be made useful again by creating missions with multiple target locations close enough together to justify a rover over a rocket hopper, though I might even go so far as to include a wheels but no rockets requirement. I would also want to try creating contracts based on the completion of another contract, which could present the situation where a new mission would need to be sent back to the same location to gather additional data through a different experiment. Anyway, this brings me to this post and why I'm writing it... Obviously, I wouldn't want to attempt something like this if it already exists, so I'm curious if something like this does already exist. If not, I am in need of technical and creative guidance, as I've never attempted to write a contract for KSP before, let alone one which allows for technology, location, and situation variables. Is there a guide somewhere that addresses any / all of these things? Finally, I'm curious if this is even worth trying as I really wouldn't want to have to write a hundred individual contracts to accomplish the goals because there wasn't a way to automatically generate them. Plus, it would be nice if someone else was interested enough to use it when its finished...

Looking forward to seeing this working again... I've never been great at targeted atmospheric entries and in the past, this always went a long way to making up for my deficiencies.

Searching didn't bring up any reference to this, so I guess I might be the first one to notice it... Anyway, for some reason, the texture config for this mod completely wipes out the stock textures for the Procedural Parts mod. At first, I though it was because the config for this mod points toward a folder which no longer contains the texture files, but even after changing the config to point toward the new location, the textures are still missing in game. Aside from incorrect file locations, what else might be causing this interference? For the time being, I've disabled the SETI texture config, but it would be nice to get those custom textures back. Thanks