Jump to content

barfing_skull

Members
  • Posts

    158
  • Joined

  • Last visited

Reputation

16 Good

Profile Information

  • About me
    Rocketry Enthusiast

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm not using kOS...didn't know about that one. I looked it up and at first glance it seems like it might have some promise here, though I'm guessing there's at least some learning curve to it. I suppose being a software engineer I should at least understand the programming aspect, but how that works in the KSP environment and what it actually does to craft could be something interesting to explore. The rover is actually fairly flyable, with the Vertical Velocity mod which will use engine power to keep it at a preset distance above ground, and just SAS for decent but not great stability. Set VV to 1000 m above surface, it'll stay there as long as it's got enough power and the orientation of the thrust allows it. Obviously if the craft tilts in pitch or roll, that changes the thrust orientation, which can be useful in small amounts to move forward, back, sideways. But I'd like something that returns it to flat with zero pitch and roll for even finer grained control, and the ability to let it just cruise for a while without worrying about the roll or pitch going off level. The purpose of the craft is that I'm playing the Beyond Home planet pack, and Hydrus has a non-oxygen atmosphere, and floating islands (like on Pandora in Avatar) that I want to land on. So I'm working on this hovering rover using electric fans to get onto those. Thanks for the tips!
  2. This *almost* works, the problem being that when I rotate (yaw) the craft more than 90 degrees it pitches over upside down in an attempt to point the nose in the original direction, which is not what I want. I need it to ignore which direction the nose is pointed in the horizontal plane.
  3. So here's the craft in question below. I added the docking port on top as suggested, but it changes all the controls and the navball, since the control point is relative. The nav ball shows it pointing up, but the craft is not pointing up, it's pointing east. The control point needs to remain pointed forward/east to have the controls and navball act correctly, unless there's some way to change the nav/control not to follow the "control from here" part, but have MJ follow that new control point. I'm guessing that's not possible?
  4. I've done similar things before with attaching a probe facing up, but in that instance the control point is facing upwards....which screws with the navball when you're trying to fly something in the same horizontal orientation of a plane. So maybe if there were a way to have the navball follow something other than the point of control. I'd have to experiment with that and research if there's some way to do it. The funny thing is that in concept what I want to do is really simple...and multiple mods don't really implement it that way.
  5. Thanks, I looked at it a bit more carefully, still not quite what I want. I probably should have elaborated in that what I'm trying to fly is essentially a VTOL rover using lift fans, with a propulsive fan at the back for forward thrust. No wings. So, a helicopter, more or less. So the traditional spaceplane stuff doesn't really help, since it seems geared toward flying a fixed wing aircraft, and this isn't that. The roll component of MJ's Aircraft Autopilot is useful, but there's no way to zero the pitch. I've tried Kramax autopilot, too, but it has some odd side effects on this type of craft. Kramax has worked well for me in the past for fixed wing craft, but it's not quite the same with this. Tried Atmosphere Autopilot but that's way more complicated than what I'm looking for. I've got a mod for vertical control of the VTOL with an auto-height function that works well. Vertical Velocity Controller Redux. I just need a way to keep the VTOL flat, zero pitch, zero roll, for cruising. Obviously it's good to be able to turn that off and fly manually for landings using pitch/roll, but for longer flights keeping it flat and just letting Vertical Velocity keep it at a constant altitude above terrain is what I'm looking for.....so something more akin to Smart A.S.S. Except, that doesn't flip the craft over when I turn it around. Flying a VTOL upside down is what is often called "undesirable" unless you're practicing lithobraking. One would think this would be a simple, common thing to desire in attitude control, but a lot of these mods don't really seem to implement it quite that way. Cheers, and thanks!
  6. [Moderator's note. This series of posts was originally split off from the MechJeb thread, since it's really more about "how to accomplish a thing" with various mods being discussed as possibilities, rather than being about MechJeb itself.] Hey all. I'm having a problem doing something that seems simple with Smart A.S.S. but yet the way to do it is eluding me. Essentially I want to keep my craft's roll and pitch at zero when it's in the air, regardless of which direction it's facing or moving. What I want is SURF-> Up (which does a pitch of 90 degrees) to have a pitch of 0 degrees, and complete freedom in the horizontal plane. I've tried ADV -> SURFACE_HORIZONTAL but it requires a horizontal reference which in my case is irrelevant, I want control over where it's pointing in the horizontal direction. I could probably do this by having a "control from here" part that's oriented vertically, but "forward" for this craft needs to be in the horizontal plane as it's designed for atmospheric flight. There's SURF -> SURF then check both PIT and ROL to 0, HDG unchecked. which works fine until I point the craft in another direction more than 90 degrees, at which point it flips it over on its back to point it in the original direction, which is definitely not what I'm looking for. The craft needs to stay horizontal relative to the ground regardless of the heading, not flip over front to back. Any hints on how I can achieve this? Cheers!
  7. I think just switching to Parallax 1.0.1 did the trick. Figured I'd try one change at a time until it worked. Thanks!
  8. I'm seeing the same thing. At closer than about 500m distance, the terrain goes black. Unfortunately, that's not a playable condition. In order to rule out mod conflicts, I started with a clean install and added just the Beyond Home necessities on top of stock 1.12.2 + expansions. Disappearing terrain still happens. Parallax is 1.3.1. I'd like to know if there's something I can do with this version of KSP to fix this as well.
  9. I'd only seen it on re-entry before, but a launchpad test produced the same problem when I hooked up the drive section with the nuclear salt water engine and the radiators to something that would at least launch. I found a lot of these in the KSP.log at the time this was happening: [EXC 09:38:11.820] NullReferenceException UnityEngine.Renderer.get_material () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) SystemHeat.ModuleSystemHeatColorAnimator.Update () (at <c7392b4010df46a7af1d4bc1aaa6002c>:0) [EXC 09:38:12.235] NullReferenceException UnityEngine.Renderer.get_material () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) SystemHeat.ModuleSystemHeatColorAnimator.Update () (at <c7392b4010df46a7af1d4bc1aaa6002c>:0) [EXC 09:38:12.650] NullReferenceException UnityEngine.Renderer.get_material () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) SystemHeat.ModuleSystemHeatColorAnimator.Update () (at <c7392b4010df46a7af1d4bc1aaa6002c>:0) [EXC 09:38:13.067] NullReferenceException UnityEngine.Renderer.get_material () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) SystemHeat.ModuleSystemHeatColorAnimator.Update () (at <c7392b4010df46a7af1d4bc1aaa6002c>:0) As an aside, I'm on 1.11.1, Linux, with a bunch of other mods as well. Cheers!
  10. So I'm having a problem with the XR-500 and XR-600 radiators, namely, that when they break off in the atmosphere it completely brings the game to a standstill, and I'm getting about 1 frame per 4 seconds. I have a fairly beefy setup. I put these on sacrificial stages, or I de-orbit the vessels, but as soon as they blow off the vessel, performance drops to where the game is unusable. I'm going to take a guess in that this results from the game needing to handle the physics and aerodynamics of the 8 billion little pieces that come off as they disintegrate. The particular stage I'm using has 8 XR-500's and the same number of XR-600's. Is there any way to have these parts meet their aerodynamic demise with more grace? Could they break off in one part? They're just flotsam at that point anyway. Cheers!
  11. Well, starting from scratch, adding RSS, then my other mods, seems to have solved the immediate problem and it works well with fast FPS and looks fantastic. Although I'm still getting the popup about no RSS textures installed, even though they are. I'd love to have clouds and the like, but from reading back, the only thing I see is RSSVE as an add-on to EVE, and that no longer works from what I read? Are there any other visual enhancements for clouds or the like that work with the current RSS? I have scatterer and EVE there, but I think they'd need configs for RSS. Cheers, -BS
  12. Yeah, from a few posts above it was noted that it should work with 1.11. I'm not seeing any actual problems other than the huge FPS drop. I actually added RSS to an existing installation with other mods already in place. Again, no problems with that other than the expected odd placement and disappearance of vessels when their planetary bodies are moved or no longer exist. I think a lander I had on Mun ended up on Titan, presumably because the configs just renamed it. Perhaps I should start with a fresh install and add mods from there. I don't care about my savegame much, but I do want to copy over some of my craft. The 8192 textures look fantastic. 4096 are good, but it's a huge improvement to 8k. Mostly I'm wondering what kind of graphics settings seem to work for people. Again, one other thing I could try is run the game at HD res, but I have a good video card and a 4k monitor for a reason...but there are at least a couple things here I can work on.
  13. So this is one of those mods I've known about for some time and finally wanted to get around to trying it. The installation seems like it worked properly, although it gives me a popup about not having textures installed. They are installed under GameData/RSS-Textures, right where the documentation says they should go, and the textures look like they're present in-game, from what little I've looked at it. So any idea why the warning for no textures? But my big problem is a huge drop in FPS when entering any flight scene with physics, to the point of being unplayable. With the stock planetary system, my FPS was fine. I tried both the 8192 and 4096 textures, as my machine is fairly beefy. Both had about the same amount of FPS problem. Tracking station and map views were lightning fast. RSS 18.3 KSP 1.11.0 (Linux) KopernicusBE_1.11.0_Release67 My machine is an i9-9900k, 32G RAM, RTX 2080. I play the game at 4k res. Any idea if some kind of setting might be causing this? Anything I could tweak or change? What are reasonable graphics settings, if it is actually graphics rather than physics, for the above? I know CPU can be a bottleneck, too. If it's the physics, what's different about them in this mod? Cheers, -BS
  14. Found this mod while looking for planet packs and from the descriptions and from what I was able to try of it, it looks really cool and really promising. However, while I can see the new planets in the tracking station, they appear pink/purple when on the surface. I can think of two reasons for this, one, that I'm on KSP 1.11 or two, that I'm on Linux. I suspect it's the latter. I got the version of Kopernicus (build 58 I think) that was compiled for 1.11. Everything seems to work except for the planet surfaces, and it gives me errors about BeyondHome and Parallax not being installed upon game startup. I have Parallax 1.0.1 as the documentation states. Reading through this and the Parallax forum, does this sound like a synopsis of the state of affairs? 1. Parallax only currently runs on Windows machines. I think this is because of a DirectX 11 dependency. I saw mention of working being done on this, but also that you lacked a Linux dev machine? Parallax is what gives the terrain detail, and makes things look really cool, from what I gather. 2. There is an effort to decouple BeyondHome from Parallax, and that would make it work as a standalone planet pack. However, this would ditch a lot of the cool graphics, right? So, if 1. were to come to fruition on Linux, it would have the same eye candy as intended. This is obviously the best outcome. 2. would result in a playable planet pack but without some of the graphics that seem like they make it more special. So is that pretty much the state of affairs? Cheers!
  15. I think this is the thread already, looks like the same issue I saw: https://github.com/KSP-CKAN/CKAN/issues/2481 I'll see if I can add any relevant details since it looks like the initial report was OSX.
×
×
  • Create New...