Kerbal101

Все верно, вылет из-за нехватки адресного пространства. Дело в том, что в 32битном режиме разные ОС выделяют онного разное количество, и если для ОС Windows процессу достается всегда максимум 2.5Gb, то в GNU/Linux обычно поставляется ядро PAE с полными 4Gb. Насколько мне известно, рекомендуется использовать версию ОС и KSP 64бит по разным косвенным причинам (GC, фрагментация видеопамяти итд).

@RarogCmex Приветствую! Для перевода не нужно регистрироваться на Zoho, следует выслать разработчику merge request, что вы абсолютно верно сделали. Если есть время и желание поучаствовать в поддержании базы, напишите мне пожалуйста ЛС. Спасибо и с уважением!

Здравствуйте! Предоставьте пожалуйста логи. Вы можете найти их: - Mac: ~/Library/Logs/Unity/ - Linux: ~/.config/unity3d/Squad/Kerbal Space Program/Player.log - Windows (32бит): C:\Users\имя_пользователя\Appdata\KSP_win\KSP_Data\output_log.txt - Windows (64бит): C:\Users\имя_пользователя\Appdata\KSP_win64\KSP_x64_Data\output_log.txt этот файл можно сжать в архив и загрузить на любой обменник, или как текст на сервер pastebin.com

@Semyon Spirin Извините за столь запоздалый ответ, но без логов помочь будет трудно.

@Semyon Spirin Здравствуйте! Какая у Вас точная версия MacOSX и точная версия КСП (бильд), - и прошу уточнить не грузится ли сама игра или проблема имеется только в КСПпедии? Была проблема с запуском КСП для High Sierra, но начиная с 1.4.х игра должна работать без проблем. Для более ранних версий КСП, нужно добавить параметр "-force-opengl" к бинарнику игры если это стим инсталляция, для ГОГ участник @salajander предоставил [ скриптом ] на который нужно сделать ссылку. Некоторые участники говорят, что помогло отключение от сети. [ По этой ссылке ] , в разделе "Вам требуется Техническая Помощь // "я хочу сообщить о проблеме с игрой или модом" , указаны все шаги как сообщить о проблеме. Без логов и деталей помочь будет трудно... Спасибо!

Hi! As an alternative to docking ports, I recommend "weldable" Docking ports from the Konstruction mod by @RoverDude. They look like normal Docking ports, but these have a special option "Compress" that explodes the two connected ports ("compression") and permanently connects the parts. It is also part of (larger) MKS package. The last version is 0.5.0 and supports 1.4.x

@Vaisman @-MadMan- Могу только подвердить ситуацию, что мы никого намеренно не блокируем. Модераторский состав проинформирован на счет ситуации, использование VPN для решения технических трудностей с нашей стороны не возбраняется. @Kirill Otavva Думаю, что карта лучше всего подходит в тему Обучения. По поводу оформления, в [ Правила и ЧаВо ] есть раздел "Как вставить картинку в ваше сообщение" и список хостеров изображений. Если у вас останутся вопросы - просто распишите их.

@Dr. Jet Спасибо! Добавлю ссылку под шапку, если не возражаете.

@rspeed Hey Rspeed! Can I ask you to open a dedicated topic for your overhaul, so that descriptions and [ license stuff ] is proper? I would gladly add your project to [ porkjet legacy topic ], if you don't mind. Thanks!

