Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

7 Neutral

About Doxel

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thank you, mysterious stranger. You have made my day.
  2. 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.
  3. 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.
  4. 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" unt
  5. 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 list
  6. 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?
  7. 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.
  8. 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.
  9. 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 so
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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 {
  15. 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.
  • Create New...