Jump to content

EndlessWaves

Members
  • Posts

    1,359
  • Joined

  • Last visited

Posts posted by EndlessWaves

  1. I don't know where the line lies as to what constitutes something complex enough to be copyrighted but there are plenty of mods that already include modified squad configs on both of squad's sites (here and spaceport) so they don't object at the moment and in future if they want to phase it out they're likely to do so gently and pleasantly - banning everyone who's ever uploaded a modified config file would completely destroy the community.

    They have added an override system in 0.20 where you can override specified properties of another config file but I'm not sure if it'll do exactly what you want yet, have a look at the 0.20 stickies.

  2. So could there be a way to add it to the list of planets

    That list you've quoted is just the terrain detail level settings. They're not responsible for anything you're after, and indeed if you're using a solid model rather than a quadtree they won't apply to you anyway.

    Try looking at the components attached to the existing planets in game, perhaps something like a celestialBody component would generate the gravity and keep it visible (you'd need a plugin, there's no support for adding planets in config files).

  3. The thing that worries me (about what research may discover) is... why didn't the original DR developer use a different joint type? Is there some huge downside or issue preventing it?

    Damned Robotics is very old now, I'm not sure if it was released the same version the plugin system came out but if was one of the ealier plugins. I would think at the time r4m0n had enough on his plate understanding the system to think about making a custom joint type.

    A custom joint does raise the possibility of additional problems but I don't think they'd be insurmountable.

  4. Not a lot of work has been done on them. The plugin system has access to huge amounts of the game (and can play sounds itself) so it's almost certainly possible, but it's also entirely undocumented so it takes a some trial and error to work out how to do things.

  5. Only resource-wide, the density of a resource determines it's weight and it's defined in resource nodes. (GameData/Squad/Resources for defaults).

    Bear in mind that anything that works on mass flow rate will produce the same result if you raise the amount but lower the density to compensate, for example engine fuel consumption.

  6. If it happens with multiple mods then it's likely a problem your end, It could be a whole range of things and without any details about your system (operating system, extractor program etc.) it's difficult to guess. Almost all mods are in an archive package though (e.g. a zip file) so one thing you could try is an alternative extractor/unarchiver program.

  7. it was accelerating constantly while cruise was active.

    Yes, but for how long? 5 seconds? 30 seconds? 5 minutes? The response is somewhat slow at the moment and it can stay above the targeted speed for a while (at a decreasing rate of acceleration). That'll be fixed as it gets tuned better but if it kept accelerating for dozens of seconds it sounds like a bigger issue.

    Also hit action key 3 (reverse gear) but didn't notice anything change?

    It only works in general mode where the motor is throttle controlled (rover mode and manual mode have dedicated reverse keys) and it won't apply the brakes automatically so if you're already going at some pace it'll take a while to slow down.

    Couldn't the 'forward' direction somehow be determined from the track itself? Maybe as an option? What I'm trying to do here is this

    That is how they function, the command pod is only used as a tie break if the combined forward vector of the tracks adds up to a vector of less than 0.1 length. Unfortunately the game's default symmetry tends to put equal number of tracks facing in opposite directions so that case comes up far more often then it should.

  8. It's actually very close to the part transform transform.up, but off by a few degrees, which actually makes a big difference. I wonder if thrust vectoring is part of the issue? I'm guessing thrustTransforms.forward gives the actual (vectored) thrust direction, and balancing the fuel to that has a nasty positive feedback effect -- the engine gimbals to stay balanced, fuel is rebalanced so that is the new set point, drains a little, and the engine has to gimbal even more, so the fuel is rebalanced to be even more uneven. In that case, any thoughts on how to get non-vectored thrust direction?

    Yeah, ModuleGimbal rotates the thrustTransform object as it's the engine module that applies the thrust. Starting (neutral) rotations are stored in initRots of ModuleGimbal. Although if it's linear you may be able to simple work backwards; angle = current angle - maximum gimbal * steering (-1 to 1).

×
×
  • Create New...