Doxel

Members
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

7 Neutral

About Doxel

  • Rank
    Rocketeer

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" 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.
  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 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.
  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 some help.
  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 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?
  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 { 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.
  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. 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.