Jump to content

TiktaalikDreaming

Members
  • Posts

    1,972
  • Joined

  • Last visited

Everything posted by TiktaalikDreaming

  1. Firespitter-core actually. For reasons. I should convert to texture replacer for the simple fact that it does what's needed and nothing else, while firespitter core does a few things, most of which aren't used. But when I was developing, I had firespitter installed, but not texture replacer, and firespitter has an option to change texture maps, so....
  2. There's several items of "optimism" in the design. :-) A lot of it is immaturity in aerodynamics, a lot of which they were pioneering. But they were pioneering without a lot of data. And, the A-12 design was mostly just a set of numbers for "we'd need X fuel, with Y engines on stage A, which means X2 fuel on stage 2 with Y2 engines, etc etc. And then with the thrust to mass and volume of the engines, it led to short fat stages. Nothing beyond the A-10 really had much work put into actual design.
  3. About 100kw to get to 15m/s based off real world vehicles. How the kW relates to stuff in Ksp is still up for grabs. To go faster requires a lot more juice though.
  4. Agreed. Having the orientations,emtpy transforms, colliders etc all part of the blender (or whatever) set up is a massively better way of working. Having done that, and early on, not done that, I think I can say that with conviction. Not breaking that prefab is a powerful tool. :-)
  5. Now that I've actually googled it, I think the spitfire/p51 style is probably actually doable as a symmetric part. It won't look exactly like (particularly the spitfire, with it's forward angling) the originals, but the P51 is actually not far off being an OK KSP part for symmetry. We're basically talking a side folding landing gear that is flush with a surface when folded. And, I don't think symmetry issues will stop the MiG-21 landing gear, so much as they're incredibly specific to the fuselage/wing shape. You'd need to make a whole bunch of different models to cover all the different wing-to-fuselage arrangements, and then hope the player mounts them just right. I think they're probably the sort of thing that would only get done if someone was working on a Mig21 mod where the wings and body were all custom, and maybe the wings had stack nodes set-up to match where the wheels should go. But, as a general part, I can't see how it would work.
  6. That was the exact plan. :-)
  7. OK, done. Updated. (Blender doesn't use the same glow system as Unity, so, the glow is missing below, cos I'm too lazy to do it twice)
  8. Unwrapped, and beginning to replicate parts. It's taking a long time, partly because I'm finding the weather too hot to think straight (ie; it forces me to drink too much beer) and because when I sit down at my PC, I start flipping through social media stuff and then get angry at politics. Which again leads to beer.
  9. I've been struggling a bit with overlapping constraints getting animation to match nicely for the unfolding Warp Drive, but I sorted that out. Each constraint in blender seems to overlay. So to follow two points, the first constraint you set as 100%, and the second as 50% so you end up with the average. Was driving me nuts. Anyway, animation unfolding with one copy of everything. So one nacelle, one set of levering arms. Eventually there'll be two nacelles, both with arms above and below the extension cord thing.
  10. I've never written a module for KSP, although I've done some minor adjustments to them. IFF I do get around to adding modules for this, the first two space magic things will be an anti-gravity drive and an "inertial damper". Basically something to turn on or off the "Kerbals pass out at High G" setting from the tweaks menu. It only takes a couple of Epstein moments before you realise that's a good idea. But I doubt I'll be able to do that any time soon.
  11. Updated to 0.7 with a new Warp Drive. This one is a fixed twin outboard nacelle type, with animation just for the uncovering the glowy bits. The nose parts changed to a red glow as a stage early on with a green glow the exposed X shape looked a bit too much like a console logo. The old warp drive is still there, but will get replaced with a new part that unfolds. So there will be two options. The new fixed format, which I intend to be more powerful. And an unfolding version that's a bit weaker, but, well, it unfolds.
  12. I'm not sure bad quite covers it. That's plain awful. I've seen it before, but only on internal mini-project type things where they get non web-devs to code up a web site for something. Minor rant about "IPS"; And, they have the gall to call it IPS? Tells you how much they're aware of security that they'll name their forum the same acronym as a general term for a security system. After a quick look at the InvisionPower thing, the https option either is just admin etc as noted, or the whole site. Which in the current version breaks the chat addon and a few minor bits and bobs that no-one on the forum forum detailed. Looks like the system uses full path links rather than relative, and so you set a prefix basically of either http:// or https:// And Squad aren't using the IPB/IPS chat system anyway. It'd depend on what else gets stuffed up. That's for the software InvisionPowerBoard. Which is what the hosted service Invision Power Service runs. As to whether you can access that option (it's a manual edit of the global_config.php file) on the service offering is something I couldn't find out. Sounds like a pretty daft way of enabling https though. They should just stick an apache (or whatever) reverse proxy in front of the silly thing with some basic security things enabled and https on that if the software has issues with ssl.
  13. Yeah, I went and checked. My $5 is still happening. I (easily) justify it by contrasting it with the alternative hosting costs for building my own mod hosting solution. Plus @VITAS is doing all that webhosting work, which saves my from relearning all that. But, if all those hosting a mod donated $1, there clearly wouldn't be $1000/month, but there'd be more than there is I suspect. Not all mod authors can afford such things, but for those of us with a bit of disposable income, who already sink lots of time into KSP, I feel it comes in way below many subscription type models for paying for games. I fully expect to never see a kerbalcon, but the SSL on a website with passwords should be a no-brainer. Dammit, what decade is this?
  14. I'm more thinking a fixed part mainly, with the deployment animation being more of an opening hatches to expose the warp whatsits. But there is room for a few variants, and I still like the idea of some unfolding/extending type thing. Here's my current thinkings; And a quick mockup for KSP (including a full shield part on one nacelle that I forgot to remove); I'm intending the glowy bits to all be behind doors/hatches until you engage the engine. I've only built the front dome cover so far, but that will be the most awkward. The side bits will just be simple sliding door things. I'm thinking I'll do at least two warp drives. A smaller, less powerful unfolding one, and this sort of fixed, more powerful one. Use the two ideas as a trade off between convenience and power.
  15. Without being explicitly treky (madly dodging potential copyright issues), that's kind of where I wanted to go, but as an inline part that unfolds to two nacelles. It may end up being a non-unfolding part, because when you start to try to 3D model a large part unfolding from a much smaller part, you either cheat outrageously or run into serious issues about how a large part can actually unfold without being basically a large thin sheet. I wanted the part to be an inline part but not requiring the last node (eg engines) in the stack. And thus the unfolding. But it achieves the same result with no unfolding of course. But RoverDude's code has the provision for unfolding, and everyone loves some animation. Maybe I'll just uncover some glowy bits or something. And, for this at least, don't worry about killing old designs by suggesting things. As I said "I'm not really happy with it", and I do intend to have a serious rethink. I'd also like to have a few different sizes/speeds/etc. Requiring differing amounts of warp field generators etc.
  16. Updated once more. The warp drive now impersonates a finished part. More elaborate shapes/animation to come, cos I'm not really happy with it. Also fixed the wrong sized resized eludium tank. And the overly enthusiastic shading on the warp core. Part images updated on the OP
  17. Awesome. I'll add in the parts I've been working on (mostly smaller editions of existing parts) and include it in the main download. Nice to see you're using :NEEDS[] :-D Fixed up. Also, I've gone through and made stock TechRequired all experimentalScience or experimentalElectrics. The engines did have tech requirements, but the intents etc were all over the shop and made it hard to spot. The config files are typically something stolen from a squad part then edited. So, although the parts had a techRequired entry, it was usually horribly wrong. :-) @PART[SOEngLong]:NEEDS[CommunityTechTree] { @TechRequired = ultraHighEnergyPhysics } @PART[SOEngShort]:NEEDS[CommunityTechTree] { @TechRequired = ultraHighEnergyPhysics } @PART[SOEngShort2.5]:NEEDS[CommunityTechTree] { @TechRequired = ultraHighEnergyPhysics } @PART[Size4SmallETank]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[Size3SmallETank]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[Size2SmallETank]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[Size4LongETank]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[Size3LongETank]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[Size2LongETank]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[linearHWRcs45]:NEEDS[CommunityTechTree] { @TechRequired = expGriddedThrusters } @PART[linearHWRcsSml45]:NEEDS[CommunityTechTree] { @TechRequired = expGriddedThrusters } @PART[linearHWRcsBg45]:NEEDS[CommunityTechTree] { @TechRequired = expGriddedThrusters } @PART[linearHWRcs90]:NEEDS[CommunityTechTree] { @TechRequired = expGriddedThrusters } @PART[linearHWRcsSml90]:NEEDS[CommunityTechTree] { @TechRequired = expGriddedThrusters } @PART[linearHWRcsBg90]:NEEDS[CommunityTechTree] { @TechRequired = expGriddedThrusters } @PART[linearHWRcs]:NEEDS[CommunityTechTree] { @TechRequired = expGriddedThrusters } @PART[linearHWRcsSml]:NEEDS[CommunityTechTree] { @TechRequired = expGriddedThrusters } @PART[linearHWRcsBg]:NEEDS[CommunityTechTree] { @TechRequired = expGriddedThrusters } @PART[HWTank]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[HWTank2]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[PnEReactor]:NEEDS[CommunityTechTree] { @TechRequired = unifiedFieldTheory } @PART[PnEReactor375]:NEEDS[CommunityTechTree] { @TechRequired = unifiedFieldTheory } @PART[PolFldGen]:NEEDS[CommunityTechTree] { @TechRequired = unifiedFieldTheory } @PART[PTank]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[PTankMed]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[PTankSmall]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[QuantumEnt]:NEEDS[CommunityTechTree] { @TechRequired = unifiedFieldTheory } @PART[TF2HWConverter]:NEEDS[CommunityTechTree] { @TechRequired = unifiedFieldTheory } @PART[TF2HWConverter3]:NEEDS[CommunityTechTree] { @TechRequired = unifiedFieldTheory } @PART[TFTank]:NEEDS[CommunityTechTree] { @TechRequired = exoticFuelStorage } @PART[WarpCore]:NEEDS[CommunityTechTree] { @TechRequired = unifiedFieldTheory } @PART[SOWarpDrive]:NEEDS[CommunityTechTree] { @TechRequired = ultraHighEnergyPhysics }
  18. Oh, yes, great. I'd completely forgotten about tech tree things. I just kind of assumed everyone using this would be sandpitting. :-) If you upload it, I'll add it as a patch in the main download. And probably look through the existing parts for some stock tech nodes or something.
  19. Yeah, thanks for making me feel old. You couldn't have left off the year?
  20. I'm not sure what I might have done differently, but it's all working fine with my install. It might be fussy about the Unity version. I think the recommended is 5.4.0p4, which I'm using. And check you're using the latest Part Tools. And (found this one out just recently) check you have no zero size/blank config files in the KSP GameData folders.
  21. Yeah. It's nice to know the collider is being used, but it doesn't allow much custom tweaking. I should try a non-collider invisible box as well. I know KJR uses whatever's there, as adding an entity that is neither visual or collider is the fix for some weird stuff with large tension forces (aka parachutes). It's also possible the collider is only consulted for joint stiffness for surface attach joins. Gawd,... I'm digging myself an experiment rabbit hole.
  22. A bit more experimentation and it's looking like a lot to do with collider sizes. First up, there's at least two algorithms (of sorts) and the worst one will be the one causing the problems, because there's always two joins. None of the Squad surface nodes have sizes. Which should have been a hint. :-) Some of my really bad results, the joint I was theoretically messing with wasn't having any trouble. The decoupler's node, is the decoupler attaching to the main body of the craft. The join that usually (not always) has trouble is the surface attaching of the booster to the decoupler. So, I messed with the TT-70 decoupler, the one that sticks out on framework, and made it longer. The interesting thing with this decoupler is the collider exists only on the outside portion of the part (ie, where you attach the booster), but not where it itself glues onto the main body. So, my stretched decoupler showing collider (orange highlighted thing) in blender; With everything else the same, no node size value, same mass, everything, the longer collider makes a huge difference. There's still a visible torquing going on, but much less. I'm not sure how the length is making the attachment to the core vehicle stiffer. It doesn't twist enough to get that collider to contact the main body. But it seems likely the extra stiffness of the booster to decoupler at least is based on the size of the collider, or possibly the connected surface area, or something. There's most definitely an effect. Long decoupler result; Stock decoupler, just before a booster left the building; And it's likely that increasing the mass to match the larger part, and extending the collider (or adding a second) so it contacts the body of the craft, can all help add some stiffness.
  23. Yeah. I have previously (0.8, 1.0.5 etc) seen differences in stiffness with node sizes, but only on fairly large parts now that I think back. Maybe there's a bunch of algorithms and it takes the worst. :-)
  24. The size setting did have an effect way back when. Not sure nowadays. Tested. Once for regular and once for an identical stock part. No noticeable change in stiffness, but the radial decoupler with node size increased didn't break. It MIGHT suggest a higher breaking point. Still, a long decoupler, with a matching collider and an attach node in the middle somewhere, *should* do something to stop too much movement in or out. AND, I first tried the test with KJR still on. And, well, that does seem to hold everything very nicely in place. So, all stock parts, using the "Hydraulic Detachment Manifold" mounted near the top so the boosters would force inwards as much as they could. Followed by Taking the Hydraulic Detachment Manifold, quickly editing a copy of it's config to just have ,8 at the end of the attach_node definition (8 is huge,WAAAY beyond what that should be) and retrying, the boosters still wobbled about. They didn't seem to quite hit that wobbles causing wobbles feedback loop though, and got all the way to booster exhaustion. Only one test of each so far, and attach points were done by eye, and aren't the same from craft to craft. And, further testing suggests all sorts of things. No idea anymore. Sometimes there's no difference, other times it seems a larger node size makes things worse. I suspect there's too many small inputs causing large outputs to say anything, and I'll defer to the wisdom of @NecroBones re there being no detectable effect.
×
×
  • Create New...