Sebra

Rotating not the whole craft but just engines would allow you to keep it levelled. But this is not easier unless you are Creative Cyber Commander, able to use whole keyboard plus mouse and joystick simultaneously. Would you describe us which controls would you use? Quite better would be to use additional RCS thrusters to control horizontal speed. Do not get me wrong. I'm not against gimbals. Just explain how you think to control it.

You can always rotate whole vessel.

I think US and Russian keyboards differs only by button labels so I can see "й" on the same button with "q". This means you have almost perfect test model. Picture can help you as additional reference. I found exactly the same. 0400 difference in unicode. There is also problem, described above in my last edited post: Russian letters can be typed and stores using internal editor. Then I can run file and see Russian letters from this file. But as soon as game saved and loaded back, only question marks "?" are on the places of Russian letters.

This works good. print terminal:input:getchar(). works bad. Exactly! For example "абвгд" typed gives me "01234". ( ascii less by 112 , unicode less by 0400 ). It seems unicode need more than 8 bits In-game. I do not even know if some terminals use unicode. Yes. 2 hours ago, Alchemist said: Terminal now displays correctly if the script prints something in Russian Yes. But after save/load game letters become question marks "?". (not on archive).

Sorry for late response. Did not play too often now. I tested kOS on 1.3 and unable to use russian letters. No matter chosen font. Is it a problem with seven bite byte somewhere or should I somehow teach KSP/kOS to know Russian? How?

1.KSP aerodynamics is weird anyway. I think it would work in KSP in any shape. High speed lift is the job for wings. 2.Have you seen the film about "navi" coloured people? 3.Have some "simple" idea.

I'm not great at aerodynamic, but... 1.Fast forward motion would mask rear fan. Rising it up would not help, full height would. 2.Wide holder would mask side fan. Border holder would not mask. 3.Side fans would be great with ability to turn, based on controls.

Additionally to my previous vote (for 3 and 4). Concepts 1 and 2 looks like they cannot be walked through. Concept 3 looks like douse is too short. Concept 4 looks like it need self decoupler. Also I think absence of own fuel is better for the balance reasons.

Agree with Starwaster fully almost for the same reasons.

ROFL Still need 1.22 with mods. Would install 1.3 tomorrow and try it. PS. How was "Kerbetrotter" word built? What meaning should it have?

How can I help? (Russian)

Your opinion is not bad, but wrong (in my opinion). I answered with arguments, you just ignored. ROFL was not about you, but about some movie, attempting to be as much scientific as possible.

We want our game to be fun and interesting! For this we want all Kerbals to be useful. And you can customize your game as you want.

ROFL, thanks!

So you just ignore not pleasant for you questions.

Why your engineer did not do it on orbit? Do you think scientist would provide proper power, control and integrity for attachment? Do you understand how much fiction that movie is?

Can you describe your idea for us? I hope it is better than mine.

I may just have to write my own RPM background handler finally. That is what I want to repeat.

Of course windows was as an example only. Not yet. But would have.

Thanks! Can I get test version? For testing purposes. So kOS would read fonts from windows based on configured list. Am I right? It seems you do not want to discuss it.

I found my mistake later, just did not edit post. I also found doubtful realisation of cursor, which shift letters to be placed. Can you find better implementation? May be by properly applied image. Oh my explanation skill. I mean several pages per kOS CPU so pilot can open wanted page on wanted monitor and kOS prepare them all. As an example of implementation I suggest string variable (or list of strings) to be shown as a page content. I still did not get the need of flag panel at all. I see labels are perfect to be used as flags and I do not need many. And what is IPC? For inter-process communication we have messaging system. I see your attempts to separate monitors but different flags and labels are meaningless IMHO with the same text content. To minimize copypaste you can minimize color names to the configured list. I do not know your possibilities. Can you add something like "[x100y200][-x110y250]" to draw line from (100,200) to (110,250) by current color on the layer under the text? Can you add something like "[p:stopsign]" to show "stopsign.dds in some position? Can you add something like "[c:camera1]" to show picture from mentioned camera?

I would. But now it is still dark to me For now bugs found are: 1.Arrow keys still move IVA view if kPM intercept keyboard. 2.ID not changed when switched to another CPU. 3.Russian characters are broken. The same is on Terminal, so doubt you can fix it. KOS probably ignores high bit and use 128 of 256 codes. My idea was to give single kOS processor ability to show different info on different RPM monitors. Do you think single kOS CPU should provide single screen only? Also I do not like STBY button do not close kOS screen as it is supposed to do for all screens. So here is my suggestion: 1.STBY button is always close kOS screen exactly as any other screen. 2.Upper right button "kOS terminal screen". (immediately if no DPAI installed) On this screen there are rows of upper and lower buttons labels, status line like "CPU 1 'navigator' 5.3 EC/min ...". The rest of screen can show terminal content. NEXT/PREV buttons select CPU here. 3.Other six upper buttons switch monitor to show one of six pages, prepared by kOS CPU. Pages can be kOS variables of string or list of strings type. KOS script could be able to know how many monitors show that page. Probably pages should not be able to get keyboard input, but should be controllable by buttons. If you like it I can add more details. Sorry, I'm weak in explaining. If you think single CPU should have single terminal screen, let it be. If this amount is ridiculous, it seems it is done wrong way. I would be more interested in graphics.

"When" is not a loop. It waits for condition in background.

http://ksp-kos.github.io/KOS_DOC/structures/misc/pidloop.html

http://ksp-kos.github.io/KOS_DOC/math/vector.html#function:VANG For example FUNCTION RDV_STEER { PARAMETER vector. LOCK STEERING TO vector. WAIT UNTIL VANG(SHIP:FACING:FOREVECTOR, vector) < 2. }