@steve_v When you speak of "console controllers", these things are usually different, because they talk MS-only "XInput". This "Xinput" is not related to neither "libinput", nor "xorg", its a relatively new protocol that was introduced by MS to replace classic joystick API. The classic joystick API in MS world is called "DirectInput" and in Linux world - classic joystick API [ link ]. Both APIs talk through USB, however they return different values. Typically in Linux, if a classic joystick (Joystick that talks classic protocol) is attached to software that listens for newer "Xinput", then software will not be able to detect it. And if "Xinput" joystick is attached to software that listens to classic API, then software will incorrectly map keys. Some joysticks allow to switch between the API, like can be seen [ here ] but also joysticks with classic API-only and "Xinput" API-only are sold and produced today, adding to the confusion. This is a big headache today. In my humble opinion there is no advantage from "Xinput", its just a different language. I guess its just another " ' 'thanks' ', Microsoft " thing. Unfortunately I am not a software developer, but in Windows there is software piece that allows to emulate (emit) classic joystick events to Xinput events, that is then detected by software. It looks like Unity is using Xinput now and abadoned DirectInput, and this is a big problem for Linux until similar emulation layer is implemented ... or there is an option to add classic interface + switch in the settings. The workaround I see at start of the page, that uses Fly-By-Wire mod basically uses a mod that can listen to classic API, you are effectively bypassing the "Xinput". More information: [1], [2]

Sorry, but I had to snip your links and would like to ask you to please remove the file from github and any other sharing site where you stored it. I perfectly understand that you are trying to help, but redistributing assets from "Squad" inside "Gamedata" is a no-go, because its copyrighted and a EULA violation. We could achieve the very same effect plus sustainability over updates using the awesome ModuleManager, the syntax guide can be found [ here ]. Thank you for your understanding.

This is a known issue in stock unmodded game, please follow [ this link ]. I am locking the thread to prevent duplicate posts and confusion.

@Jungfaha Hmm, breakingForce and breakingTorgue lead me to this: However, if you have ModuleManager installed and you create a text file with ".cfg" extension and any name inside "Gamedata", that has the following: @PART[landingLeg1] { @crashTolerance = 12 @MODULE[ModuleWheelSuspension] { @springRatio = 6 @damperRatio = 1.0 } } @PART[landingLeg1-2] { @crashTolerance = 12 @breakingForce = 80 @breakingTorque = 80 @MODULE[ModuleWheelSuspension] { @springRatio = 6 @damperRatio = 1.0 } } @PART[miniLandingLeg] { @crashTolerance = 10 @MODULE[ModuleWheelSuspension] { @springRatio = 8 @damperRatio = 1.0 } } Does it fix the issue? These values are from 1.3.1 and include few vars that were relevant, when I made LY-01 as strong as LY-05. The most important factor at that time seemed to be "crashTolerance", with LY-05 having a whopping 325. That value should solve the problem, although it still needs bugreport. It could also be that the problem arises from reported "jumping" in 1.3.1 and 1.4.2 (probably unrelated), there is this mod that could help combat it. I would ask test the cases differently, if I may, just to help find the cause more precisely.

Updated the thread to 1.4.x status. I have marked the versions that I have no compatibility data as such - and as always, any constructive correction or criticism are welcome.

@DECQ Привет в дискуссии! Ты никогда не помешаешь, присоединяйся. Каюсь что сам по болезни дошел до середины рассказа, сегодня исправлюсь! Кстати, мой первый запуск из кабины в безвозвратном режиме закончился прощанием с Биллом , к чему только не ведет жадность до науки.

Господа, по поводу политики, обсуждение теорий итд, я хотел бы уточнить, что пока тема развивается к конструктивном, уважительном и интеллигентом (с подтверждениями фактами, без эмоций) ключе(1), и не отходит от целей этой темы (2) - не вижу никаких проблем. Пункт присутствует именно из-за "огнеопасности", так как очень часто люди на глобальном форуме используют их чтобы потроллить или пофлэймить.. Но некоторых аспектов это не касается, это когда были совершенны реальные преступления против человечества, это лучше не диспутировать.

@Sokol_323 Имеется известная проблема, при которой при подгрузки корабля, он появляется ниже поверхности, что вызывает прыжок вверх. Загрузка и выгрузка происходят на дистанции 2км, что приблизительно соответствует приведенному вами на картинках. Эта проблема Unity-специфична и то появляется, то исчезает, [ есть мод ] который отключает влияние гравитации на несколько секунд и позволяет судну медленно опустится на землю. Эта проблема не связана с физикой и узлами (nodes), которая исправлена. Извините, я немного приболел, поэтому несмог ответить сразу.

