diomedea

Did a test with the modified part.cfg as you suggested, still on that install with FAR and those two vessels in game. Possibly there is a change, because while switching from one to the other vessel and back through the map window ingame, the state is conserved. It sure was lost in my main game doing the same. However, if I go to the space center and then back to the vessels, both lose some of the actionstates. I am now using only stock parts, and have observed that all antennae lose their states (using communotron 16, DTS-M1 on both, and communotron 88-88 on one vessel). Other parts are not affected, be those solar panels, scientific parts, ladders, reaction wheels.

Sorry about that link: here the correct one. I am indeed using MM 2.1.5, maybe that is part of the issue as well (noticed you keep packing MM 1.5.6 with AGX, but certainly can't use that with other mods). I'll try those instructions soon. Yes, I had some knowledge RT2 is numbering PartModules. Can't remember now about what other mod it was discussed, but the issue was really similar.

So happy to see you are back (again), and keep making progress with Jebnix. Wish all is good IRL for you . If the disclaimer with the github repo is still current, Jebnix is not yet ready for independent testing. Would you point what steps still are required to make the first beta version (that I would like to run) ? Not asking timings or schedules, unless you want to tell.

Probably something unusual, yes. Apart from using my so-heavily modded game install (so any kind of conflicts may emerge due to other mods), I had an asteroid orbiting Kerbin under control in the flight window while I opened the MCC and tried to retrieve orbital data for a probe I wanted to send to Moho (had the solution with a direct transfer, the intention was to use the orbital data for the inital orbit while computing the departure burn). Probably we should not be able to "fly" asteroids. In case the above is not clear, that asteroid was a captured one (was detached after being redirected); normal asteroids aren't "flyable". Tried the MCC feature with a normal ship, even not the one I want to retrieve data about, and all data is retrieved as it should. So, probably just a warning "don't fly asteroids" would be enough . Anyway, while trying to isolate this issue, I found something else. This time with an almost clean KSP install, so quite difficult mods have any influence. 1) Again using orbital data in MCC from one ship while flying another in KSP. Orbital data is retrieved fine, but then when I want to upload the maneuver found by KSPTOT back to KSP, it is uploaded with the vessel being flown, not the one the data retrieved was about (of course I notice there is no way to select a specific vessel while uploading a maneuver to KSP, so probably this is just another thing to warn the users about, and nothing more). 2) A word from you about how to set-up the upload maneuver correctly may be a blessing. The "Upload Maneuver to KSP" window has the option to select the Time Type (UT or Time past Periapsis). It defaults to UT. I found the uploaded maneuvers being wildly wrong in KSP if that option is "UT", but closer if "Time past Periapsis" (afterwards, noticed the DV Maneuver Information panel in the Departure Burn window actually uses "Time past Periapsis"). Still, the uploaded maneuver in KSP is not exactly right (KSP does not show a rendezvous), so I may be missing something else.

I may have found something. This time I tested AGX on an almost clean KSP 0.23.5 install to start with. Launched two different vessels with as many different toggle commands tied to stock parts as I could. On a clean install the actionstates are preserved. Looking at the log window, noticed warning messages about AGX not saving things at launch (probably a temporary thing). But something in those messages made me have a look at the config you use with parts so to preserve data. Noticed the instruction "@PART [*]:Final", went looking for other mods that issue similar instructions with my main install. A few do (mainly for their own parts), one struck my attention because more generally applied to any suitable part: FAR. Installed FAR on the same test environment, relaunched the same game, and now actionstates get lost! (FAR seems to apply some parameters to parts by default, though the exact cause may be different. But the effect is, FAR and AGX seem not compatible currently). Of course the question comes: AGX really needs to place its module as "Final" ? Anyway, here are all files relevant to that test for you to see, I hope you will identify what goes on. The real cause may well be different from what I'm guessing. If those questions above still are of interest: issue is found with both stock and mod parts; I do wait for animations to finish (actually, most parts with this issue have no animation).

Would recommend to contact DYJ about those rules. Your case seems similar to others we had on the forum. Indeed prohibited by the rules. Any chance a trimmed version of those libraries could be published instead?

That is real good news (in particular after all this time, it seemed like this mod could be lost) .

Yes, that is the same impression I get, like sourcecode was provided only for version 0.1. And downloading that, the impression seems confirmed. Nasenspray, the rules (Community rule 5.2, and Plugin posting rules) are that sourcecode has to be provided for all plugins you upload to this forum and other Squad sites. This is a security measure to protect users, it can't be allowed to let unsourced plugins in the wild. If you keep 3 different versions linked, sourcecode must be found for them all. Removing links until this is corrected.

Absolutely. Contracts in 0.24 are devised to work independently of mods. Sure, is possible to consider some mods (e.g. Real Solar System ?) could not be so easily played with the contracts as defined in the stock game, so also contracts will have to be modded in that universe. But to keep with this thread subject, FAR will be playable without too much impact.

I may have detected a minor issue. KSPTOT MCC RealTime System should let the user choose any vessel, from the selection dropdown where all vessels in KSP are listed (and, BTW, really everything orbiting in game is listed, including debris and asteroids). But, after a vessel is selected and data is fetched (from KSPTOT Connect), it shows that data is actually about the loaded vessel that KSP is flying. So, the selection dropdown in the MCC has no effect.

My tests till now were done switching two crafts via the map (though, the issue shows also going through the space center); also the issue shows switching by using the targetron mod (but I guess that gives control of crafts just the same way as right-clicking them on the map). So, have to say switching via the map is not working as expected. Never tried yet with two vessels within physics range. In case it may help, please suggest some specific situations to be tested. Also, have to correct myself about the parts presenting the issue. I had solar panels keeping the state consistent across vessel switching (while other parts had the AGX state reversed), but solar panels also have a similar arrangement of commands (set, reset, toggle) than those other parts. So, it may be the state is kept consistent if - by design or luck - both vessels had the same situation for those parts. Can't say what, if those parts have to be on exactly the same AG with both vessels, have to be in the same state (with both vessels set or both reset), the two conditions together, or else. Flight window: yes, the issue happens when switching from a vessel with lots of AGs shown (long window) to a vessel with less AGs (smaller window).

I am considering if a warning light may be associated to some of the gauges, to be lighted when what is read goes above or below a set value. E.g. electric charge too low, or drain too high. Would require some more coding, but would make the set even more complete (if you like ).

I continue to have issues when switching vessels, even with the latest version. No error logged. But perhaps I am beginning to find a pattern about the toggles actionstate. If I alternate two different vessels, each with similar AGs defined, those AGs that are set as toggles (with parts that allow also set and reset commands beyond the toggle) are scrambled in the switch; also, some AGs that are peculiar of only one vessel, are blanked (lose their action definitions, though keeping the names) when switching over. AGs with parts that only have the toggle command seem to always work fine, however. So, I kept re-syncing all those toggle AGs with the correct state of the relevant part after switching, only to find - again - the AGs reversed with the other vessel when switching back. In the end, left those toggle AGs as they were appearing with one vessel (reversed from the switch); and when switching back to the first vessel, those AGs were in the correct state! Hope the above is clear enough and could be of help. Like if the state of the AGs is not aware there are different vessels (each one with a different situation). If that is because AGX gets confused with parts that have multiple commands, the solution may require to read the state from the vessel definition ingame (as the state with all parts is actually persistent, and is restored when switching to the vessel). Other issue: the Flight window still "flies" (does not stick to the bottom and keeps its position based on the top of the rect) when switching vessels. In case it helps, I use KSP in a borderless window of 1920 x 1080. I move the Flight window as far down as possible while flying a vessel, but there is no sign it gets stickied.

Maybe the one below is not that simple, but absolutely makes for complete coverage, no maintenance, and zero downtime. Fact is, it is obtained by using 24 GNSS satellites as comms relays, each one equipped with just one Communotron 32 Omni. As everybody knows, Global Navigation Satellite Systems provide for continuous coverage with at least 4 satellites in every spot of the globe (and generally there are about 8-10 always above the horizon); so I can assure the comms capability is highly redundant. The picture shows my network around Kerbin, apart from some KSO satellites with dishes, there are those 24 satellites placed in 4 orbital planes in circular orbits at 1588 Km altitude, 55° inclination. What is surprising, is that RT2 is able to manage all those connections without too much effort (compliments to the developers ).

Download URLs. True, after the closure of Spaceport, there are now more different sites than ever that modders can choose to upload stuff. Unfortunately this "freedom" came with disintegration of a repository, in the interest of users would be better if one or two good repositories are used instead of so many. Won't link mods (will take too long), but beyond Curse/curseforge and Github, very used are Mediafire, Google drive, Dropbox, plus some emerging dedicated sites (Kerbalstuff, Majiir's own domain, Spessport, to name some). I'm sure it won't be pretty (even if possible) to include separate controls for each different repository with the mod info window. It may be a better choice to allow, instead of the Spaceport controls, any URL to any site, possibly complemented with an access command in case it is required to initiate download. And yet, unfortunately, most of those non-dedicated repositories don't allow for a single URL with a mod: each link to them is tied to a specific version instead, something that will make impossible any automatic version check.

