Navi1982

It seems the mod introduces a little problems with rescue missions (lost in space at some orbit) when the game generating missions with cabins without hatches. As a real example - module "PTD-6 Star". It is possible to eliminate such parts from missions?

Oh, no!... Flatearthers here too... Omg!... But, resonable question is: Why you playing that game? P.S.: Nowadays Flatearthers become so much like a virus information obscures the mind of people.

Can't find "Basic dV" in CKAN... first post say - it is indexed. But still cant find it.

Nartea, please remove the folder encryption in release versions - I mean to uncheck flag "Encrypt Contents to secure data". Thanks.

DaMichel, this mod is more important than FlightIndicators... I need it! We need it! All player need it! Because many of us don't want to go back to the KER mod... PLEASE, make it without FAR. Please, please, please... But, sincerely speaking, this is the most useful MOD to those who like to play in the stock version with minimal impact of MODs! Hope, next update, for v1.2.x will coming soon. Thanks a lot for your efforts!

I think Cover still have some bugs... For example, when i attach garage between two garage adapters and want to put cover under garage (or adapters) - it is shown as two sections: ending one and middle, but both and (i think it is) reverted on 180 degrees. See image and description.

Very useful mod. Thanks! But, it would be nice to be implemented a good feature like: "to toggle it on/off" by right mouse button click on its icon. Thanks in advice!

Hi! This is a great mod. Much better than stock... But, it is possible to do transparency like in stock mod, to have access to the parts inside and without to disassemble fairings? Or, if possible, at least to see what is inside. Thanks in advance! Good Luck!

Just a link how to check state of CapsLock and other keyboard leds in unity - may be it will be useful... http://answers.unity3d.com/questions/219017/toggling-caps-lock-or-even-just-the-indicator-ligh.html I can imagine the following steps: 1. When flying scene is calling - check state of CapsLock led on keyboard and set Precision Controls to: a) blue status (fine precision control) if it is On, and red status (hard precision control). (blue and red - it's mean color of control indicators in left-bottom side of screen that is shown when 3'rd person view camera mod is active, and I don't know another way to check it's status except to switch camera mode) 2. Do "1." if CheckCapsLedState = true from StockPlusController.cfg file. I mean, Check Led Status and set PrecisionControl if that option (CheckCapsLedState) is set to true in case when PrecisionControlsToggle is set to another key or CapsLock key - no mater. in code (i prefer basic language): <best place of this code would be in OnFlySceneLoad (not sure how it is called but you know what I mean) event> <initialize some variables here before set somthing: read from StockPlusController.cfg option CheckCapsLedState and check CapsLock led state> if CheckCapsLedState = true then if Led = true then ' led is on? <set contol precision in Blue state - fine precision control> else <set contol precision in Red state - hard precision control> endif endif Next code must be implemented after PrecisionControlsToggleKey is pressed: if CheckCapsLedState = true then if PrecisionControlsState = Blue then <set led of CapsLock to be On> else <set led of CapsLock to be Off> endif endif I really have no idea how to implement that... But, in general it might be in such way.... Many people will say to you many thanks for that fix. Good luck!

Good job! Like all what and how you are implementing. Many thanks. And, I hope you will spend some time for another fix - Precision Controls Toggle. As it setted on CapsLock key, the main problem is a LED on keyboard that misleading pleyers about the status of Precision Controls, especially when a rapid intervention in flight control of vessel is required and map orientation is preferable. I propose it to be set in function of CapsLock Led status... What I mean... Since I own programming skills (unfortunately the old school) in assembler, I am sure that the state of the LEDs on the keyboard can be changed without pressing the key. And even more, to be checked. So, I propose that: 1. At the time of switching to the vessel, to check status of LED CapsLock and according its state to set right Precision Controls Toggle, and then transfer control to the player. 2. So if Precision Controls Toggle function can be assigned to any key, then calling this function can set desired state of CapsLock LED. 3. CapsLock LED state changing must be optionally, when Precision Controls Toggle function is called. I suppose it must be done through the configuration file, like the activation of the StockPlus. This kind of fix will be very useful. And I hope this is posible via modern programming techniques. Thanks in advance.