@Sokol_323 К сожалению не могу этого подтвердить, никаких изменений с аэродинамикой и физикой в 1.4 не произошло.

@Duerkos Unfortunately, I am not apt in C#. I guess @pizzaoverhead could help here, but I think the mod needs recompile for 1.4.x and while its really one of a kind and great mod, there are some issues in it.

Поехали! Перевод занял однако немного больше времени, чем я предполагал, но было увлекательно!

@Sokol_323 С удовольствием подскажу как это делаю я - MJ не использовал никогда и не планирую. Но управление без САС - это уже отдельный уровень мастерства. Сложность управлять кораблем без САС состоит из двух факторов: центра массы(1) и центра подъема(2). Первый фактор есть всегда - если центр массы впереди и отцентрирован относительно центра тяги, то траектория будет стабильной. Если построить несимметрично, то тяга двигателя начнет постоянно кренить или вращать корабль. То есть, строить симметричные корабли и нагружать фронт - себя всегда оправдывает. Второй фактор идет в довеску, если корабль путешествует в атмосфере. Для самолетов - центр подъема (Center of Lift, CoL) должен быть внутри центра массы (Center of Mass, CoM) и немного позади (чем далее позади, тем стабильнее), причем допусимо если немного выше. Также для ракет центр подъема должен быть существенно сзади (добавить подъемных поверхностей, особенно управляемых). Наконец, играет роль обтекаемость (сопротивление) переда корабля. Вообщем казалось бы всё это - классика самолето и ракето-строения, однако без САС эти вещи имеют очень прямой выраженный эффект.18 Если корабль построен с учетом вышеперечисленного, можно переходить к практическим советам (если не построен, его будет беспорядочно крутить). При полетах в атмосфере без САС, таким как взлет ракет со Спутником (Stayputnik) или ракет с кербалами не-пилотами с Кербина: - архиважно, чтобы у ракет был хороший симметричный баланс "дротика": -> 1. вес в голову, 2. аэродинамичная голова, 3. больше подъемных поверхностей в хвост - у ракет должна быть достаточная тяговооруженность (TWR) - 1.35+. Её можно прочитать в моде KER. - необходимо чтобы присутствовали двигатели с управляемым вектором тяги. - это сложно и сразу не получиться. Даже если вы научились делать гравитационный поворот на орбиту - даже если без САС. - для начала лучше не трогать управление вообще и дать ракете набрать вертикальной скорости выше 80 м/c. - атмосфера ниже 10 км достаточно плотная и будет атаковать/трепать любую несимметричную и не-дротиковую конструкцию или конструкцию с "плоской" головой (если нет обтекателя, эффект бега со "столом" перед собой) - но если конструкция удачная, то можно управлять, если применить "магический трюк" : переключатель нежного управления (precision controls), по умолчанию он активируется по [ Caps Lock ] и управлять небольшими точечными толчками. дело в том, что если ракета набрала вертикальную скорость и аэродинамически верна - то воздушные массы при таком подходе будут играть роль САС и стабилизировать курс. но чтобы понять пределы возможноги и допустимого, потребуется разбить не один десяток ракет. - атмосфера выше 20км - это еще веселее: она достаточно разряженная, поэтому стабилизирующей эффект будет менее выражен и с управлением нужно быть еще нежней, а лучше вообще не трогать. Также если есть "управляемые поверхности" (рули) - они тоже потеряют свой эффект, управление идет только через отклонение сопел двигателя. При полетах в атмосфере без САС на самолетах, самолет должен быть очень аэродинамически стабильным, например стоковый [ Aegis 3 ]. Но всеравно гораздо чаще потребуется корректировать курс, так-что лучше лететь с пилотом. При полетах вне атмосферы без САС, в т.ч. на планетах или выхода корабля на орбиту, имеют вес следующие моменты: - очень неплохо иметь дополнительные гиродины (и батарею, и солнечную панель). Двигателем управлять очень неудобно и накладно. - то же самое "нежное управление", хотя с ним нужно быть аккуратным - и вот почему: - атмосфера тут не стабилизирует, поэтому любой толчок нужно аккуратно гасить толчком в другую сторону. - если гиродинов и RCS нет, то это еще сложнее - придется включать двигатели на малую тягу в момент руления. - можно воспользоваться багом/читом - и ускорить время, это отключит физику вне атмосферы и стабилизирует корабль, хотя это дело скользкое. Как-то так. Всё - из собственного опыта.

