Gaalidas

I apologize if this has been covered, but I was reading in the help stuff in the OP that you can do something like this: MODULE { name = TweakScale type = stack defaultScale = 3.75 MODULE { name = ModuleEngines maxThrust = 1, 2, 3, 4, 5 } } Now, I'm having a little trouble with implementing modularity into the KerbalFoundries tweak scale implementation. I first exported the defined scales from the part config into a "SCALETYPE" config, but I am unsure if the "MODULE" definitions in the above example can be exported into a more modular location. As it is now, the set of values for the specific modules must be restated in the Tweakscale module. So, my question is... If I were to take the above example, and remove the engine module definition from it and instead stuck it into a "Scaletype" definition, would it work? If not, is there any way to define those values without the use of exponents in something similar to the exponent definitions? It seems to me that there should be a way to define those specific values for the various scales in one place and then simply call that set in the part config like we do with "type" and save having to redefine them in every single part.

Need a few small engines on the back of that little rover to give you that extra push out of the crater. I've heard KAS grapplers can help to pull somethign up a hill if you launch the grappler high enough that it can fall hard enough to grab the surface. None of that helps your currently stuck craft, however.

I'm full of those. I wonder what I'll call out next?

Hey, I won't claim to have a "better" handle on it, but I know enough to be dangerous. (Yes, dangerous... I've broken it all many times and I'm very good at it.) Now I just need to go look at your code and see if I can add a debug display of that new parameter you added for tweakscale support to the part's context menu so I can see if things are working as intended. Sometimes I wish there was an easy way to view all of KSP's variables and their current values. In other platforms there's always been a console window where you could call up the current cvars and whatnot, modify or monitor them at will and whatnot.

Really? Really? It's a set of parts, what more do you want? Honestly, "64 bits" is being passed around like it's the new cool greeting on the street. "Yo, how ya 64-bit goin', brah?" It's like no one is even paying attention to what they're saying. You don't make a "64 bit" edition of a few models, textures, and part configs. It's the same bleeping files! I swear, the human race is doomed. We're getting less intelligent with every generation! Gah! Amd I'm one of them! Now I'm sad. I'm just a stupid, sad, doomed human being. (Yes, I just realized I over-reacted to a misunderstanding of the comment. I admit it. Throw a 64-bit rock at me if it makes you feel better.)

Well, I won't clutter your already cluttered workload with a ton of new stuff, but I do intend to do a little experimenting. Who knows, I might stumble on something. What I lack in C# knowledge I make up for in configuration knowledge. We'll see if that helps me at all. As for the spamming stuff, no that's definitely not what I'm talking about. What I am referring to is that you can define a scale type, or the plugin variable exponents, in a separate configuration file and then simply reference them from within the tweakscale module in the part instead of having to redefine them for every part. Module Manager can also patch those definitions, but it's not actually necessary for these kinds of definitions to work. At this time, there isn't much need to modularize your implementation, but if/when you get this mod stable enough to warrant some massive content updates, it would save a lot of time and frustration to export the data into separate configs much like the official TS distribution does it. But that can all wait. I'll fiddle around and get back to you when I have something to show. In the meantime... get back to work you slacker! EDIT: As a good example, here's what I put together for a custom KF scaletype: SCALETYPE { name = KFScale freeScale = false scaleFactors = 0.75, 1.0, 1.25 scaleNames = Small, Medium, Large defaultScale = 1.0 } We then remove those parameters from from the module in the part and redefine the scale type from "free" to "KFScale" and we're good to go. I'm still researching whether or not we can define the module modifiers in the scale type definition as well, so I'll get back to you.

Ask him for screens and you'll get a video. What happens if you ask for a video? You guessed it... your computer will infiltrate your brain with nano-spores that will transform reality into a complete simulation of a kerbal... complete with the horrifying pain and death that accompanies a kerbal being killed for science. Be careful what you ask for. So, I was watching that video and thought to myself "but once we get the transparent pod stuff, we won't be able to see all that." So, I have to ask, is there a way that we can make those details, hopefully in an extra semi-transparent state, be visible on the windows from within the transparent pod? That would really enhance the immersion.

That's one scary looking planet there, kinda disappointing that it wasn't all screwy on the surface. As for atmosphere, I've been reading a lot of the custom planet threads lately and atmosphere is one thing people are having a lot of trouble with.

