Gaalidas

That's gonna be a visit to hell for you I'm afraid. I'm involved with a number of projects that involve me compiling my own variations of other mods to figure out compatibility issues and such, so there's so many possibilities. Besides, I have enough mods installed that it takes me a good hour or so to compile the list. I'm not desperate for your mod to work for me though, considering I really do actually need to see the exception in the logs to track down the cause.

Now that's what I'm talking about. I look forward to it.

FAR on the other hand is big only in what it does... not so big in any other concern.

It definitely looks like an awesome project... but my brain already hurts from my other worldly rigors... and this isn't helping that at all. You can take that as high praise, however, considering it takes a lot to mess up my brain. That assumes my brain is working right in the first place... they could never fully agree on that topic...

Whaaa....? I don't follow you at all there. Kerbal Joint Reinforcement solves the wet noodle rocket syndrome. If your altitude-100k rockets, as you say it "goes to Kerbin again" then I'd say you forgot to do a gravity turn and/or circularize your orbits. Either way, that mod is so low on the ram usage, you'd have to load 30 of them on top of each other to even notice the difference. EVE and Porp I can understand though. Texture Replacer on it's own is nothing, but if you're actually replacing large textures then that's quite the factor too. - - - Updated - - - Well, at least I've got that skill down then. Yup. Totally nailed it. At least I'm trying to be constructive here, which is totally in context with the WIP status of the mod. If I didn't like what you've done so far, I wouldn't have even tried.

Of course, now that you've done all the extracting, you could just put up the resulting files and save us from needing to actually use the plugin for the stock planets... but don't mind me... I'm just a silly duct tape owner, I don't really know anything.

I doesn't work because it's not formatted correctly. First of all, if you're adding this to an already existing scaletype which does not have the parameter you have specified already in it, then you want: @TWEAKSCALEEXPONENTS[InterstellarFissionPBDP]:FINAL { partMass = 3 }Notice that there are no spaces between the node type, the node name, and the ":final" part. No new lines either, just all one long un-spaced, single line entry. However, if the parameter you are specifying (the "partMass" parameter) already exists and you are editing it's value, then you need to add an @ symbol in front of it so that MM knows to edit the parameter instead of adding a new parameter of that name. If, however, you are adding a completely new exponent node, then you don't even need MM to add it and can follow the original exponent entries as an example of how to set them up. Bottom line, avoid spaces and new lines when giving MM the information about what part to go look for.

yeah, well, I'm out of ideas here. I tried adding the "scale = 1, 1, 1" in the node, commenting out the scale parameter outside of the node, and leaving rescaleFactor alone, and all I got was what I had in the first place. I'm done trying to figure this out now. I'm just not too sure what the real problem here is. There are countless mods out there that can use mesh or model parameters interchangeably without issue either way, and which use all sorts of scaling values. This ranger body is a real bugger. We'll just leave it in the designer's hands then... and hope for a miracle.

That's just the thing. Why should I need to fix this in the first place? I went looking for examples of a working way to deal with the issue and you'll never guess where I found it. That's right, it's here in the Endurance folder: name = commandEndurance module = Part author = benjee10 MODEL { model = Endurance/Parts/ENDURANCE/commandEndurance scale = 1, 1, 1 } rescaleFactor = 0.9 Notice the rescale factor is not 1, and yet so far no complaints about it resizing itself when reverting. My point with all this is that if the other two crafts of this mod are all sharing textures in a rather efficient manner, and the ranger has to load a separate large texture that is exactly the same for each part, then there's something that needs to be addressed. I'm trying to make it work in the meantime for my local copy, but in the end the developers of this mod need to decide if they're going to use an efficient way of handling models and textures or not, and not have a whole third of their project bogging the user's system down with redundant textures when the rest is more optimized. And before you say it, yes I know the endurance itself has a separate texture for each part... I can excuse that because it's such a large and awesome craft, and at least the texture isn't exactly the same for each part. My hope is that I'm not coming off as the rear end of a donkey here. I'm just speaking up for the voiceless masses that don't have the experience with modifying configs or texture formats for performance reasons.

Jam a seat on the back and that would be even more awesome. As it is, very interesting design there.

In which case the config must be altered to not do any extra scaling if it's already scaled in the first place. I know there are ways to fix the scaling issue when using "MODEL" nodes. I believe it involves making use of the scale parameter inside the node, which calls for three dimensions of scale. I'm looking around my damedata directory for examples now. I've seen a few cases where "scale" is removed from the part level, and instead defined inside the "MODEL" node to redefine the scale of the part, while leaving rescaleFactor at 1. That might be the ticket.