Провалами выложена дорога к успеху. О! Это целая история! Для вставки альбомов от imgur на форуме (в софтине) есть плагин, и этот плагин имеет историю отваливаться и прикручиваться. В данный момент, плагин переживает фазу отваливания и криво вставляет не только текст, и ссылку. А так, в [ ЧаВо ], в параграфе "Как вставить картинку в ваше сообщение" я пошагово указал процесс вставки. Я даже когда-то [ писал ] как организовать таким образом альбомы на английском, пожалуй я это тоже включу в ЧаВо.

Очевидно, что одним из центральных компонентов «Making History» являются сами миссии! Здесь вы можете прочитать некоторую информацию как строить миссии, и как работает система, под называнием MissionSystem, - изнутри. Что же такое "Миссия" ? В общих чертах, миссия это серия Узлов и Соединений (Коннекторов), в которых игрок начинает со стартового места и может следовать по пути от узла к узлу до тех пор, пока они не подойдут к концу. С точки зрения программирования - это конечный автомат (Finite-state Machine или FSM). Но в системе миссий мы делаем и кое-что отличающееся от традиционного FSM: мы не храним состояние каждого перехода в постоянстве. На Узлах имеется логика, которая позволяет Узлу иметь свойство "Захват Всего" (Сatch All), что означает, что миссия может перейти на Узел с таким свойством - с любого другого Узла. В свою очередь, это означает, что мы можем хранить больше информации в файле миссии, не требуя сохранения каждого перехода по отдельности, и - также, имеем возможность распаковывать его для использования как FSM в игре. Таким образом, на языке FSM "Узлы" это - "состояние", а "Коннекторы" - это "переходы". В игре есть механизм разбора, который отслеживает каждую миссию и обрабатывает циклы обновления, которые используются для прогресса каждой миссии. И Активный Узел - это текущее активное состояние. Описанное выше составляет суть того, как миссия обрабатывается после сборки, а ниже мы разберем детали. Что такое MissionSystem? MissionSystem - это движок синтаксического разбора, это основной класс, который управляет миссиями, и технически это то, что называется модулем сценария (Scenario Module) в КСП. Он загружает компоненты миссии из файла сохранения, обрабатывает их и начинает следить за состоянием миссии: когда должны меняться Узлы и когда запускать действия. Другие модули сценариев (Scenario Module) в КСП включают ContractSystem, FundingSystem, CommNetScenario, надеюсь, что вы видите схожий момент и здесь - всё это элементы, которые запускаются как компонент игры и используются для загрузки и сохранения постоянных данных, - и потом обрабатывают эти данные в игре. Путешествие между узлами Давайте придерживаться терминологии Конечных Автоматов (FSM) по мере разбора. В любой момент в нашей миссии всегда есть только один Активный Узел (ActiveNode) (это как "состояние" в FSM), - что немного похоже на главного персонажа Горца (Highlander) из одноименного фильма, тем что всегда «может быть только один». Так вот, MissionSystem затем должна проверить, не пора ли перейти к новому узлу. Для этого система миссии последовательно проверяет Узлы, к которым подключен Активный Узел, - это включает в себя Узлы, которые напрямую связаны, и любые Узлы со свойством "Захват всего" ("Catch All"). Как же система миссии определяет, когда пришло время менять Узлы? Каждый Узел может иметь несколько подключенных к нему модулей, и они помогают понять, когда должен произойти переход, а также что делать после изменения Активного Узла: Проверки смены Узла обрабатываются TestModule следующим образом: TestModule - это класс, который определяет логику, которая проходит проверку и возвращает Истину (True) в случае успеха. Каждый Узел может иметь одну или несколько тестовых групп (TestGroups), и каждая тестовая группа (TestGroup) содержит TestModules. После того, как все TestModules в любой тестовой группе (TestGroup) вернут Истину, этот Узел активируется и Активный Узел (Active Node) миссии меняется. Если у узла нет тестовых групп / модулей (TestGroups/Modules), это сразу вернет Истину Действия, которые происходят при активации Узла, обрабатываются ActionModule: Каждый Узел может иметь один или несколько присоединенных ActionModule. Они активируются в момент активации Узла - но это не исключает применения Вами программных блоков, чтобы немедленно их активировать и выполнять длительные действия. Теперь, когда мы разобрали взаимодействие Узлов и Коннекторов, рассмотрим какую роль играет Активный Узел (Active Node). MissionSystem просматривает Активный Узел при каждом цикле обновления и проверяет все Узлы, на которые он может перейти. Это подразумевает любой Узел, у которого есть Соединение с Активным Узлом и все Узлы со свойством "Схватить всё" (Catch All). Прочее Но как насчет других вещей, которые видны в Строителе ? Что такое Прикрепленный Узел? Как можно увидеть Узел со свойством "Захват всего"? Как говорится, картина стоит тысячи слов - вот некоторые моменты, которые я нашел полезными и интересными: Начальный Узел Имя уже всё говорит, но тем не менее - это Активный Узел с которого начинается миссия. MissionSystem всегда начинает здесь, а затем проверяет Прикрепленные Узлы. Узлы создающие корабли можно состыковать с Начальным Узлом (только эти типы узлов и ни один другой). Первый Узел создающий корабль, прикрепленный к Начальному Узлу - создает стартовый корабль для миссии. Прикрепленные Узлы Представляют собой особый вид соединения, в котором прикрепленный Узел будет проверяться один раз, в момент когда родительский узел (тот, к которому этот Узел прикреплен) активирован. Это отличный механизм чтобы реализовать различные изменения, вроде коррекции выдаваемых очков в момент активации Узла или менять маршрут миссии в определенный момент времени. Разрешите привести пример: Допустим Узел "Go to", показанный как 1, подключен к Активному Узлу,- тогда, когда "My Other Vessel" достигнет этого места: Узел "Go to" станет Активным Узлом. Затем система проверяет, является ли MET (время с момента запуска миссии) менее 2 часов, если этот Узел становится Активным,- и никакие другие Прикрепленные Узлы не тестируются. Если нет, то идет проверка MET < 3h30m, если это Истина, тогда этот Узел становится единственно Активным. Если условие на любом Прикрепленном Узле становится Истинным, тогда подключенные к ним Узлы немедленно начнут корректировать счет. После чего игроку необходимо поднятся выше 5000м над уровнем моря, чтобы продолжить далее. Узлы "Захват всего" Эти Узлы не имеют прямого подключения на входе. Они будут протестированы независимо от того, какой узел является Активным Узлом. Из нашего примера на изображении видно, что таким Узлом является "Vessel Destroyed" (Корабль Уничтожен) - что означает, что если в любой момент в миссии корабль, за которым ведется учет, будет уничтожен, то этот Узел активируется. Порядок Проверки Соединений Как узнать, в каком порядке MissionSystem проверяет какой Узел следующий? Для Прикрепленных Узлов это должно быть понятно - это порядок в котором они состыкованы, но когда есть несколько Соединений, порядок может быть найден (и скорректирован) в Узле "Параметры" на панели действий "Настройки» (SAP - вверху справа в Конструкторе). Мы объединим этот принцип со следующими... Некоторые дополнительные свойства Узлов Активировать только один раз - этот параметр включен по-умолчанию, чтобы предотвратить бесконечные циклы, но при тщательных расчетах вы можете отключить его, чтобы использовать некоторые рудиментарные циклы в миссиях. Всегда Истинные Узлы (B) - эти Узлы могут использоваться для логических структур, чтобы заставить вещи двигаться вместе. Всегда Ложные Узлы - вы можете использовать их, чтобы ввести своих игроков в заблуждение - да, так и есть - удивить их. Чтобы помочь понять рисунок выше, я нанес цветовой код на Коннекторы. Предположим, вы хотите направить игрока на EVA с одного судна, а затем войти в Mk1Pod в ближайшем судне. Но вы хотите добавить немного давления, взрывая солнечные батареи судна, пока они не добираются туда (не спрашивайте меня почему, может быть, вы такой Kerbal ). Вот как это решение работает: Ваш игрок попадает в Узел A, как только кербал выйдет в EVA Миссия немедленно перемещается в Узел B (потому что он всегда Истинен), и мы также выстроили всё так, что он может активироваться несколько раз и повторять события. В точке B - Узлы проверяются в соответствии с там настроенным порядком, через "Порядок Соединения Узлов" (Node Connections Order) как показано ниже: Вот так проверяются присутствие экипажа в указанной детали, потом тестируется прошло ли 120 секунд и так далее.. Предположим, что прошло 31 секунда - миссия переходит к Узлу C (через синюю линию), а затем взрывает одну из солнечных панелей судна Затем снова активируется Узел B и снова начинаются проверки Поэтому каждые тридцать секунд мы взрываем панель судна до тех пор, пока а) кербалы не достигнут и доберутся до модуля Mk1, или б) они долго провозятся и мы найдем что-то еще "противнее". Итог Я знаю, что эта статья немного длинная, но, надеюсь, что я дал вам некоторое представление и информацию о некоторых разработках и возможностях в "Making History" ! Увидимся в следующий раз! -- -- -- -- [ источник ] Автор статьи @TriggerAu Все права зарезервированы Статья переведена @Kerbal101 и размещена с разрешения и с использованием материалов @TriggerAu По прошествии месяца, эта статья будет перемещена в раздел [ Обучение и обмен опытом ].