Don't forget some of my code alterations too... though, I didn't exactly, rigorously, test all of those. I'm curious... so I have this little tweaking mod that expanded the "free" scale type to allow anything from 5% to 400%. I can take one of your small tracks and make them larger than 6x6 mole tracks back to back AND on top of each other. I haven't tested it yet, but I'd love to know how you think it will perform at that scale? I think, however, we could make things a bit more modular if we separate your exponent controls from the part files themselves and create a custom scale type to handle your parts. I'll get to work converting that if you'd like. I'm also not too sure about the "free" scale type as a base, since that technically allows the user to circumvent any specified scale levels and can sometimes make it hard to keep different parts scaled by the same factor. Instead, I would provide a custom scale type with tested scaling values specified directly. Also, I noticed in your code that you've added the scaled variable to your calculations in some places. I also wonder if there are other parameters that could be scaled as well, which don't actually require making code changes, or at least not too many of them. I'm thinking things like the default repulsor strength/damping and stuff. I intend to do some testing personally and see what I can come up with. I've becomes rather familiar with your code lately.

I was sure I'd seen every error this crazy game could produce, but that one's definitely a new one.

yeah, that really does work. It took me a minute to figure out what the IVA was from, but it fits pretty well.

I hate it when that happens.

dag nabbit lo-fi, you never cease to amaze. Animations based on slider positions? sweet stuff there. Now, if we can get attached parts to move with the end of the arm (like we get with IR) you'd practically be reinventing the piston motor (now that you've already reinvented the wheel, that seems to be the next logical step).

Hey, I just gave this baby a try and guess what? [ERR 16:07:47.425] AssemblyLoader: Exception loading 'EVAFirstPerson': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'HullCamera, Version=1.0.5100.39113, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'HullCamera, Version=1.0.5100.39113, Culture=neutral, PublicKeyToken=null' Before you ask, yes I do have the hullcamera.dll installed. Not only that but, considering this is the only change I've made to my installation since my last run and I can assure you the errors did not show up last time, when that error showed up I got a whole slew of other errors regarding "System.Reflection" exceptions. It was fun, really... but it's also not going to fly.

Hey, the name's accurate enough if you factor in the foreign accent. "dat's sum tony whahl der!" Oh, I can confirm that the part icon fixer is working much better with his recent update. I actually discovered some duplicate parts that I wasn't even aware of due to his debug output, and I'd been using those configs for months.

You'll just have to copy whatever Squad did to make the launch clamps orient to the ground (except in rare instances in the SPH when it gets screwy) and procedurally extend to the ground, and make the connection act like the launch clamps. For the movement, you might be able to set up something like you get with IR parts, but you'll have to customize how the parts accelerate and the moment of launch-clamp release, instead of the instant movement of IR parts. I'd love to see a version of this oriented for a vertical catapultation (I think I just made up a word there) or at least near-vertical.

With the work it would take to convert them all, and the recent updates we've seen on the progress, it might just be a step in the backward direction to use any outside models. At the very least, those should be used as reference for setting up the Kerbal size version. Textures, however, might be doable.

