diomedea

What about reading the post you're commenting about?

I want to ask SQUAD to consider increasing the number of joystick buttons recognized in game, possibly up to the range 0..39. Moreover, I suggest the input settings GUI to be slightly modified: as of KSP ver 0.22, each single button used for joystick assignments is long only enough to show the text "joystickbutton" and barely a single digit afterwards. With a different font, or a slight increase in horizontal size, it would be possible to read two digits as needed. I believe any advanced joystick would benefit of the above requested changes. Anyway, my joystick is a Saitek X-52 Pro. KSP is the only program to have issues with it: it is able to bind axes fine, but not the main hat (POV0) and not any button with a ID number beyond 19 (X-52 has the ability to use up to 40 buttons, as each of its 8-way hat switches can also be reprogrammed as 4 single buttons). X-52 ships with a programming software that allows to assign buttons to keys, and with many other programs I just need to create a proper profile to match keys (as defined in the program settings) and buttons. However, KSP shows the very peculiar capability, when running, to intercept those buttons: no other program can get any input from the stick, including the joystick programming software itself. I even tried to directly write in the settings.cfg file an assignment for a button beyond #19, but KSP does not like that and resets most joystick bindings.

The KSP Wiki is right, though still not very clear. For more: http://en.wikipedia.org/wiki/Orbital_node For hard-core academic correctness: http://astrowww.phys.uvic.ca/~tatum/celmechs.html, e.g. @ Chapter 10, Page 2: "The two points where the plane (of the ecliptic) and the plane of the planet’s orbit intersect are called the nodes, and the point marked ☊is the ascending node."

@ razark: what you wrote may be revealing where the problem is. It is with KSP itself. It is a game and shows only what is relevant to the game. But to consider how planets and vessels move in space, I use astronomical concepts. KSP has them embedded, but does not show what is not relevant. When you have a ship on the launchpad (or landed), it actually moves with the ground of the planet. That point on the ground actually revolves due to the rotation of the planet, so it describes a circle at its latitude. That circle is parallel to the equatorial plane; in case of a point on the equator, it is on the equatorial plane, so I can say that the landed ship has an orbit on the equatorial plane itself. However, KSP does not show any orbit for a landed ship, so you can't see the nodes I am talking about (those would appear if you could ask KSP for a plane change for that ship, but KSP doesn't let that for landed ships). KSP is no astronomical software per se, so it does not provide references to let show purely astronomical concepts. For me it is easy to visualize the equatorial plane by seeing the equator, and can figure where it intersects any other orbit. I studied astronomy on books, and had to learn to calculate the relationships of angles, time, distances. I can determine my exact position on Earth using only the stars. To teach the whole of what I am writing about, it would take a course. However, there are some good computer programs that may help visualize something, in case you are interested in the subject. My preferred one is Celestia http://216.231.48.101/celestia/index.html. If you still have doubts, or would like to continue on this subject, I am happy to try and explain what I know.

@ razark: two different planes always have a line in common, and the nodes are the opposite directions along that common line. In orbital mechanics, the two planes are the ones containing orbits or a reference frame. In this case, one plane is tied to kerbin's equator (equatorial plane) the other the orbit of the station. Thence, yes, we have ascending and descending nodes; they have nothing to do with the rocket, the launchpad or else. Yes, the nodes (either of them) are the points to match for a launch. I did not even consider previously that we don't need to wait for the station to actually occupy one of the nodes or be in any specific position along its orbit. Though, most efficient rendez-vous launches are conducted when the "station" already in orbit is just on the node, if the rocket is powerful enough to get to orbital altitude in a fraction of one orbit. If not, best insertion would also consider how fast the rocket will gain on the station while ascending (so, the station has to have crossed the node already by the same time that will be gained by going on a lower orbit). I definitely use Kerbal Alarm Clock (KAC) for most time-related functions in KSP, and definitely to wait for a node passing. Even if I could calculate the time myself. As I wrote before, time calculations on Kerbin are really simple due to the rotation period of 6 hrs. It takes as many minutes to rotate as the number of degrees of the rotation (longitude difference). Given that an orbit in space is fixed (does not rotate with the body) and therefore the direction of the nodes is fixed, I only have to consider Kerbin's rotation to calculate where a node will be found with any orbit.