Nice tool, but I cant understand how to remove some parts from vessel... My problem is: First of all I've launched a space station and then I decided to land it on Mun. So I've designed module based on fuelTank2-2 that have two landingLeg1-2, two radialLiquidEngine1-2 and some RCS control features. This module can be docked with dockingPort2. Of course, this modules have probeCoreHex to be manned. So, when I launched two such modules and approached the station - I realized that one of them can not be separated from the carrier rocket. And I've decided to edit quicksave file... I just deleted parts that I dont need... After reload quicksave file - my module, that was welded with carrier, began to rotating and fast go away from the station. And I was surprised - there have been two modules, but one in another. But, savefile contain only one of this. What it can be and how to fix it? What I've tried too: - copy CoM coords from another module - same results. - copy nrm, rot - same results. I using KSP v0.90 beta. Please Help Me... Some interesting things... After reload edited quicksave, then save it again and reopen it in editor - I have observed, that this two modules is parts of same VESSEL How can I put my vessel close to my station aprox in 500m from it?

As already mentioned here, the concept of the algorithm to convert image files is not really suitable for all mods. The good side of this tool is the two ideas of the controlled conversion and user friendly interface process. However, maintaining the basic idea, you must implement it in the right direction with better flexibility. And I think that, in the right direction would be as follows: Show dialog box to select the folder in which you want to convert images. (realized) Given that the DDS textures can only be square and have a side of a power of two - provide conversion options, taking into account parameters such as: Exclude images width less than or equal to Min_Width (control with 2 arrows Up/Down that will rise/low power of two or set manually (any size for some future reasons)) Exclude images height less than or equal to Min_Height (same control) Reduce images width to the size of Max_Width (same control, but check if above the Min_Width, else set equal to Min_Width). Reduce images height to the size of Max_Heigth (same control, but check if above the Min_Height, else set equal to Min_Height). Three Radio buttons (dots) for option above: "Ignore local exception files, use settings from this file"; "Use local exception files but use settings from this file"; "Use local exception files and use settings from those files". And CheckBox labeled "When exception file found then ask me to apply or ignore it using dialog box." All those options described above must be writen in the file "DDS4KSP_Global.txt", in global section (see what is mean below). Parser must check each folder for files with exceptions (created by author of the corresponding MOD's). The file name with exceptions must be strictly regulated in the description of this utility. For example, "DDS4KSP_Exceptions.txt". "DDS4KSP_Exceptions.txt", as the "DDS4KSP_Global.txt", may contain the following structure: Section for global settings (see #2) for converting images from the current folder and its subfolders. Section for exceptions, which will specify files excluded from the list of conversion or for which will be valid only the specified conversion options if they are indicated as string parameters. [*]If local "DDS4KSP_Exceptions.txt" not found then settings will be used from "DDS4KSP_Exceptions.txt" of upper folder or from "DDS4KSP_Global.txt". Same for options from #2.e.

Great work! Especially I like stockalike concept of design. May be somethings need to be improved (textures), but anyway - it is best MOD that I'd seen, which implement stockalike parts from real life. How about USA, ESA and others stockalike parts in the future?

Nice. But is too much details in the shapes and very low detail of textures... and speaking about design, it's not compatible with stock parts. So, it would be best to review design. But, in generally it is a great work. Keep working on! ...and about textures in IVA - russian painter (strange, dont so?) had very bad day, when wrote inscription as like "XYN"?

I like this idea. Hope will be implemented in final release of KSP. But, I want to give some advice to developers of this mod... It is necessary to approach the design from a technical point of view. Thus, the Ribbons must be redrawn (or converted) to a resolution of 128x32 pixels. Should be stored in files with a resolution (maximum) 2048x2048 pixels (like textures size). And when displayed on the screen, you need to pull out of the image 128x32 (by accessing it with x,y coords and width,height parameters). You can leave the original size of the ribbons, but centered in the area with a resolution of 128x32. The advantage is to minimize read/write operations between memories (HDD/RAM/VRAM) and may reduce the errors and crashes. Because, Ribbons will be stored consecutively in memory. The desadvantage is used more memory. Some technical info for image 2048x2048 pixels stored in videomemory: - will take max 16MB (if compresion algorithms is not used); - will have capacity to store 16x64=1024 ribbons; Possible, to store some groups of ribbons appart in smaller files 512x512 pixels: - max. 1MB in memory; - capacity to store 64 ribbons; - but will increase read/write opperations between RAM and VRAM. In general case - using small files is bad idea, cause some part of it's headers is stored in memory too and increasing RAM usage. Hope devs solve this soon.

Looking good. Especially balloons. But I would like to give advice on their colors scheme: Oxigen - Light blue or skyblue (like oxidizer currently); CO2 - is ok; Water - is ok; Waste water - may be toxic green; Liquid fuel - must be more red (like Firetrucks); Oxidizer - must be dark blue but not very dark; Monopropellen - is good, but for matching design is good to be more darken. Green color is for Food. European standard for pipelines have this colors: Gases, Fire Fightings, Other liquids, Airs, Waters, Combustible liquids, Acids and Alkalis, Steams. Recommend sticking to this standard, but given the color-coded subsections. As a result, the marking shall consist of a primary color and complementary color stripe. That is, the style of the cylinders can be left as he is, but to the color from top and bottom need to add a strip at a distance of the width of the strip itself or half. In accordance with European color codes and its subdivision color-codes, we get something like this: Oxygen -strip, CO2 - strip, Water - strip, Waste water - strip, Liquid fuel - strip, Oxidizer - strip, Monoprpellen - strip, Food - strip. Russian standard for pipelines have this colors: Waters, Steams, Airs, Combustible and non-combustible Gases, Acids, Alkalis, Combustible and non-combustible liquids, Other substances (like pudres, gels, pulps) Also I sugest to see this wikipedia: http://en.wikipedia.org/wiki/Bottled_gas but russian version have colors schemes... Another Italian standard http://www.siad.com/russia/docs/colore_bombole_gas_industriali_uk.pdf

After reading the views of all participants in this forum thread, I came up with the generalized idea of ​​motivation to build space stations. And since the game is being developed in the direction of research and science, space stations should find its niche in the game. However, the station can be built with different goals, but they can be combined. The most common type of space station and quite realized - it is Refueling Space Station, which also does not leave himself without attention. As you know, from time to time it is also necessary to refuel. Scientific Space Station, may be useful during investigations. As already suggested here, such a station should be built from a variety of modules, but not all at once! I propose the following scenario for Scientific Space Stations: All of us have probably already noticed that scientific developments are grouped (by columns, if you watch the tree). What if, to limit the study of these categories as long as there is no certain area of science research opens the level of these developments? That is, before you start to develop any of the branches in this category (column), you will need to build and launch into space (zero gravity required) a special module and "unlock" inside it appropriate category. The game would look like this: developments in this column (of branches) will be displayed as gray icon (that exist only in theory) as long as there is no unlocked category by Kerbonauts in the right module (been confirmed or denied the facts and theoretical speculation). Further, each of these modules will enhance percentages of the study, as it is now implemented with Mobile Processing Lab. Thus, motivating players to build these modules for efficiently telemetry of scientific data. [*]Another type of stations - it Production Space Station, thus will be built "Engeneering Module". In the distant future, it may be produced spaceships, but given the current game mechanics, at the moment I see no point in implementing this. However, even now can be introduced "Engineering points" that will accumulate over time (perhaps even in the warp) in order to improve the performance of parts. Maybe at first it will be implemented in the likeness of "research points", but in the near future I do not see any obstacles to implement a system of "Engineering points" as described below. According to the scenario, in these modules in ultra-sterile and zero-gravity conditions, kerbonauts will produce parts for production equipment that improve the quality of parts made on Kerbine. Then, "Engineering points" accumulated in the module will be carried on Kerbin, in that same module or in a special "cargo" module. However, then the last module must be present at the station as a storage during production. And on Kerbine, in the research center will be a tab a la "Engeneering Enhacements", where in such a same tree, like scientific, will be improved the details by some sort of exponent. [*]Still, it is possible to build a "Tourist Space Stations". But, have to wait implementation of the economic model in the game. The station will serve to supplement the budget. In this case it is necessary to carry passengers kerbyan, wait until they run tourist season, and then take him home. Tourist will not pay more than the provisions under the contract. I think it should be clarified some of the details of all that I wrote. P.S.: And... Sorry for my english. By origin I speak Russian. And used electronic translator. Hope you will understand me.