Yeah, he posted a possible fix that I'm going to look at in a few minutes. The main event right now is that I have some updated information for you considering my tweaks. This time, I can actually post a successful test and some new data to merge in (whenever you feel like plugging some numbers in and "hoping for the best" result.) Any parts that go unmentioned were found to be perfect as they are. Alright, lets get started. AlphaMediumTrack: node_stack_001 = 0.535, 0.355, 0.0, 1.0, 0.0, 0.0, 1 node_attach = 0.535, 0.355, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,1 KF_MediumWheelALPHA: node_stack_001 = 1.385, 0.52, 0.0, 1.0, 0.0, 0.0, 1 node_attach = 1.385, 0.52, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,0 RBIInvertingTrack: node_stack_001 = 0.525, 0.0, 0.0, 1.0, 0.0, 0.0, 1 node_attach = 0.525, 0.0, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,1 AlphaRepulsor: node_stack_001 = 1.39, 0.315, 0.0, 1.0, 0.0, 0.0, 1 node_attach = 1.39, 0.315, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,1 AlphaRepulsorSurface: node_stack_001 = 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0 node_attach = 0.0, 0.0, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,1,1 ScrewTest: node_stack_001 = 0.545, 0.38, 0.0, 1.0, 0.0, 0.0, 0 node_attach = 0.545, 0.38, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,1 AlphaSmallTrack: node_stack_001 = 0.21, 0.13, 0.0, 1.0, 0.0, 0.0, 0 node_attach = 0.21, 0.13, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,1 AlphaLongTrack: node_stack_001 = 0.605, 0.295, 0.0, 1.0, 0.0, 0.0, 1 node_attach = 0.605, 0.295, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,1 RBITinyTrack: node_stack_001 = 0.375, 0.34, 0.0, 1.0, 0.0, 0.0, 0 node_attach = 0.375, 0.34, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,1 IE_RepulsorWheel: node_stack_001 = 1.385, 0.52, 0.0, 1.0, 0.0, 0.0, 1 node_attach = 1.385, 0.52, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,1 Skid: node_stack_001 = 0.0, 0.17045, 0.0, 0.0, 1.0, 0.0, 0 node_attach = 0.0, 0.17045, 0.0, 0.0, 1.0, 0.0 attachRules = 1,1,0,0,1 KF_SmallWheelALPHA: node_stack_001 = 0.33, -0.01, 0.0, 1.0, 0.0, 0.0, 0 node_attach = 0.33, -0.01, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,1 AlphaSurfaceTrack: node_stack_001 = -0.255, 0.0, 0.0, -1.0, 0.0, 0.0, 1 node_attach = -0.255, 0.0, 0.0, -1.0, 0.0, 0.0 attachRules = 1,1,0,0,1 KF_TonyWheelALPHA: node_stack_001 = 0.1, 0.0, 0.0, 1.0, 0.0, 0.0, 0 node_attach = 0.1, 0.0, 0.0, 1.0, 0.0, 0.0 attachRules = 1,1,0,0,0 And that should be the lot of them. Are you tired yet? Cause I sure am!

Well, I just installed your update for the TS stuff, and I'll see what happens. I think possibly NodeHelper was giving me false data. I checked my tweaks against your configs and it turns out some of my numbers were higher than yours, when in fact they should be lower since I am mostly copying the attach node and reducing the numbers on it for the stack position so that it looks plausible when attached. I then modify the attach node to match so it consistently attaches in both ways. It's possible that the same issue encountered with the icon size is also affecting how the numbers are being worked out by the other plugin. I've since reinstalled Nodehelper and I'm going to see what it looks like with some of those nodes reverted to the default. I'm not done struggling with this stuff yet! Worst case scenario, I'll see if I can weld in a little I-beam into the part without messing with the rest of the wheel's functionality so that I can get the visual-connection setup properly without having to adjust the node too. I'll keep you posted. Speaking of the icon fix, apparently the fix has been posted as a potentially separate plugin, though upon adding it to my installation it stalled my loading process every time i launched. It could be conflicting with parts of that fix that you've integrated into this project, but I'm not seeing any evidence to support that theory yet. More likely it has something to do with his plugin trying to fix parts without requiring the use of MM patches to apply the fix variables. It's just a guess at this point though. EDIT: So, to answer your question... I'm doing both actually. Adding and tweaking to both node types. Edit2: Oh, by the way, I noticed the icon size fix is working great, though the RBI invertible track seems to be spinning around a spot at the end of the track, and when the opposite end spins behind the rest of the mesh, the icon-area rendering system cuts the mesh off due to its depth being really small (or whatever you'd call it, sorta like setting a fog range to an insanely small number like we did back in the old days when our 3d accelerated graphics cards were little more than recycled computer chips glued to toothpicks and pumped full of electricity until they made something glow really nice.) Edit3: I was so not expecting that when I finally got around to clicking that link. What an unfortunate name that species has. FINAL EDIT: (I swear!) I think I have the node-placement issues ironed out. It's rather complicated, but it turns out that NodeHelper does indeed add to the original positions of the nodes when editing them so, if you tweak based on its output alone, the nodes will be all out of whack. What I did was first take down the position NodeHelper first reports, then I tweak the position of the node and take down the new data. I then calculate the difference between the two and add that difference to the original coordinates in the part config. I had to make sure I was incrementing/decrementing the numbers in the right direction based on whether I tweaked the node positively or negatively. I then applied all my tweaks and, if my test tomorrow goes well, I'll be ready to write my report. I'd do it now, but it's getting late and I just spent an hour sending that evil reaper guy a list of all of my mods (wrote it out by hand, and I have a TON of them) so he could maybe track down a bug with his official icon-fixer mod that was causing my load-ups to stall half way through every time, and succeed every time when his mod was removed. The part of that fix that you've integrated into KF does not affect me in this way, making me wonder if there's a conflict between the implementations. Anyway, bed time.

It's much easier with the node helper plugin, and I think I've eliminated that plugin as the root problem, though it complicates things further than it should. with NodeHelper, you can visually and mathematically alter the nodes in real time to get them where you want, though you'd better modify the part configs yourself before launching with a craft using modified nodes. What seems to be happening is that the node position is being set, the game shut down (LoadOnDemand mod freaks out when I do a database reload, and I can't launch without it), the part config edited to match the new values, and then re-loaded with a new launch of the game only to find that the nodes are resetting themselves to a new position each time. It only affects the tracks, and only the ones that you made. my thought is that the collider that controls where another surface-attachable object would stick to the part (if it were allowed) and/or the one that controls the clickable space around the part in the editor are interfering with the node placement. It's like trying to put a camera inside a brick wall without making a hole where the camera can sit. Unfortunately, in this specific situation, the brick wall is invisible and the camera is our stack node that isn't cooperating. EDIT: I just got that naming thing... very clever... and yeah, they might have issues. I'd so do it anyway though. EDIT2: That array is awesome. Lags a bit? You bet it does, and by design too! Honestly, if you build something like that and it runs smooth as silk, then you need to pinch yourself and wake up.

