Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by funk

  1. Hey guys, can anyone explain to me what's the new behaviour of the intakes? Is the old build rule still valid? I've recognized some weird behaviour, it seems like the attaching rule has changed vice versa - engine-intake engine-intake? It's nothing about future or past, it's just about aerodynamics. At supersonic and hypersonic speeds you want extremly sharp wings, even negative sharped wings are imaginable, or just a lifting body with some control. But planes in such a shape are hardly maneuverable at subsonic speeds. IR they try to combine the different approaches, which leads mostly to multiple delta wings or in some cases to jackknife wings. If you try to design the same way, it should be possible to get some stable delta wing shaped planes. I've build dozens in 0.90 with FAR. In the following thread I'd already explained something about them: http://forum.kerbalspaceprogram.com/threads/115600-RO-and-spaceplanes?p=1840878#post1840878 The only thing I'm guessing is, if nuFAR, with its voxel approach, recognizes the shape of e.g. the leading edge? This could be an opener to many more designs...
  2. FUNKYndustries presents "van Beethoven" LKO crew and satellite carrier: Stock parts only except Bahamuts Adj. Landinggears and some cameras for RPM.
  3. Yep Cryoengine uses Interstellar fuelswitch, I changed the cfg to not proceed when MFT is installed, so the cfg of a standard tank looks like this after all patches: { name = fuelTank module = Part author = NovaSilisko mesh = model.mu scale = 0.1 node_stack_top = 0.0, 7.72552, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -7.3, 0.0, 0.0, -1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 TechRequired = advRocketry entryCost = 1600 cost = 500 category = FuelTank subcategory = 0 title = FL-T400 Fuel Tank manufacturer = Jebediah Kerman's Junkyard and Spacecraft Parts Co description = The FL series was received as a substantial upgrade over previous fuel containers used in the Space Program, generally due to its ability to keep the fuel unexploded more often than not. Fuel tanks are useless if there isn't a Liquid Engine attached under it. They can also be stacked with other fuel tanks to increase the amount of fuel for the engine below. attachRules = 1,1,1,1,0 mass = 0.25 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 50 breakingTorque = 50 maxTemp = 2000 bulkheadProfiles = size1, srf RESOURCE { name = LiquidFuel amount = 180 maxAmount = 180 } RESOURCE { name = Oxidizer amount = 220 maxAmount = 220 } MODULE { name = GPOSpeedPump } MODULE { name = ModuleFuelTanks volume = 400 type = Default typeAvailable = Default typeAvailable = Cryogenic } MODULE { name = TweakScale type = stack defaultScale = 1.25 } MODULE { name = ModuleTweakableFuelPump ResourceNames = LiquidFuel, Oxidizer } } PART Edit: It seems that MFT don't change the maxValue of a specific tank/resource, if it's already defined. I haven't looked at your code, perhaps there's an update necessary when switching tank_types. Sry haven't checked quality of vid... so here again: https://youtu.be/1IecD2i9P-I
  4. I noticed two little bugs. Not gamebreaking, just FYI: 1. When tweakscaling tanks, their volume stays at the original value. If I remember correctly there was a tweakscale interaction dll for 0.90?!? 2. I've build a patch for CryoEngines to have two tanktypes available for stock tanks. When switching between Default --> Cryogenic --> Default the existing tanks aren't updated. If the tanks are removed before switching or updated after, the behaviour is correct. TANK_DEFINITION { name = Cryogenic basemass = 0.000625 * volume TANK { name = LqdHydrogen amount = full maxAmount = 50% utilization = 10 } TANK { name = Oxidizer amount = full maxAmount = 50% } } //------------------------------------------------------// // Add tank type CryoEngines to all default tanks @PART [*]:HAS[@MODULE[ModuleFuelTanks]]&HAS[@type[Default]]:FINAL { @MODULE[ModuleFuelTanks] { typeAvailable = Default typeAvailable = Cryogenic } }// Add tank definition for CryoEngines Short Video, look at the value for Oxidizer... https://vid.me/kZJP
  5. I know about PreciseNode and Mechjeb ManeuverPlanner. My intention is, to have some stockalike easy click-only UI. If you like, you can call it an other UI for PreciseNode including prediction readouts. As much as necessary informations and a minimum of buttons and occupancy of screen.
  6. I'm annoyed about the user-unfriendly behaviour of the maneuver node gizmo. According to Murphys Law, when I try to click on the prograde button, for sure I will click one of the others first. So I've been thinking about how to simplify the interaction, especially when the maneuver node is over- and underlayed by some other icons and text... see picture below: It would be nice to have a separate gizmo somewhere, which is fixed (not rotating with view) with some additional informations and some small tools like preciseNode has, e.g. Snap Node to AP,PE,AN/DN, view next/previous node. An increment slider for increment steps of the vectors as well as time of the node (mousewheel or 3rd mouse button over gizmo-icons). Readouts of the predicted orbit values: AP, PE, inclination - in Targetmode: Distance of closest approach and rel. inclination. Perhaps +- one orbit buttons. Visible only in Map View, if at least one node exists. A quick and dirty pic to illustrate my thoughts: I'm not able to code a plugin. Therefore I hope sb. will attend to it. I've some concrete details in my mind, which I'd like to share and I can give some support if needed... except coding! Suggestions anybody?
  7. Some things in KSP become boring after you've done them multiple times, using different approaches failed again and again until mastering. That's because I love spaceplanes and planes in general. They always behave different, especially with FAR. And it's great fun to fly some small maneuverable planes without SSAS near-threshold to stall. Destroyed buildings and quaking mountains included. (ehm.. perhaps not the best methaper today...sry) Yep, and then I'm using Hyperdedit to load some EC for the first start of the generators, because I don't want to draw a KAS-Pipe during lowFPS EVA.
  8. I've tested without any mods except TE. The bug still exists. It seems to have some weird consequences how the craft is rebuild after decoupling. Quicksave: http://workupload.com/file/A40Gfd8Y ...quickload shows "Station and Satellite" ship... it should be in orbit prepared for decoupling the satellite with the next stage... when you switch back to the station part after decoupling it's all fine, but there is already weird staging of the satellite after decoupling. Accelerate the satellite until the station part is on rails. Then switch back to the station on map view... Kerching! Edit: When the bug appeared first, yesterday, I recognized, that the station part of the craft was doubled in tracking station, but if you choose the first one KSP showed emtpy space around Kerbin. The second one showed the same non-maneuverable bug. Perhaps it is related to how I build the craft, so I uploaded it, too. Stockparts only. Craftfile: http://workupload.com/file/FPIAf1Ld
  9. I've an issue with stageable docking port decouple. If triggered in flight, the stage with the docking port stays without resources and isn't maneuverable anylonger. When trying to go back to spacecenter it sets time back because: "[Log]: Active Vessel is under acceleration (G = 0.780494940469038). Cannot save." log entry: NullReferenceException: Object reference not set to an instance of an object at ModuleDockingNode.Decouple () [0x00000] in <filename unknown>:0 at TweakableEverything.ModuleTweakableDockingNode.OnActive () [0x00000] in <filename unknown>:0 at Part.ModulesOnActivate () [0x00000] in <filename unknown>:0 at Part.force_activate () [0x00000] in <filename unknown>:0 at Part+.MoveNext () [0x00000] in <filename unknown>:0 log download: http://workupload.com/file/27c0oVu2 P.S. Is there a way to tell KER or MJ that the decoupling of a docking port triggers a new stage? Edit: When toggling "decouple" manually it's fine, so it must be related to staging.
  10. Similar experience here with rockets, perhaps because something changed with the mass of fairings. For a standard 2.5m rocket with light payload I suddenly need 1/3 more fuel and therefore a Mainsail.
  11. I've had the same problem. The contract part for fly by should be fullfilled when entering Muns SOI. During testing, I've changed two things when the contract was completed: Warping through SOI change with max 4xwarp The craft was seperated into two crafts, one for flyby and one for orbit. I've changed the root part of the craft to the command module of the tourists stage. Before, it was the command pod of the orbiting stage. So one of these changes has been the cause for correct completion.
  12. After lifting over 30 crafts to LKO I've recognized, that an initial TWR of 1.6-1.75 is the most efficient. I mostly need between 3200-3300m/s for light and for heavy crafts. Record so far is 3050m/s. Go as fast as you can and try to do a proper gravity turn. The lower TWR the higher you'll have to start he turn - for high TWR around 50m/s vertical speed, for very low TWR perhaps when surface velocity is 100m/s and more. Slight burning effects above 10km seem to indicate the most efficient ascent path (height/velocity relation).
  13. Assuming that SQUAD did not the same failure with heatmanagement as they did for aerodynamics before 1.0. I guess that they depend on real physics for heatflow. That's said, IR heat capacity of a body depends on material and Volume, therefore I assume they use the mass of a body for simplification (for tanks I've recognized, that fuel is recognized too). Heat radiation depends mostly on surface area in reality. And everyone knows that heat flows from hot to cool mass. My conclusion: Use parts with high surface area relative to mass eg. solarpanels, airbrakes, structural panels etc. as heatsinks. Mount them near to the heat source. Perhaps even wings could be used as heatsinks, if they aren't the source eg during supersonic flights.
  14. I'm not familiar in which way KSP 1.0 handles the loading of textures. So far I've recognized, that if I use ATM aggressive the used RAM increases about 200mb. I've only a few part mods installed and I'm running openGL mode. What's the cause of this behaviour? I assume DDS conversion is only for faster loading in game and at the start to push textures to VRAM. So my question is: Is it useable to scale textures when using OpenGL? Does RAM usage benefit of scaling?
  15. http://forum.kerbalspaceprogram.com/threads/117153-Is-there-an-updated-map-for-the-new-Delta-V-s?p=1874833&viewfull=1#post1874833 As I mentioned in the thread above, I think it's possible to need less than 3000m/s. Ascent path depends on initial TWR.
  16. It's a mod called Kronal Vessel Viewer... [Defunct link removed by a moderator]
  17. This craft is capable to fly by the mun. It has enough dv to forgive inaccurate maneuvers, because you might not use maneuver nodes. My first attempt has dv = 370m/s left before entering Kerbins atmosphere Tricky is the ascent path: Always Full throttle - Start gravity turn when surface speed is around 80m/s (not the most efficient one, due to low initial TWR). http://imgur.com/a/p4BJo
  18. For now my best result is 3050m/s to 71,8km LKO - measured by mechjeb -. The ascending curve depends on TWR of the stages (especially first stage) and leads to different dv amounts needed, same as FAR. I think with a little tweaking, it's possible to use less than 3000m/s. This was the used craft: The initial TWR was 1.72 (with unused Monopropellant onboard). In FAR I´m used to start with 1.57 TWR.
  19. Great work! Nice to see your new models finished. I really like this stuff - definitely one of the mods I will download for 1.0 first.
  20. Last 0.90 crafts I made (they will be updated): SUKHOI SU-27 Replica Inspired by this video I've tried to build a replica of the precursor of the SU-35 - the SU-27. The goal was to perform the world famous cobra maneuver... though I only can perform it completely above 10km... Mods: B9 (intakes, Turbojets, Aerobrake) B9 proc.Wings BahaSP Adj. Langing Gears Procedural Tanks RemoteTech (Communotron 32) MFT FAR Use fuel load for balancing (more or less stability/maneuverability) Because the offset of some parts isn't saved correctly, I've made a video: craft file here Direct download Sukhoi SU-27 EADS ZEHST alike crew bus SSTO/HTOL: "THELONIOUS" A few years ago EADS showed their plans for hypersonic passenger transport in the future: I've made a similar SSTO which should be capable to reach kerbins moons and the suns SOI (refueled in orbit all planets) and return to Kerbin using a steep reentry trajetory. Use less fuel load for easier takeoff. As it is, it will gain height, when leaving runway (throttle up before toggling brakes). Mods: B9 B9 proc. Wings BahaSP Adj. Landing Gears MFT FAR/DRE craft file here Direct download FunkyndustryThelonious
  21. Was anything changed with ssas-system regarding pid reaction? I normally use it to fly HTOLs and adjust the trims manually for desired direction parameters, but with the latest release the plane starts to tumble like a boxer before getting knocked out? changing scalar won't help, it just effects the amplitude of tumbling. Also, Pilot Assistant - vertical control | vertical speed - seems to avoid high AoA in the last part of atmospheric flight around 30000m+, though the plane has enough pitch authority. It pitches down and causes negative vertical velocity. When switching back to stockSAS it's pretty much stable at high AoA (intended by design). Edit: found the AoA Limit...
  22. Indeed, especially because SR-71 has a long sharp edged body, which should create lift, compared to relative short wings at the back. It's the same vortex lift mechanism for the body. If I remember correctly they were very surprised during flight simulations that critical AoA is 14 subsonic and 8 degrees while in supersonic flight. But the transition between stable and unstable vortex lift isn't at a fix AoA. Eg. maneuvers like rolling can create non symmetric lift, which causes yaw torque at the body. But that doesn't mean, that the vortexes breakdown completly. As I said above the shape of the leading edge has a great influence to vortexes. Here is an example craft I´m working atm: It's the first version of a ZEHST ( ) alike crew lifter HOTOL, in KSP SSTO of course. Pictures are from the first test flight. I forgot air breaks, but it's rockstable during ascent and reentry, even at high AoA.Look at the wing shape and leading edge of the wings, from thick root to thin ends, sharp leading edge and a falciform overall shape of the wing. Can anyone confirm, that FAR doesn't recognize thickness and leading edge shape? Or is it B9 proc. wings, because at least in the VAB the colliders of leading edge aren't updating. Perhaps one of you might know, if there is a mod which contains ramjets? I'm also searching for high thrust turbofans like the ones of Tupolew Tu-22M which have 245 kN IR.
  23. Delta wings and their secrets... I've built a lot of them with FAR but not using RO. Besides things already mentioned, here's my attempt to explain whats happening. I'm not natively speaking english, so pls be lenient with me, my non-existing drawing skills and my technical expressions... When flying transsonic or supersonic it's recommended to use arrowed wings, but there are some special facts about them: Air flows like this at arrowed wings: As you can see, this could decrease vertical control when the tail is in the middle. For increase of control capabilities use multi-delta-wings and a bigger or two tails (I prefer All-moving-wings from B9 proc. wings) in the middle and/or like a winglet. In reality thickness of the wing and edge shape would effect airflow too, but I think FAR doesn't recognize it - changing edge and thickness has no impact to the stability numbers. Now airflow is closer to the fuselage. Pay attention to the lenght of the leading edge. It is greater which leads us to hypersonic flight: At arrowed wings and high AoA lift is created by air vortexes at the upper side of the wing. Thus even higher AoA up to 25-30 can be handled easily and increases lift in comparison to the linear method. This effect is known as vortex lift. I hope this link can help: http://soliton.ae.gatech.edu/labs/windtunl/classes/unstaero/vortflo1/vortflo1.html Don't hesitate to search for other stuff, it's really interesting, because the behaviour of the vortexes has to be modeled numerically for special usecases, eg. edges of scramjet inlets. Now long story short the vortexes are mainly related to the length and shape of the leading edge and the shape of the wing. Until the vortexes break down (at very high AoA) they are symmetrical and have the following pressure distribution: So for your instabilities: 1. Increase leading edge length - change wing shape - you can fly at higher AoA. 2. Use vertical control where the highest pressure occure. This is a simple example of your craft and FAR shows nice numbers (don't pay attention to Xw it's unimportant): I hope, you're able to build a stable shuttle now.
  24. In this case there is Wildbluetools.dll from Angel-125, which you can use for switching modules from templates. He uses Firespittercode so I´m not 100% sure if he implemented meshswitch or uses it as an extra module.
  25. B9 uses it for collider switch and it's working fine, though... ..."// If this is true, any colliders on the toggle objects also get turned on/off. It’s still recommended that you use colliders on switched objects as little as possible, and instead use a single collider for the part. affectColliders = true" FS documentation: https://docs.google.com/document/d/1iD52DfHft04Hb48TEhF5a4n5JOc8efUevdg5Y_QPICQ/edit# Example from B9: MODULE { name = FSmeshSwitch moduleID = 0 objectDisplayNames = Straight; Raised objects = Tail_S; Tail_R affectColliders = true }
  • Create New...