You find that the orbital path of your station will cross the KSC latitude (almost 0°) twice per orbit (ascending and descending node). Size of the orbit determines the period, and you compare the period with the rotation time of kerbin (6 hrs). The time difference is easily translated in longitude difference (with 6 hrs rotation time, 1° longitude = 1 min). That means you will find the crossings (nodes) coming at different longitudes. You have to wait for a launch window, when (generally every number N of orbits) either of the two nodes longitude will return to match with KSC longitude. For a perfect orbital insertion, the longitude of the node should be a bit east of KSC: while your rocket rises to the orbital altitude, it still is initially tied to Kerbin's rotation and therefore it will move a bit to the east in relation to the orbital path (perfect calculation would require timing your ascent and taking in account altitude and Kerbin's radius). Launch at 63° azimuth on the ascending node, 117° azimuth on the descending node. However, as your rocket moves in latitude (northern than KSC in the first case, southern in the second) it will also continue to move to the east with the same initial speed of KSC, and that speed is greater than the speed of the ground at higher latitudes. This means you see the rocket drifting east (due to Coriolis effect) in relation to Kerbin's frame of reference, but that does not effect the orbital frame of reference. Heading has to be adjusted as it changes along the orbital path (as a sine wave, from 63° at 0° latitude, to 90° at 27° latitude north, then 117° at 0° latitude descending, then 90° at 27° south).

Based on that new video, it's getting even better than I had hoped. One minor issue, probably will disappear when more mods use this plugin: the toolbar area seems to be "locked" to the same rect even when changing "scene"; if I have the toolbar set in a specific position and dimension in flight or map, I will find the same position and dimension while getting back to the space center, and with each single building (most times, empty toolbar). I could even see an empty "toolbar" with the initial splashscreen when restarting KSP. If I try to adjust an empty toolbar it will shrink to a small square, but then the correct setting for flight may have benn lost. IMHO, each "scene" should have a specific setting for the toolbar to be shown.

KSP Interstellar parts do work for me (have Interstellar ver. 8.2), just out of the box with this mod (no tagging required): they appear within the tab "WarpPlugin" as that is the folder where those parts are installed, and with the "all" section. Here it shows: https://www.dropbox.com/s/k5jzqk7m3bpkxo9/VAB-PartCatalog-Interstellar.png The issue in your case could be KSP had a glitch and didn't load Interstellar? Maybe other mods interference?

Il tuo inglese non è male. Peò per sicurezza mi sono andato a guardare cosa si intenda per "folder" nel gergo dei software di gestione forum, in particolare con vBulletin. Per folder pare si riferiscano solo a sezioni della directory di installazione del software (non diversamente dal generico uso in informatica). Forse il termine più corretto è "subsection" oppure "subforum". Quindi andrebbe chiesto "... to have a subsection/subforum dedicated to italian users within the International section ..." (l'ho fatta lunga per massima chiarezza). Presumo che l'amministratore preveda l'opportunitàche venga designato almeno un moderatore, e certo dovràessere qualcuno di noi. Se lo chiede, dovrebbe indicare i criteri da soddisfare e quindi vediamo chi ritiene di essere in grado (è un bell'impegno) e se la sente. L'aspetto che mi appare abbia bisogno di un chiarimento è firmarsi "The Italian community". Un post è sempre scritto da una sola persona, e non vedo modo per farlo sembrare una proposta collettiva. Dato che non credo esista un censimento di noi italiani, nè tantomeno un modo di sottoscrivere un post (tipo petizione), la soluzione più vicina potrebbe essere quella di una votazione (poll): peccato che un poll possa essere svolto solo aprendo un nuovo thread (non che sia impossibile aprire thread nuovi nella sezione internazionale, solo che non apparrebbe in alcun modo legato a questo). Pertanto, io aprirei il post come segue: "... in name of the Italian community on this forum, I would ask to have ..." magari anche indicando che altri utenti della comunitàhanno espresso consenso all'idea.