Well, as far as I can tell, I'm at a point where I can't go any further unless the models are modified with a visual attachment thingie, or I find some new information about placing stack nodes underneath the part's editor collisions. as it is, no matter what I do, the node is being reset to its default position. I don't know how KSP is storing that information, cause it's not in the persistence, and there are no MM patches modifying the nodes, and the node positions defined in the part should be correct because, when using nodehelper, I can load up the part and see that the node has been shifted off its position; I can then copy the correct position from the cfg into nodehelper and tell it to reset the node to the entered coordinates and the node will visually shift to that spot. So, I know that my coordinates are correct, but still I get the wrong position when KSP loads the part. It's driving me insane. I'm about ready to try and weld a stock truss to the side of the tracks so that I can position this thing better. I sorta wanna hear your naming scheme anyway, just for a laugh. When it comes down to it the part name doesn't really matter, as long as it properly describes what it does at a glance.

That is awesome! By the way, having some troubles with the stack nodes when using NodeHelper to tweak them. I'm doing some final fiddling before publishing my tweaks. Edit: So, the only thing I can come up with, after removing Nodehelper and still getting the attach/stack nodes being offset improperly after adjusting them is the possibility that the meshes could be interfering with the nodes. Could be something to do with the editor collisions that define the click-area for the part, or something of that sort. Either way, I cannot get the nodes to get close enough to the medium track's side to make them attach to a surface and still look like they are attached. Instead, they sit away from the surface unless you make use of the soft-attachment thing where you can bury surface attached objects within a larger object by shifting the mouse in the right direction before it snaps to another angle in angle-snap mode. Needless to say, this is simply unacceptable. Fortunately, this is only affecting the tracks so far. The RBI invertable track has a mounting bracket integrated into the model, and thus its attach node is perfectly aligned even after my adjustment. I'm thinking that the tracks you've made need something similar on them, a part of the model that is intended for attachment to the craft which is not contained within that collider. Either that, or the collider needs to be shrunk a bunch. Edit: Just watched that Wired video. Awesome stuff in there. One thing in that article that I noted as being slightly inaccurate is the part where it says something like "if you were closer to the black hole, it would seem like my time is sped up." This is true, yes, but only from the perceptual angle of the person closer to the hole. By the other person's perspective, the person closer to the hole would be slowed down. That's the funky part of the time/space/light dilation effect. The other useful bit of data for that is where things seem to disappear completely when crossing the threshold where light can no longer escape. The object would not, in fact, disappear right away unless you were right next to it, in which case the time dilation would not be in effect between the two observers. Instead, since light travels at its constant speed in relation to time, and time itself is being dilated, then the image would begin to stretch back towards the threshold and would slowly fade until an image of the craft rested in a 2-dimentional plane just above the "surface" of the threshold. This image would persist for quite some time if you were observing from outside of the time dilation effect. Another thing worth noting is that all that junk orbiting the hole is extremely stressed particles of light and left-over matter from the star's supernova which would have taken place just before the collapse. It's a failure of the star in producing too much iron in its core when it swelled during the end of its life-cycle. The resulting explosion throws all that matter out, which would have vaporized the planets that were orbiting at the time (which means those planets in the movie had to have been attracted to the system after the collapse, or they were originally ice-dwarves at the far-reaches of the star's SOI) and then collapsed into the black hole. The matter is then pulled back in, but not all of it at a perfect angle to simply disappear. This means that, if indeed that particular black hole was spinning at near-light speed, you have a lot of highly charged and thermal-emitting particles of star-stuff that are being pulled around it. while these particles are what made up the star, and due to time dilation they would appear to be active, the light emitted from them would be extremely low when viewed from the atmosphere of a planet like the ones orbiting the hole. The result would be a frozen wasteland with a dim light at the noon-time that would barely feed your solar calculator, and the magnetic affect on electrical system would wreak enough havoc to make a happy little EMP generator seem like candy in the hands of a child. That means your calculator is going to be spitting out martian swahili in response to your mathematical queries. All that aside though, good movie and highly recommended.

So, a few observations from my attempts to adjust some errant stack nodes on a mod I am collaborating on. First of all, there are some parts (no pattern detected) which habitually refuse to be written from. by that, I mean that no *_NH.cfg file is created no matter how many times I hit the button, and no errors are produced from what I can see. Second, I have several objects which have both an attach node and a stack node in the same orientation and position (allows for consistent attachment via KJR-stiffened stack node, for use with specific rover bodies with wheel stack nodes, or standard surface-attach node in the same orientation and position for wheels in which a standard surface attach is the only option available). When the results of the modifications are written, I've found that one of the two nodes will have incorrect data. Specifically, the attach node will be correct, but the stack node will be bumped away by roughly the size of the node's spherical representation in both the X and Y axis. Another thing I noticed is that when a node is selected in the NH editor window, the orientation tends to be bumped from standard "1, 0, 0" (for an X axis orientation) to "1.25, 0, 0." I went on to test this thoroughly and discovered that even if I took down the coordinates for the node manually and updated the configurations on my own, upon loading them in-game, the nodes are again bumped out of alignment, and upon checking NH to see what's going on, again I notice that the position for the stack node has been offset. My final test is about to commence where I will see if this happens without your mod installed. The really crazy thing is that when I edit the ones that refuse to write an *_NH.cfg manually, the node offset issue does not occur. This is what leads me to think that this could be part of this mod rather than a stock game issue. I will know that in a few minutes after my final test.

What, are you camping out at the movie theater so you can nab a particular scene when you need it? Or is it better if I just don't ask those kinds of question?

Alright, I've got a little tidbit here that totally stalled KSP load. Far as I can tell, it's related to this mod, but I've included the previous few lines just to be sure. [LOG 16:14:17.574] PartLoader: Compiling Internal Space 'Squad/Spaces/mk1PodCockpit/internal/mk1PodCockpit' [LOG 16:14:17.590] PartLoader: Compiling Internal Space 'Squad/Spaces/PodCockpit/internal/PodCockpit' [LOG 16:14:17.627] PartLoader: Compiling Internal Space 'Squad/SPP/Mk2CockpitStandardInternal/internal/mk2CockpitStandardInternals' [LOG 16:14:17.696] PartLoader: Compiling Internal Space 'UmbraSpaceIndustries/ExpPack/AES/Spaces/internal/AESInternal' [WRN 16:14:20.087] PartIconFixer, Didn't find a ConfigNode for oxiac.IAGM2; skipping [EXC 16:14:20.147] InvalidOperationException: Operation is not valid due to the current state of the object System.Linq.Enumerable.Single[UrlConfig] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) System.Linq.Enumerable.SingleOrDefault[UrlConfig] (IEnumerable`1 source, System.Func`2 predicate) PartIconFixer.PartIconFixer+<>c__DisplayClass5.<StartLoad>b__3 (.AvailablePart ap) System.Collections.Generic.List`1[AvailablePart].ForEach (System.Action`1 action) PartIconFixer.PartIconFixer.StartLoad () LoadingScreen+.MoveNext () I have no idea what it means but, considering it showed up right after a warning from your mod, it seems a little suspicious to me.