It may require further testing, but till now it seems the Toggle State is lost across stages and vessels switching. Or, it is not persistent. Doing some effort to put the State correctly (reflecting the part actual situation), so to show green when active, red otherwise. After a staging command, or a vessel switch, all states with AGX show red (so, have to re-sync them with the relevant parts).

Flight window. Nice the attach-to-bottom, nice the actionstate color, nice the groups . A thought: are really two buttons needed for each actiongroup on that window? (One titled with the description assigned, another with the keybinding, but both performing the same). I would leave one button for actiongroup, default showing description. If ever the keybinding is to be shown, it may appear as a tooltip (after a brief moment of hovering the cursor on that button), or a keypress (e.g. Alt, or Cmd) may be detected while the cursor is within the Flight window, and then the keybindings shown instead of the description. Having just one button would give more space for the text to be displayed, so the size issue for that window may be solved.

Sto cercando di farmi un'idea in proposito. Sicuramente il gioco è rallentato, ma non eccessivamente. Come memoria, stimo KSP stia occupando circa 100 MB in più (certo non pochi, ma nemmeno troppi). Non sono in realtài singoli satelliti a preoccupare (molto più semplici della maggior parte dei veicoli che costruisco, e destinati a rimanere "unloaded, on rails" quasi sempre), ma la rete di comunicazioni che hanno stabilito, che non dipende da Figaro ma da RemoteTech2. Oltre ai 24 GNSS, orbitano intorno a Kerbin altri 8 veicoli in grado di stabilire comunicazioni tra di loro con le antenne omnidirezionali. Quindi sono in tutto 32 i veicoli che RT2 deve controllare, ogni pochi cicli di gioco, e per ciascuno va verificata ogni altra possibile connessione (che in totale sono pari a 31+30+29..+1 = 496). E per ogni connessione verificata attiva, viene rappresentata una linea beige (come si nota nell'ultima immagine). Quindi, un plauso a RT2 per riuscire a gestire simili mostruosità.