that craft file keeps telling me it has found invalid parts and cannot be loaded. I think I discovered my problem with that part though. So, what I was doing is just starting a new craft and grabbing the body part as my base part. the nodes are floating out of place, and the other parts appear to be unmatched in scale. It's like it's being rescaled after all the nodes are created. I'm not done experimenting with this thing though. There could be a bad interaction with the replacement from a "mesh" parameter to the "MODEL" node I had to do in order to set up texture sharing between the parts. I can't afford to have anything loading the same large texture for multiple parts like that if I want KSP to run smoothly.

I've got nothing. I don't see any window either, but then I may not be experiencing any exceptions at the moment. I sorta wish I would get an exception though, cause I'm getting some oddities in the game right now that would sure benefit from a trackable exception or two.

Mmmm... prunes.... Unfortunately, in KSP, the number of mods you have doesn't make much of a difference. What matters is whether or not they are really freakishly huge mods. You could have 200 small mods with no problem, or three huge mods and crash with more precision than a gravity turn with mechjeb.

Alright, this is really weird. I don't usually have these kinds of issues, honest. So, the ranger looks great... but something not right on my end. the main hull is scaled a bit smaller than the rest of the parts, and the attach nodes are floating in the air like they think the hull is still some other size. On top of that, most the parts are still scaled to match the nodes, except for a few specific parts. For instance, the middle part of the wings seems to fit in precisely the right spot, but the side wings float ahead of the spot they would normally sit. Finally, the craft file seems to contain invalid parts. This is really not a normal occurrence for me.

Mechjeb is weird, it seems to take notice of everything else that's installed and has issues with most of them.

Now you really must take that as far as it'll go. How many hulls can you paste together like that before it becomes unusable?

indeed. After KSP went beta, and the holiday season ended, a number of the regulars disappeared. Large scale mod releases have been replaced by a plethora of small simple mods that each tweak something tiny, together probably managing to slow down the entire program with all their individual tweaks. It's the passing of an era in KSP's history.

Amen to that.

Sure enough, loaded fine. I don't get it, but it's working now so we're good to go.

I'm downloading now, will let you know what happens. That ranger is really badly optimized as far as memory usage though. It's loading a copy of ranger.(whatever filetype you use) for every separate part of the craft. I highly doubt my issue is with an animation. It seems to me the error is directly related to the node that the configs are trying to add, attaching it to the transform instead of by coordinate as most other parts in KSP do. Still, I do have some mod parts elsewhere that add nodes in this format, so I can only assume it has something to do with the transform that's causing the error, or that the node type is the wrong type. For instance, it could be trying to make an attach node (surface attachment) when the transform is better used as a stack node. I'm not a model guy though, so I'm just fishing in the dark.

So, I tried it again and the result was the same. It does not like having to add a node at the transform. From the log: (Note: Yes, I did rename the part config file, just in case it's different. I couldn't stand having to make the game load that texture file so many times, and so had to patch thing together so that all the parts could share the same texture file.) [LOG 06:06:33.961] PartLoader: Compiling Part 'Endurance/Parts/RANGER/Parts/rangerEngineleft/rangerEngineLeft' [LOG 06:06:33.984] Added sound_rocket_hard to FXGroup running [LOG 06:06:33.986] Added sound_explosion_low to FXGroup flameout [ERR 06:06:33.990] Part: Cannot add attach node. Transform of name 'leftEngineNode_eng'And from the output_log.txt: PartLoader: Compiling Part 'Endurance/Parts/RANGER/Parts/rangerEngineleft/rangerEngineLeft' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Added sound_rocket_hard to FXGroup running (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Added sound_explosion_low to FXGroup flameout (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Part: Cannot add attach node. Transform of name 'leftEngineNode_eng'It never reached the other engine, but I could wager that it would have trouble with the other one as well.

Did he now? I missed that idea...

Okay, so I admit I didn't have the time to see if it happened again. It's a stall on the loading process, and quite far into it too. That takes a lot of spare time and, as a student, I have less of that than I'd like. I suppose we'll see what happens. - - - Updated - - - Well I didn't, so that's awesome.

slight problem detected: [LOG 16:34:44.068] PartLoader: Compiling Part 'Endurance/Parts/RANGER/Parts/rangerEngineleft/rangerEngineLeft' [LOG 16:34:44.092] Added sound_rocket_hard to FXGroup running [LOG 16:34:44.093] Added sound_explosion_low to FXGroup flameout [ERR 16:34:44.097] Part: Cannot add attach node. Transform of name 'leftEngineNode_eng'My loading process stalled at that spot.