Doxel

Thank you, mysterious stranger. You have made my day.

Sounds like a mod name. I will officially take your word for it. ...yeah, I'll definitely just be taking your word for it on this one. Thanks, dogstar.

I've been using this mod for three years and I just now realized that I have no idea what RLA stands for. None of the readmes ever said. Thanks for making me feel really weird, RLA.

Giving me a second type of situation to query adds another bit to the puzzle, although it is still not working entirely right. Both vessel.situation and protovessel.situation work if you are asking about the currently active vessel, but I am still getting wonky results with unloaded target vessels. Protovessel.situation seems to always be able to detect if an unloaded vessel is landed or splashed, but it calls orbiting, sub-orbital, and escaping all just "orbiting". Regular vessel.situation seems to be always able to detect landed or splashed too, but it calls everything else "flying" until I switch to, view, or otherwise load a second craft of any kind. Rather confusing. So the same exact vessel that is currently escaping Kerbin's SOI would show up like this initially: targetObject.GetVessel().loaded == FALSE targetObject.GetVessel().situation == Vessel.Situations.FLYING targetObject.GetVessel().protoVessel.situation == Vessel.Situations.ORBITING ...and then like this once a second vessel of any kind loads: targetObject.GetVessel().loaded == FALSE targetObject.GetVessel().situation == Vessel.Situations.ESCAPING targetObject.GetVessel().protoVessel.situation == Vessel.Situations.ORBITING The vessel situation system continues to elude my understanding.

I tried splitting it out into two bits like that, but no luck. It still matches to Situations.FLYING for anything off the ground even when it should be Situations.ORBITING. And I am getting the autocomplete suggestion list, so it is definitely Vessel.Situations.ORBITING. A bit of testing determined that I can get an orbiting body to register as orbiting if I am within a kilometer of it, but otherwise it just returns flying no matter what. This makes it sound like the game can only figure out the situation of a loaded object, but I know that can't be right because the Tracking Station lists every vessel's situation correctly when none of them are loaded. Any other ideas? I am at a loss. EDIT: Okay, little more testing, and it turns out it isn't being near the vessel that I am trying to read the situation of, it's just having seen another vessel. Any other vessel. When I first start up KSP and launch a vessel, everything comes up as Situations.FLYING. If I switch to any other vessel and come back, everything comes up correctly. I have no idea what could possibly cause this and am thus compelled to blame dark wizards. If anyone has an idea, please let me know. In the mean time I am going to declare Vessel.Situations and all of its enumerations to be officially cursed by evil spirits and try another avenue of attack. I plan on making use of the patched conics system. As long as the next conic is not escaping or crashing, I will assume the targeted vessel is in orbit. Wish me luck. EDIT: Patched conics work but it's awkward and I have to test for a lot more edge cases that the conics don't differentiate between. If anyone knows how to get the situation variable to work right for unloaded vessels, I would still appreciate hearing from you.

I have what I hope is a relatively simple problem to solve. I just want to know what a vessel's targeted object is doing. I tried the following: if (vessel.targetObject.GetVessel().situation == Vessel.Situations.ORBITING) { // stuff } It's never true. It seems that "vessel.targetObject.GetVessel().situation" always equals "Vessel.Situations.FLYING", whether it is orbiting, escaping, sub-orbital, or whatever. I'm sure I am making some sort of simple obvious mistake. Anyone know what I messed up?

Really? Works for me. The icons might be borked, but if I hover the cursor over them I can read the popup Tooltips and see what to click to make new alarms just fine.

Were you using any other mods at the same time? For me the icons and menus are broken, but the alarms still go off when they should.