Realizzata (in 19 ore del gioco) la mia rete di satelliti GPS basata sul Mod Figaro (24 satelliti messi in orbita con 4 lanci).

I am considering if those axis inversions with DPAI are really needed. If only DPAI had axes inverted out of all the tools that show docking helpers, that would make things more confusing. In my case, getting set with up and down just requires to try the RCS - something I like to consider akin to test the RCS system works, before using it for real. Taniwha is also right, we actually move the ship (the cross-hair), not the target (moving markers). But if anybody really has issues figuring directions with IK and JL command pairs, I guess those commands may be easily switched in the game settings.

Concur. Jeb sneaked his own electric stove aboard .

That is one issue I have marked since months but never got anywhere near isolating. Glad you already know about it and what that is about. Would really love if that could be dealt with, therefore to ask SCANsat developers/maintainers if they may have a look. But before that, is there something more to know about that issue? Could you point out where, from the 46 different *.cs files in MCE sourcecode, the methods for control of text wrapping are?

First, let me thank you for even considering that suggestion . I tend to have the map screen quite clogged in the vicinity of Kerbin, while doing a career game. So, if I have to reach for any craft by clicking on it on the map screen, that action is far less easy than it should be, due to all the other crafts close by. But, the target selection menu accessible from the map view (to assign an antenna) is absolutely fine. I would imagine however to have another menu available (possibly with Mission Control, as those Github comments suggest) where all available antennae from all communication sats in orbit around a body can be controlled together. Multiple antennae may be assigned to specific groups, and then may be activated and assigned targets with a single group command. Like on a spreadsheet, with rows for available antennae (or groups) and columns for possible targets, and the user may select a specific target for each antenna (or group), all in a single place. Have to say, the above is not actually an original idea from me. It is how complex comms network assets are managed in real life (the "spreadsheet" is implemented in a real device, in my local reality it is called the "matrix"). About Active Vessel. I am not fond of it, and almost never use it (or, could say I never use it unless for testing purposes). My personal reason is I don't feel it enough realistic, while its logic also makes nasty troubles (I'm sure you don't need hints about those, you sure know very well). Actually, ActiveVessel works, and well, if what I need is just a temporary two-way link to any deep-space probe I sent. I would never allow a manned (kerbaled) mission to be out of good continuous comms however. And when a ship or probe is close to a body or any maneuver node, I want to have comms links firmly established (realism indeed, as my feel is Mission Control would want to in reality). Anyway, I am definitely not among those who wanted to see ActiveVessel removed (reference to the previous RT2 thread). It works for some users. But, my realism need also requires something else. If at all possible, I would like to see some automatic search and linking algorithm implemented, for any antenna that loses its primary (defined) link, as a way to re-establish comms whenever needed. My feel is it would be far more realistic than the current system (with or without ActiveVessel). But, this proposal got a lot of dissent when discussed in the previous RT2 thread, so it will have to be examined again here. And, in the end, that is something that requires some serious work to implement: I am happy if you keep RemoteTech working and possibly implement new things a bit at a time, rather than risk to block everything with a very ambitious rework .

Consensus! I would like to show I agree on the above. But, for me it just works in reverse. I am absolutely fine with WASD(QE) and (HN)JL, but IK (up and down translation controls) seem reversed and always (each time I start a docking) have to try them a couple times blank to get used at them. Sure, DPAI may show reverted indications about the up/down axis, and that would help me set my bearings correctly. But other tools use the same as DPAI currently (tried with Docking Navball and the Docking Camera from Lazor systems, all tools seem to match) so it shows it is my handling that needs some upgrade, not the tools. After all, real pilots undergo extensive training before they are allowed in a real cockpit.

Certainly you deserve to receive some feedback on this excellent addon. I tend to always find lots of things to do in KSP, so just lately got a window of opportunity to launch my GNSS constellation. Going to try with 6 satellites on each of 4 orbital planes (don't want to copy exactly the GPS arrangement). Here is the first of my satellite carriers in orbit, ready to let the GNSS satellites detach at apoapsis, one at a time in 6 orbits, and then land: Hope to be able soon to show the whole constellation.