Jump to content

TiktaalikDreaming

Members
 View Profile  See their activity

  • Posts

    1,972

  • Joined

  • Last visited

 Content Type 

Everything posted by TiktaalikDreaming

  1. TiktaalikDreaming
    Yep, Edit, and the Additional Authors section. Never used it, but just confirming that's where it is. :-)
  2. TiktaalikDreaming
    Just a quick note on not confusing movement with force. The line of Suspension is a freedom of movement axis, not force. In fact, the fact that the wheel travel is constrained to that axis guarantees forces are holding it to that. Travel up and down the suspension is driven by the spring rate and damper, travel outside is governed by modulus of elasticity of big chunks of (usually) steel. They generally flex a lot less than a spring. So, usually you just summarize and say there's no movement in those directions. But the forces are there, and need to be there. Please now return to your regular scheduled programming. (PS: this is really in response to @damerell, there's zero wrong with Shadowmage's description. I just thought it needed my brand of clarity, cos we're all egotistical in that way)
  3. TiktaalikDreaming
    "upgraded" to 5.2.4f1 from 5.3.4 and uncommented my MODEL tags. All working fine. :-/
  4. TiktaalikDreaming
    That's the reason I'm lurking on this thread. KF seems like the likeliest source of well functioning off-road wheels and tracks to use so my Rover isn't completely incapable of driving over a curb without taking a run up. It started as a "how oversized are stock rovers?" test, fell into a "can't not make it due to rover pun" and is now taking over my life. But a set of wheels that weren't large disks with shopping trolley wheels at the bottom would be nice. So here I lurk. :-)
  5. TiktaalikDreaming
    I just want to take a moment to say that while a lot of this is solidly in the "should be doing, and we've all known it for decades" that many big websites don't follow these basic principles, and that Spacedock does. In particular, the number of Government departments that don't, and financial software packages the don't, are simply amazing. The number of unsalted or even unhashed password databases out there is staggering. And, also for the record, thinking you'll never get hacked, or that having been hacked means you're slack is plain wrong. Everyone gets hacked, because you can't win all the time. How you deal with it is what matters. And Spacedock, aka @VITAS, @GenPage and co have responded really well. Top notch work guys. Especially with the animales. :-)
  6. TiktaalikDreaming
    Gah! I've had this for a while now and never looked to see if there was a fix. :-( Works perfectly. Thanks
  7. TiktaalikDreaming
    Destroying my admin building in my sandpit test game in 3,..2,...1 And done
  8. TiktaalikDreaming
    I've found the 64% edition is close enough to 1.25m that you don't really notice. It does struggle lifting stock KSP pods due to their mass, but it works if you drop the fuel a bit, tweak a few things etc. But it wasn't really designed to lift pods so much as warheads. Anyway, here's a shot to match the 50% vs 70.3% examples from last page; You can see there's a slight difference in diameters, but it's not enough for me to worry about.
  9. TiktaalikDreaming
    I never checked which Squad props do the misplacement. I shall in future (cos it's pretty annoying). But definitely just the Squad props in my experience.
  10. TiktaalikDreaming
    The limitation isn't about how a sphere would collide, but with how a Unity sphere-cast collides. If these things made sense, the wheel collider's raycast would be fine. But in both cases they attempt to model the wheel/sphere and the suspension in a single fudged approximation. Or at least that's my take on it.
  11. TiktaalikDreaming
    I suspect it's to do with Unity version (plus parttools). I upgraded from 5.2 (before 1.1 came out with it's part tools and version recommendations) because I ran into a bug where it kept crashing when Win10 locked the screen, and I've noticed other part tools things that don't seem to function for me. I might need to downgrade. I ended up extending my screen lockout to ludicrous times anyway cos it excrementss me on a home PC. Maybe if I switch to 5.2.4f1 I can get that emissive generating tool to work. :-) I'd run into THAT bug already with the stock props, so I did check it quite thoroughly. Unless they end up rendered many miles away, they're just not there. That's not to say they're not just too far away to see. Also, I've been creating my props at 0,0,0 as a precautionary measure. I've been aiming at that for all IVA related stuff, even though it ends up being a bit of a nuisance when working with multiple props. I'm putting my money on Part Tools interacting with my Unity version, which isn't the recommended one. And, I'll test that. I'm accumulating reasons to switch to the recommended. :-)
  12. TiktaalikDreaming
    I just thought I'd put this here in case someone else comes across this. There's a reasonable chance anyone making props will be using RPM 'cos it's awesome. If you make a prop. It works, you see it in KSP and it functions fine, but in the Unity editor it spawns as just a transform (which makes it pretty awful to get placement and rotation right) then it might be the issue I had. It seems like if you define the MODEL { model = } in the prop config, then it's mysteriously not rendered by Unity in the editor. Even though it's layered right, works fine in KSP, unity don't like it. Possibly a case of the exact unity version I have mixing badly with part tools or some such. Dunno.
  13. TiktaalikDreaming
    Yep. Also, to update, I just recently found what this was. In my config I had the MODEL{model = /path/modelname} section suggested in a few places. I removed that (most props just seem to work on the assumption that there's a mu file in the directory and that's what to use) and it's all fine again. So, something about the MODEL tag is perfectly fine with KSP, but not the Unity + part tools combo. And deleting it, without replacing it with anything (eg: mesh=) works fine in both KSP and Unity.
  14. TiktaalikDreaming
    That makes sense. I couldn't find any examples in ASET, but I was looking using findstr when I'm used to grep, so maybe I was looking wrong. I'll try that later (at work now). Awesome, it worked. And now I can see that in the doco as well. Missed it 'cos I'm an idiot. Thanks @MOARdV Now I just need to figure out why my props aren't rendering in the Unity editor. But the steering wheel is done, the "tacho" is done and the other more standard gauges all work.
  15. TiktaalikDreaming
    Thanks for the notification. For my 2 cents pile-on for useless advice that I see starting up; I hope you didn't totally bin the suspect system. Normal best practice is isolate, stop, contain, but keep everything so you can analyze what went on. That assumes a few capabilities though, like being able to keep the old hacked system isolated while building a replacement. And, as usual, off-box logging is your friend. :-)
  16. TiktaalikDreaming
    Hi, I've had some messing around and generally great success getting RPM props set-up. But I can't seem to make the RPM_MATH_VARIABLEs work. If I try referencing them in the prop, the prop fails to load. I'm basing the config on the notes at https://github.com/Mihara/RasterPropMonitor/wiki/Custom-Variables I can't find existing examples to steal config from. :-D I've generally made peace with not using the MATH variables and moved on (there are plenty predefined variables after all), but I was wondering if this was a known issue (maybe broken in 1.1.X?) or if I'd just mucked up the config. Example config I've been trying; PROP { name = DefTorq MODEL { model = KerbinRover/Props/DefTorq/DefTacho } MODULE { name = JSIVariableAnimator refreshRate = 3 VARIABLESET { scale = 0,20 variableName = ENGINE_TORQ controlledTransform = Needle localRotationStart = 0,0,-120 localRotationEnd = 0,0,120 longPath = yes maxRateChange = 1 } } } RPM_MATH_VARIABLE { name = ENGINE_TORQ operator = MULTIPLY sourceVariable = ACCELFORWARD sourceVariable = MASSWET sourceVariable = HORZVELOCITYFORWARD } Ta. :-)
  17. TiktaalikDreaming
    Hi, I'm having a weird issue in Unity that's making it quite tricky to get an IVA right. I made some new props using Raster Prop Monitor (although I seriously doubt it's an RPM issue so much as a prop issue). I made the meshes as normal through blender, imported them fine, tagged as Kerbals layer, exported out, created props config, and I can adds them to an IVA via the part tools screen just fine. But the added prop mesh is invisible in Unity. The transform of where they are is fine. And they show up in game just fine, and function fine. But obviously placing them just right by iterative guesswork and reloading is going to make me lose hair, turn to the bottle, or both. Searching for visibility issues with props has netted me a vast collection of reminders to set the layers to get things visible in KSP. But that's working just fine. It's Unity that's not showing things. HALP!
  18. TiktaalikDreaming
    Yep, I'm lurking like mad on that thread. :-) The latest test video shows their wheel collider doing exactly what stock KSP wheels can't do. Apply force when the wheel isn't touching directly down. Somewhat important for any rover I would have thought. I do still want to add a small tracked vehicle like the Hagglund Bandvagn, and it's not going to happen without tracks.
  19. TiktaalikDreaming
    The biggest change is in internal room. 7 Kerbals in the 50% scale rover was a bit like a clown car, but it looks about right with the 64% scale. Comparison (with gratuitous dashboard dev shot) of internal spaces;
  20. TiktaalikDreaming
    That IS the resized one. It's only going up by 28%.
  21. TiktaalikDreaming
    Heaps of space.
  22. TiktaalikDreaming
    Please see where I said; Once resizing it I noticed I had more room in the cabin and I'm currently busy populating props on the dashboard and adding oxy tanks and life support consoles. And writing my own speedo prop. I did find the brilliant ASET pack of props, but the velocity scales are completely out of touch with ground craft. So I've done my own speedo, and I'll be adding some other props as well. There's no way of doing an odometer, or a tachometer for that mater. I'll probably do up a "forward acceleration" dial as a placeholder for a tacho. Or maybe a liquidfuel rate of change. It seems the RPM_MATH_VARIABLE system isn't working. Or not for me anyway. It could be syntax though, as out of the 3 packs of various props I have, non have a math variable. I will be doing car style (aiming at LR Defender to start) fuel guages and any other guage I can lay my hands on.
  23. TiktaalikDreaming
    I was guessing you knew. I wasn't sure the person you were responding to knew. I did try at once stage a many staged, legs at each, for a kind of leg-glitch-powered orion, but it never worked beyond the first stage.
  24. TiktaalikDreaming
    The legs are pre1.1 so they'll always explode until they're updated. You will get the same effect with other non 1.1 legs.
  25. TiktaalikDreaming
    Pretty sure any flex would be a really small effect (although maybe on very gentle turns at speed it could be dominant) compared to slip. Think about how long a track's surface is in contact with the ground, and usually backed by a fair amount of rigidity. There'd be intra link flex, and general motion of the links, but the wheels will hold the track to a line. It means a fair chunk of slip at the front and back during turns. If they didn't reduce ground pressure dramatically they'd be ripping roads to shreds. As it is, a heavy tracked vehicle will still rip up a road a fair bit. EDIT: Dammit, I should read the other posts before posting. Yep, agreed, interesting issue, and I'm sure tracked vehicle manufacturers would know, but yeah, for KSP, probably doesn't matter.
×
×
  • Create New...