As far as I can tell, yes. It still runs for me fine as far as the actual functionality of the mod goes (although the icons don't seem to display right anymore). I haven't done extensive testing to see if it this is still true in an unmodded clean install yet, but it's the results I got with a pre-1.4 save and all the mods turned off but this one. And may I just say thank god for that. This is the most valuable mod to me. More than Texture Replacer, more than Engineer, it's all about this alarm clock for me. There is no way I'm keeping the timetables for twenty flights straight without some help.

That makes perfect sense, Cetera. Thank you for the detailed answer. I suppose that by default it would look the same anyway, since there are only four stock veterans. I was mostly just curious why you split them off. And thanks again for making my favorite suit pack. I really appreciate it.

Cetera, I couldn't help but notice that you separated out some of the same class into multiple suits, particularly with the veteran suits. Was there any reason you chose to do that? It looks like the only files in more than one of these folders is identical, so it seems like they could all be combined. I actually tried this, and put all the files for CetPilot, CetOrangePilot, and CetPurplePilot into the same folder. TRR correctly made regular pilots red, male veteran pilots orange, and female veteran pilots purple. Were you just splitting it up so you could make orange non-veterans if you wanted? I can't really think of why else they would be different suits when they have no real overlap. I mean, you did combine the badass and normal helmets, so why not combine the veteran and normal suits?

Clever Solution. Although, come to think of it, why not just rename TRR's main folder? If you just added an @ and called it @TextureReplacerReplaced, then you wouldn't need two folders for the mod.

Yes, if you wanted to avoid any conflicts then you would need to specify for each suit. Just use the structure I put above, duplicating it under the name of each suit instead of using DEFAULT_SUIT. You do not need to include settings that are not changed, so just add entries for the four EvaGround_NoAtmo entries and the visor entries. No ModuleManager needed, as long as you move your cfg to load after the default cfg.

Yeah, in fact I tested pretty much exactly that. I made a file that looked pretty much just like this: TextureReplacerReplaced { Folders { Default = Cetera/Default/ Suits = Cetera/Suits/ } ClassSuits { Pilot = CetPilot Engineer = CetEngineer Scientist = CetScientist Kolonist = CetKolonist Miner = CetMiner Technician = CetTechnician Mechanic = CetMechanic Biologist = CetBiologist Geologist = CetGeologist Farmer = CetFarmer Medic = CetMedic Quartermaster = CetQuartermaster Scout = CetScout Tourist = DEFAULT } SuitSettings { DEFAULT_SUIT { suit_EvaGround_NoAtmo = 2 helmet_EvaGround_NoAtmo = 2 visor_EvaGround_NoAtmo = 2 jetpack_EvaGround_NoAtmo = 1 } } } No need for all the individual suit settings, since they inherit from default. The only caveat is that this file has to get loaded after the default one, so it has to either go into a folder named ZCetera in GameData, or the TextureReplacerReplaced folder itself. EDIT: Okay, confirmed. The above cfg file works to get what you want. If you make a new save file (or go into the suits menu and hit "Reset All To Defaults" on an already existing save) then you will get deep space suits in place of the non-atmospheric ground suits. You just have to move the file out of the Cetera folder and into the TextureReplacerReplaced folder (or any folder after that). As soon as TRR gets patched to ignore folder names when deciding what order to look at the cfgs, you should be able to move the cfg back into the Cetera folder, but until then moving the file seems a better solution that forcing things in with ModuleManager. I should have done this way earlier, since I always use your suits anyway and I was starting to miss them. Oh, and the reason your original cfg file didn't work was a mismatched bracket.

Not exactly. If you are talking about the first line of your config, that does have to be TextureReplacerReplaced. TRR only looks for TextureReplacerReplaced objects in cfg files, not CeteraSuits objects, so it needs to be named right for TRR to find it. What I was talking about was the order of overwritting. Whoever wrote your cfg file cleverly used ModuleManager to make sure your settings go in last, but they really shouldn't have to have, since TRR is supposed to load Cetera.cfg afterthe default one. This is easiest to see if you are making a file that overwrites the default suit. I tested this by making a file that sets suit_EvaGround_NoAtmo to two for the default suit, thinking that all of your suits would inherit that behavior and you wouldn't have to specify it for every single one. Again, it only worked if it was in a folder after TextureReplacerReplaced alphabetically. The same file functioned in a folder named ZZZCetera, but not in one named Cetera.

So, I was looking at Cetera's cfg file, and I noticed that it was structured like this: I started wondering why half was done through ModuleManager, since TRR is supposed to pull all the cfg files in alphabetical order, and the default file has an @ so it should come first and get overwritten. Shouldn't it be possible to just write it like this? I rewrote Cetera's file like that and did a little experimenting. I quickly discovered that TRR actually DOES use alphabetical order, but it includes the folder names in the ordering. A file named "GameData/Cetera/test.cfg" gets overwritten by TRR's default cfg, but the same file named "GameData/ZZZAfterTextureReplacerReplaced/test.cfg" does not get replaced. The only other way to make Cetera's suit setting work right seems to be ModuleManager, since "Cetera" comes before "TextureReplacerReplaced" alphabetically. You might want to try and find away around that, so modders don't have to make all their mod names start with Z or use ModuleManager. Or if not, maybe include a mention in the readme that ModuleManager is required if you do not put your file in the TextureReplacerReplaced folder.

Hey, no problem. You take all the time you need. I'm just glad that thanks to you I can tell my Kerbals apart again. Anything else is just gravy.

That makes it a lot better, but they're still a little twitchy. Every two seconds or so they reset to their default expression for a single frame in the middle of all the grinning. A bit of testing on my part showed that it actually happens during default expressions too if you zoom in and look carefully at their lips. There's a lot less facial movement so it's harder to see, but it is still going at hyperspeed with a neutral face too.

So, I've run into a small issue that I'm hoping you recognize and have an easy fix to, because I've got nothing. With TRR installed, Kerbal face animations play at hyperspeed when on EVA. I tested on a new save file with only TRR and ModuleManager installed to make sure it wasn't anything else causing it, but it still happened. I can have all the other mods installed and it's fine, but as soon as TRR gets added in too, the EVA animations happen so fast that it looks like several Kerbal heads overlayed on each other at partial transparency. Is this something you have seen before? Is there some config tweak or something I can do to stop this? I seem to dimly recall someone else complaining about a similar issue with the old TR, but this is the first I've seen of it.

Just a heads up about an interesting quirk of TRR that you might be interested in, but I found an repeatable error for an unusual folder setup which causes it to select textures for the wrong gender. I had my Kerbal head textures named in the pattern of "modauthor_description" and ended up with a folder named "scart_blonde" in both the male and female head subdirectories. This caused TRR to give male Kerbals the female head texture of the same name by mistake. Fixing it was as easy as appending a "_f" or "_m" to the end of each folder, but I just thought you might want to know that there was an unusual condition in which the mod gets a bit confused and forgets which folder is which. Otherwise it runs beautifully and has twice the functionality of the original TR. Keep up the great work.

You can find the Juno's cfg file in GameData\Squad\Parts\Engine\miniJet\SmallJetEngine.cfg. First module down is ModuleEnginesFX, which is what you want. In particular, you want maxThrust, which you can turn down to reduce or remove the thrust. I would set it to something really low instead of actually zero, just to be safe. 0.01 or something like that. Next, the smoke. At the bottom of the file you can find the engine's visual effect. You are looking for PREFAB_PARTICLE under the effect named running_thrust. The two entries named "speed" describe the speed at which the smoke should be emitted. speed = 0.0 0.25 speed = 1.0 1.0 Turn them down and play around with their values until it looks right in the game. You want to edit the second values. The first values describe the percentage of throttle, so the speed can change as you throttle up. You might want to clone the Juno part (either manually by duplicating the cfg file or through module manager) so the original is kept intact. Don't forget to post pics of your doughnut when you finish.

Thanks so much for the speedy reply! That really helps. Now I can start converting over all the old textures. ...so you can. Well, I feel stupid. Thanks again.

Quick question: what is the order of fallback if TRR cannot find a texture? For example, if there is no veteran jetpack texture provided, will it try to use the standard jetpack texture instead? If I am not making both male and female versions of a EVA spacesuit, should I call it "Suit_EvaSpace_Standard_Male0" or "Suit_EvaSpace_Standard_Female0" so that it will default correctly? Same question if I am making one texture for both ground and space EVAs. Basically I just want to know which are the default choices if not all are provided. The docs were clear on how ranked textures fell back to the next lowest number when they weren't found, but it didn't mention how it behaved when other things are missing.

Well, that was all I needed to get me to upgrade from TR to TRR. Thanks, KLGraham.

Thank you so much. My Kerbals can once again wear fancy color-coded suits and have fun hair colors. Huzzah.