linuxgurugamer

The problem comes down to whether or not the part is mirrored. If mirrored, everything gets flipped, including the direction of movement. I'm working on a solution, part of which will be proper instructions, because there are two modes of operation. Works one way with node attach, a different way without.

It's quite possible it's unnecessary, but I'd have to go digging to be sure there aren't any other things related.

Been a long time since l looked at this. But, it doesn't have any code, so the only thing that might need touching are config file. That being said, try it using the current version of IFS, if you see issues, then go look at the config file for that part which has problems. And don't be afraid to ask for help

I don't remember the details, but I think I had to replace both underscores and spaces with a dot, which is why the following is there: UrlDir.UrlConfig config = Array.Find<UrlDir.UrlConfig>(configs, (c => (part.name == c.name.Replace('_', '.').Replace(' ', '.'))));

Patience, little one. Your time will come

Yes

@blackheart612 I looked at AirplanePlus for inspiration, and saw that the only parts you had to use mirrorRefAxis were wheels and an engine prop. I'm beginning to think that I'll have to make left and right parts because of the difference in textures

Grrr. Fix one thing, another breaks. The fix for the elvons is ro remove the "mirrorRefAxis" line which I added to get the textures to properly mirror, but then the movemen of the surface get reversed on the mirrored side @blackheart612 I think I need your help. Look at the post above. When I have these lines: //Either one of the following node_attach lines: //node_attach = 0, 0, 0, 1, 0, 0 node_attach = 0, 0, 0, 1, 90, 0.0, 1 //and this: mirrorRefAxis = 0, 0, 1 The textures get mirrored properly, but the movement of the control surface gets reversed in the mirror If I don't have the mirrorRefAxis, then the textures are not mirrored, but the control surfaces work normally In both cases, it was in surface attachment mode Using the second node_attach reverses the direction of the movement on BOTH surfaces Thanks in advance

I must have made that beta before I added that, sorry. Interesting that the mod elvon is also backwards, same as the rudder. Might be a clue. Thanks for the tests, I should be able to do something by tomorrow evening, if not sooner

In my view, I didn't think there were too many parts that this would affect. This was before @Poodmund mentioned ReStock I can compile against MM, and test before using it if MM is there, if not then use alternative code. Avoids messy reflection stuff, I've done this in another mod I guess the question is whether JC is the only mod which this is an issue. If it is, then doing a targeted solution is fine, if not, then maybe something else. This is the current code which accesses the URL: static public string FindPartMod(AvailablePart part) { if (configs == null) configs = GameDatabase.Instance.GetConfigs("PART"); Log.Info("ModFilterWindow.FindPartMod, part.name: " + part.name); UrlDir.UrlConfig config = Array.Find<UrlDir.UrlConfig>(configs, (c => (part.name == c.name.Replace('_', '.').Replace(' ', '.')))); if (config == null) { config = Array.Find<UrlDir.UrlConfig>(configs, (c => (part.name == c.name))); if (config == null) return ""; } var id = new UrlDir.UrlIdentifier(config.url); return id[0]; } As you can see, I load all the configs locally for speed, I imagine that a dictionary with the key being the part name and the data being the URL would be fast enough to keep up

It's not the end of the world if nothing gets changed, but I do get questions every now and then about where parts are in JC. And, the example from @Poodmund is exactly what I'm referring to.

I'm trying to not have too many variants of a part. I would prefer if TS could stretch in a single direction as well as all three directions. I may just make 3 base parts of each part, stretching them as required (I want a 2x and 3x original length) As it is, I'm including configs for installs without TweakScale, and that is a major PITA. The five initial parts balloon into 35

Of course, it makes sense. When you go back and change it, there is time involved in making changes, some of which would involve partial disassembly. Think of it as a car: When you buy a car, it cheaper to get the AC from the factory rather than getting it installed after. Installing after means extra work in taking part of the engine apart in order to add the compressor, etc. (yes, i know that most cars come with AC standard these days) But it's still faster to change an existing vessel than to build a new one from scratch

Not at this time. The models have changed, so it's more of a rewrite than a port

Are you confusing what a model is vs a texture? Because the same model can have different textures. A "model" in this instance is a very specific think, referring the the internal setup of the part, the textures is what you see on the outside

@SpannerMonkey(smce) Maybe you can help here. I have a rudder part from the old B9 Shuttle Style Wings. It has both a rudder and two other surfaces which are the airbrake (split, opens to each side). My problem is that the rudder is moving in the wrong direction but the aeronautic effect is correct; ie: I apply left rudder, the rudder should swing to the left but it goes right instead. Any ideas? I am barely a beginner when it comes to 3D modeling, I have Blender 2.8 with @taniwha'a plugin, and have made some minor changes to other parts. If you want to look at it, it's in this file: https://www.dropbox.com/s/b5xvfgk2bpric4h/UpdatedB9ShuttleWings.zip?dl=0 the files are: GilB9Shuttle_Wings/Parts/B9_Shuttle_TailWing.cfg GilB9Shuttle_Wings/Parts/B9_Shuttle_TailWing.mu Thanks in advance

just an FYI, i just tested the original tail fin from the mod (unchanged) and the control surface is reversed in that as well :-( At least I know it wasn't anything I did, but now I need to get it reversed. Will work on this later

I may just write a small module which will inherit the ModuleAeroSurface, and disable the visibility of the unnecessary fields in the airbrakes. The tailfin may need some work in the model, I'll have to go back to the original and see what changed. yes. The stock parts shouldn't have nodes on them. Thanks

I agree, but I'm using the ModuleAeroSurface which is what the stock airbrake uses. If I have to I'll go back to the FSairBrake, but I'm trying to not, because it doesn't show the drag properly. I've also been busy with KCT, which is why I wanted some other eyes on this. Were they surface mount or node attach? I'll guess you tried it using node attach, and that's what's the issue. Surface attach works fine in my testing. The node attachment is a work-in-progress, and you have to follow specific steps which I didn't list above. Specifically, you can't use mirror symmetry with a node attach, parts have to be added individually I just ran a few tests before I go to work. I see that I didn't include the new elvons, which will make it a bit easier. I put the wings on a plane, turned off all nodes, and put a Big-S Elvon 2 on in mirror symmetry mode. then launched it. The elvon worked properly on both side,including the deploy direction. I do see that the fin has a reversed deploy direction, and am very aware of the mess in the PAW for the vertical fin

Fixed Being worked on, not sure if anythinig can be done yet They are, in the PAW there should be an option called "Attachment", using that you can go from 0, 1 or 2 nodes Stock bug, or limitation Same I'll have to look, I hadn't noticed that before.

Thanks, I need to know if you were using Tweakscale or not

Is it possible to have TweakScale only scale in one direction? ie: have a wing and stretch it front to back (to make it wider), but keep the length the same?

Essentially, yes Not really. At the beginning of a career you only have a few parts available, also, building vessels costs money which you don't have a the beginning of a career

Without getting too technical, Stage Recovery (SR) gets notified by the game just before the game removes the stage as debris in the atmosphere. It then looks at the stage and calculates what the final speed would be after all chutes were deployed. It's an estimate, but fairly reasonable. It ONLY works on stages in the atmosphere, does not work for things in space

Probably not. Janitor's Closet uses the URL from the part itself during the filtering process