@ BeastofChicken: Absolutely lovely. I actually find that animation quite hilarious and rather... kerbalish. Dunno, if changing the scoop to a non-entity, gonna lose on the effect: I would retain that unless it has serious drawbacks. I would certainly like to learn one thing or two from you. What about writing some tutorial (with good examples and step-by-step guide) on aminating parts?

@ blizzy78: tried your plugin (installed with SteamGauges new release) and must say it is not very easy for me. I can see the toolbar resizing rect by holding LMB and dragging, but the active area to start with resizing is pretty narrow, I most often can't click on it. Would be nice to have that active area highlighted. Could not find any way to drag the toolbar. Can you provide instructions?

Well, yes, you're right: doesn't really make sense. I was thinking along the lines of ModuleManager and seeing the DL link for that is readily available to users (even if most mods have it included in their package).

@ Trueborn: I love your mod. Then, I would love it even more if it was possible to have what follows (not urgent, I don't want to distract you from your priorities): - a shortcut key for setting the HUD on/off; - a configuration option for when the HUD has to appear. My preference is for the HUD to appear for vehicles close to the surface of the body, but not for vehicles in deep space (unless I really need it). Now I have to manually switch the HUD on/off (shortcut key would be great). I would like if your mod was able to automatically make the HUD appear based on altitude: if greater than a proper amount (like say, 20% of the radius of the principal body) it does not make the HUD appear unless switched on by the user, if less than the above set altitude, HUD appears (but can always be switched off/on).

@ blizzy78. as of now, the download link for the "user" version of your plugin seems to be very well hidden (can't see it anywhere on the first post or else in this thread). Of course I could find it in the development thread, instead. And, again, thank you for this: absolutely needed.

Chiedere non costa niente, e questo è il thread più lungo di tutta la sezione "international". Potrebbero anche acconsentire!

Many thanks for that tweak! Sensible choice, works perfectly.

Ma veramente quel bestione vola? Scherzi a parte, direi di lasciar perdere MechJeb, è calibrato per portare in orbita un razzo, non un SSTO. Il profilo di salita programmato non va assolutamente bene. Ci ho provato con un velivolo giàin quota e velocitàper poter fare l'accelerazione di salita in orbita, e MechJeb lo ha buttato subito fuori rotta.

Heli Soul I. A volte lascia meravigliati come KSP riesca ad emulare le prestazioni di mezzi reali. Almeno in buona parte. Parlando di velivoli VTOL il pensiero corre subito agli Harrier e derivati (AV-8), ed il paragone dal punto di vista delle prestazioni è davvero impressionante. Naturalmente, tutte le prove sono condotte con velivolo in configurazione pulita (nel gergo: senza carichi esterni) e non si dispone di dati circa il carico "utile". Heli Soul I si alza con manetta al 50% del motore verticale, e mantiene bene l'assetto in fase di decollo e volo stazionario, almeno fino a quando i serbatoi sono pieni. Occorre un minimo di attenzione durante la transizione dalla fase di sostentamento a quella di volo traslato, in quanto va temporizzata l'accensione del motore di crociera con lo spegnimento del motore di sostentamento: necessario fare acquisire velocitàperchè la portanza inizi a farsi sentire come pure il controllo aerodinamico sulle superfici di controllo, mentre il motore di sostentamento farebbe assumere un angolo di attacco negativo. Pertanto meglio assumere un assetto in picchiata per far guadagnare rapidamente velocitàdurante la transizione. Al confronto, gli Harrier che dispongono di 4 ugelli rotanti hanno una transizione morbida e più governabile. Nel volo traslato è molto stabile, relativamente pronto a reagire a barra e timone. Si percepisce il peso del propulsore non utilizzato: a bassa quota la velocitàmassima a serbatoio pieno è arrivata a 198 m/s (Mach 0,6) che non è particolarmente elevata (come per gli Harrier). La velocitàdi virata continua in volo orizzontale è pari a 20°/s (ma non ho utilizzato il motore di sostentamento, quindi niente manovre tipo VIFF che sono la specialitàin combattimento degli Harrier: occorrerebbe una manetta separata per poter controllare separatamente i due motori). La quota di tangenza è stata pari a 18000 metri (a Mach 0,71). Occorre dire che raggiunta tale quota, è difficilmente controllabile forse per il basso rapporto portanza/peso. Ridisceso di quota ho provato qualche manovra con il motore di sostentamento, appunto per verificare effetti tipo VIFF. Occorre una certa abilitàper tenere orientato il velivolo a bassa velocità, mentre si cerca di dirigere la spinta nella direzione desiderata: ma l'effetto è ben percepito. Purtroppo, cercare di stabilire nuovamente un volo stazionario richiederebbe che l'aereo rimanga stabile a velocitànulla, col propulsore verticale che bilancia la gravità. Ma in tali condizioni non esiste più controllo aerodinamico, pertanto l'assetto è instabile. L'atterraggio verticale è un'impresa molto difficoltosa, meglio un atterraggio convenzionale su pista.

Wonderful. Absolutely a "must have" mod, in my case, as I can't keep memory of all the AG buttons assigned to lots of different vessels. This mod provides for a much awaited functionality that was promised for ver. 2.0 of Actions on the fly, but never implemented. And I like how the GUI is arranged, too, with the clever arrangement of the functions by type. Yes, the GUI button can be dragged but with some difficulty, seems to be a unity limit; but believe that will be solved with the draggable buttons plugin by blizzy. Truly a GREAT little mod. Thanks.

@ Trigger Au: great improvement of an already excellent mod! One thing however I would ask: at least with the screen resolution I use (1280 x 1024), the window opens at the extreme right of the screen, that is fine by itself, however I also use the achievements mod by blizzy and its tab is exactly covering the settings button on the alternate resources window. No way to activate the settings unless I disable the achievements mod. Believe it would be extremely fast to change position to the settings button, from extreme down right to extreme left right of the window, so to avoid interference with screen margins often used to park inactive GUI objects. And thanks again for such a wonderful mod!

Did you actually start scanning? When you open the map window, you find buttons on the right side for the functions: you have to press the button with "SCN" on it to actually start.

Good job, nice textures. Please note that the new textures appear just fine for hexcans and recyclers, however not for support containers: in this last case the new textures are in .png format instead of .tga, so they don't automatically override the standard ones form TAC LS mod. Nothing to sweat too much, for users who know how to convert .png in .tga; however it may be better to already provide tham as .tga with the upload.

It would. As a magnetorquer (http://en.wikipedia.org/wiki/Magnetorquer) works because of the interaction of its own electromagnetic field with the ambient magnetic field, and due to the conformation of the Earth's magnetic field (http://en.wikipedia.org/wiki/Earth%27s_magnetic_field), it would be more efficient where the latter is most intense, that being close to the magnetic poles and less efficient near the equator. On the contrary, high orbits that bring a vessel far from an environmental magnetic field will render a magnetorquer useless. That is the case with geosynchronous orbits. However, the force provided by this device is quite faint, useful only with objects in space. In your example as a bow stabilizer (e.g. talking of a ship), the forces that are exerted on the bow from the environment are many orders of magnitude greater than what even a very large magnetorquer could generate.

Precision calculation of a trajectory, so to aim at a very specific point, is a well known problem in exterior ballistics (http://en.wikipedia.org/wiki/External_ballistics. A number of numerical models to achieve a good approximate solution do exist, though to achieve the required precision (e.g. as to hit a target with an artillery round at long range) corrective factors need to be found from experimental measures. But I believe you don't really need such extreme precision. Have a look at the model here, maybe you can find what you are looking for: http://www.bfxyz.nl/index.shtml.

Thank you not only for your mod, but for keeping us informed about development plans too. Your Real Life issues get precedence: if we could survive up to now without your mod, I guess we may wait a bit more to see all your nice ideas implemented.