@cratercracker Ну тогда, - на двоих!

Hello @Gaarst !! Its really nice, that you and your team found the time to migrate to (online) spreadsheet, which provides many improvements in both editing and categorizing of the mods compared to posting in the forum (which was never designed for such task). That said, I want to annonce that I and my team have been doing localized version of the mod list for quite some time independently and unaware of your effort, however our project has some differences: - we link and adverize your project as "global" (because, de facto it is), while referring to our table as local, - we are using Zoho instead of GDocs, with main reason Zoho allowing more registration ways and more classic spreadsheet interface, - our table format is purposely flat (non-hypertext) in url section, which allows the whole table to be copy-pasted into different solution, bypassing the export limitations of projects and devices, - we are focusing on local forum community: the DB is in Russian, with notes that are supplied by our users, which looks like best effort as that supporting multi-language table would consume at least two extra columns for each language and add the communication overhead to global mod db (yours). - we do not try to include everything, instead relying on what our members use, however to date we manually added the information without using data from any other similar table. - we are integrating mod localization tracking into the db, which allows to check and register translation status in-place. - we are doing atomic changes, backing up the table periodically. That said, I want to express that members of the global community are always welcome to use our db for any kind of information, including updating the global table and I would like to ask if we could do the same. The [ link to our DB ] , to link to [ our subforum thread ]. Best regards, K101