|
|
26.08.16
|
|
stranger: To Max Еще два субъективных момента. 1. Слитное написание имен любых переменных настолько становится привычкой программера, что переносится на слитное написание имен файлов (это тоже строго обязательно, если файл используется как ресурс). Но вот заголовки, предназначеныые для чтения человеком, вполне можно писать в "человеческом" формате. Код: title = "MFDRestoreAfterLoad"; приводит к тому, что юзверь в менеджере загрузок наряду с читабельными HUDS MFD - Navigationвидит HUDS MFDRestoreAfterLoadПожалейте юзверя, он и так из английских буковок только "Эс как доллар" с трудом запомнил! А ему это ведь еще гуглопереводчику скармливать надо. 2. Readme.md в Mac OS, конечно, без проблем открывается в TextEdit, но стандартный рекомендуемый формат при распространении пакетов все таки .txt, реже .rtf 1. Каждое слово с большой буквы - можно понять и разобрать. Но я согласен, тут есть над чем поработать. 2. Формат md обусловлен 2 факторами: * Это стандартный формат для readme на github.com и bitbucket.org. И чтобы он "подхватился" необходимо "правильное" имя файла. * На сколько я видел, в этом файле используется форматирование Markdown. А для этого формата правильное расширение ".md". Как результат - при просмотре можно получить вполне приятное форматирование: песочница Markdown.
[quote="stranger"]To Max
Еще два субъективных момента.
1. Слитное написание имен любых переменных настолько становится привычкой программера, что переносится на слитное написание имен файлов (это тоже строго обязательно, если файл используется как ресурс). Но вот заголовки, предназначеныые для чтения человеком, вполне можно писать в "человеческом" формате. [code]title = "MFDRestoreAfterLoad";[/code] приводит к тому, что юзверь в менеджере загрузок наряду с читабельными [b]HUDS MFD - Navigation[/b] видит [b]HUDS MFDRestoreAfterLoad[/b] Пожалейте юзверя, он и так из английских буковок только "Эс как доллар" с трудом запомнил! А ему это ведь еще гуглопереводчику скармливать надо.
2. Readme.md в Mac OS, конечно, без проблем открывается в TextEdit, но стандартный рекомендуемый формат при распространении пакетов все таки .txt, реже .rtf[/quote]
1. Каждое слово с большой буквы - можно понять и разобрать. Но я согласен, тут есть над чем поработать.
2. Формат md обусловлен 2 факторами: * Это стандартный формат для readme на github.com и bitbucket.org. И чтобы он "подхватился" необходимо "правильное" имя файла. * На сколько я видел, в этом файле используется форматирование Markdown. А для этого формата правильное расширение ".md". Как результат - при просмотре можно получить вполне приятное форматирование: [url=https://jbt.github.io/markdown-editor/#rVTBTttAEL3vV8wRUONAS0WF1AOUqiABh4YitbexPY5XrHejnXWC/74zthMCaVFVsZdE45md99682V8UA9zgwpjzDmby79GYS1sSNLjIYFaHFQTvOlhatolKWDj0lBjQl+AJY96tQ5kxF7aqbNG61IGjJTk+NZOdYwwcwFfkDibAcj9D1Tqn/SBUkGqCb+jwsYOVTXVoE3hsiPUbd5yokUag5wDuR0xjXO5Ducj6KsQGkw1+kzkbM6yHk+uf/5Z4dNhn9uwVwhOCTBncaq2ThFrU4l34Il6Qoq0mgLnS0RRuYwytL62fb9BjJMAlWoe5owyuODhUdpHmUsxQoIecoNI6Kt9ChD9T+5sQ2+N4ocUlxvI1JW6st03b/LcYb8D1FfQXlrXLxo6cxNzKaJeJMebaFuSZzOfhmLvaMqxCfAD5dcPHEnRGsa/8EkmgLeVPaBqd41lK0eatwp3cBl9ImGJh0U1mtdI+c/aB4Dg7hB9+EaLyHXtmcBdkEWkFCEVYdAO4p7bvhi2FOqXF6XRajJ2LoXEW4nw6ZvI07ya+mDBOpdHUmHuKrFO5tJxC7Nbs1seY7+QImeAw+2jMAZyVJZQvtz3bTjvWtCtxT/bpeNCnsp5MP8RWFifkTHE5esE5FT4FKEmzxukMztuT6QLLU1PU6hC73ovRBPvPun7Qrv2r1WB82LKK3JEwziltImKNxrKyZqmRJxDqVv3bb4WA0umzaCh6wZ4+dyMotdu+erqvhTl5igONDctnkN4rpPN2XtnH7fDRoI9NMnnZ8T78Gw==]песочница Markdown[/url].
|
|
|
|
![](images/spacer.gif) |
26.08.16
|
|
To Max Еще два субъективных момента. 1. Слитное написание имен любых переменных настолько становится привычкой программера, что переносится на слитное написание имен файлов (это тоже строго обязательно, если файл используется как ресурс). Но вот заголовки, предназначеныые для чтения человеком, вполне можно писать в "человеческом" формате. Код: title = "MFDRestoreAfterLoad"; приводит к тому, что юзверь в менеджере загрузок наряду с читабельными HUDS MFD - Navigationвидит HUDS MFDRestoreAfterLoadПожалейте юзверя, он и так из английских буковок только "Эс как доллар" с трудом запомнил! А ему это ведь еще гуглопереводчику скармливать надо. 2. Readme.md в Mac OS, конечно, без проблем открывается в TextEdit, но стандартный рекомендуемый формат при распространении пакетов все таки .txt, реже .rtf
To Max
Еще два субъективных момента.
1. Слитное написание имен любых переменных настолько становится привычкой программера, что переносится на слитное написание имен файлов (это тоже строго обязательно, если файл используется как ресурс). Но вот заголовки, предназначеныые для чтения человеком, вполне можно писать в "человеческом" формате. [code]title = "MFDRestoreAfterLoad";[/code] приводит к тому, что юзверь в менеджере загрузок наряду с читабельными [b]HUDS MFD - Navigation[/b] видит [b]HUDS MFDRestoreAfterLoad[/b] Пожалейте юзверя, он и так из английских буковок только "Эс как доллар" с трудом запомнил! А ему это ведь еще гуглопереводчику скармливать надо.
2. Readme.md в Mac OS, конечно, без проблем открывается в TextEdit, но стандартный рекомендуемый формат при распространении пакетов все таки .txt, реже .rtf
|
|
|
|
![](images/spacer.gif) |
24.08.16
|
|
To Max
Популяция астероидов в системе, похоже, состоит из двух субпопуляций. Те, которые дают воспроизводимый паттерн - как раз очень похоже на засев через псевдорэндом. Астероиды, добавляемые пакетами, возможно, используют другой механизм засева, но я бы не стал заявлять это уверенно. Проблема как раз в этих псевдорэндомных. Я и сам думал - стоит попробовать внести рэндомную составляющую.
А теперь капелька добра и позитива. Пакет PlanetFallMarketSaver по первому впечатлению работает как я хотел, причем он прекрасно ужился с пакетом Commodity Markets, который делит цены на закупочные и продажные и симулирует небольшие колебания цен. Как раз его мне очень не хватало и думаю, в моем Оониверсуме он приживется. Спасибо, камрад!
To Max
Популяция астероидов в системе, похоже, состоит из двух субпопуляций. Те, которые дают воспроизводимый паттерн - как раз очень похоже на засев через псевдорэндом. Астероиды, добавляемые пакетами, возможно, используют другой механизм засева, но я бы не стал заявлять это уверенно. Проблема как раз в этих псевдорэндомных. Я и сам думал - стоит попробовать внести рэндомную составляющую.
А теперь капелька добра и позитива. Пакет PlanetFallMarketSaver по первому впечатлению работает как я хотел, причем он прекрасно ужился с пакетом Commodity Markets, который делит цены на закупочные и продажные и симулирует небольшие колебания цен. Как раз его мне очень не хватало и думаю, в моем Оониверсуме он приживется. Спасибо, камрад!
|
|
|
|
![](images/spacer.gif) |
24.08.16
|
|
stranger: Увы, в AsteroidRemover v0.3 та же проблема. Уничтожение астероидов после входа в новую систему и до сохранения на ГС не запоминается. На этот раз дело точно не в том, что были уничтожены все астероиды: после прибытия в Leesti один астероид уцелел, но после стыковки с ГС и перезагрузки из сэйва засеялись все. Да, и в 0.2 не из-за этого не сработало. stranger: На чистом дистрибутиве опыты не ставил, возможно, и правда какой плагин влияет, но это странно - ИМХО плагины если и подсевают астероиды, то после того, как отработал дистрибутивный популятор. Для полноты картины - я тестирую пакет после его конвертации в формат OXP. То есть он подгружается после пакетов OXZ. Но опять же - как это может повлиять на результат? Возможно, стоит предусмотреть в скрипте небольшую задержку, чтобы популятор гарантированно засеял астероиды до того, как скрипт их изымет? Возможно, как раз запуск большого количества плагинов приводит к задержке работы популятора и он засевает астероиды поверх уничтоженных (да, я понимаю, надо было включить this._DEBUG = true;, тогда бы было больше материала для размышлений). Вечером, наверное, повторю опыт.
Популятор отрабатывает после события startUp при загрузке и перед shipWillExitWitchspace при перелете. Причем на сколько я видел код генерации астероидов - вполне возможна ситуация, что непосредственно генерация произойдет после вызова функций популятора. И задержку добавлять нет необходимости - если бы с этим были проблемы, то они проявили себя при работе в рамках одной системы. Я все еще грешу именно на разный порядок генерации астероидов (при загрузке и при входе в систему). Объясняется это достаточно просто: 1. Популятор отрабатывает не в момент своего вызова, а он как бы "дает задания" на генерацию астероидов в системе. Непосредственный вызов генерации выполняется позже. 2. Астероиды генерируются псевдо-рандомным образом. Т.е. функция рандома выдает одинаковый ряд чисел при каждом входе в систему или загрузке игры (оригинальная элита именно на этом факторе и была построена. Псевдо-рандомом генерировалось все - включая звездную карту, названия и описания систем). 3. Если при старте и при входе в систему функция псевдо-рандома вызывается в разном порядке разными модулями, то вполне возможна ситуация с разной генерацией астероидов. Исходя из этого я могу предположить, что какой-то плагин в событии startUp вызывает псевдо-рандом или при входе в систему что-то лишнее вызывается (правда, тут проблемное событие я не вижу - популятор отрабатывает до shipWillExitWitchspace, а это (на сколько я могу судить) первое из событий в новой системе). Буду еще копать эту ситуацию и попробую найти плагин, который так себя проявил. Вполне вероятно, что достаточно чуть подправить плагин для корректной работы популятора. stranger: P.S. Две помарки (увы, сам этим грешу!)
В AsteroidRemover 0.3 номер версии скрипта остался объявлен как 0.2. Линк на AsteroidRemover 0.3 в личной рубрике выглядит так: MFDRestoreAfterLoad 0.3.oxz. Исправил х 2. P.S. Ориентироваться на LogEvents я бы не стал: 1. Это сторонний плагин, который просто подписывается на все события (и включает в себя дополнительные обработки событий). 2. Сама игра может "оптимизировать" порядок событий. Например, чтобы после загрузке игры не генерировалось куча событий добавления корабля - они могут отрабатывать после выхода со станции. P.P.S. Если все подтвердится, то проблему с детерминированными астероидами можно решить и другим способом (есть "честный" рандом - "Math.random()"): 1. Повлиять на популятор через вызов рандомное число раз псевдо-рандом (правда, прямого способа вызвать псевдо-рандом я не нашел. Косвенный способ - генерация рандомных векторов). 2. Дополнительно заселить систему реально рандомными астероидами. 3. Подвинуть существующие астероиды на рандомную позицию недалеко от текущей. P.P.P.S. Стоит добавить, что против моей теории псевдо-рандома выступает то, что только часть астероидов генерируется на другом месте при перелете.
[quote="stranger"]Увы, в AsteroidRemover v0.3 та же проблема. Уничтожение астероидов после входа в новую систему и до сохранения на ГС не запоминается. На этот раз дело точно не в том, что были уничтожены все астероиды: после прибытия в Leesti один астероид уцелел, но после стыковки с ГС и перезагрузки из сэйва засеялись все.[/quote]Да, и в 0.2 не из-за этого не сработало. [quote="stranger"]На чистом дистрибутиве опыты не ставил, возможно, и правда какой плагин влияет, но это странно - ИМХО плагины если и подсевают астероиды, то после того, как отработал дистрибутивный популятор. Для полноты картины - я тестирую пакет после его конвертации в формат OXP. То есть он подгружается после пакетов OXZ. Но опять же - как это может повлиять на результат? Возможно, стоит предусмотреть в скрипте небольшую задержку, чтобы популятор гарантированно засеял астероиды до того, как скрипт их изымет? Возможно, как раз запуск большого количества плагинов приводит к задержке работы популятора и он засевает астероиды поверх уничтоженных (да, я понимаю, надо было включить this._DEBUG = true;, тогда бы было больше материала для размышлений). Вечером, наверное, повторю опыт. [/quote]Популятор отрабатывает после события startUp при загрузке и перед shipWillExitWitchspace при перелете. Причем на сколько я видел код генерации астероидов - вполне возможна ситуация, что непосредственно генерация произойдет после вызова функций популятора. И задержку добавлять нет необходимости - если бы с этим были проблемы, то они проявили себя при работе в рамках одной системы.
Я все еще грешу именно на разный порядок генерации астероидов (при загрузке и при входе в систему). Объясняется это достаточно просто: 1. Популятор отрабатывает не в момент своего вызова, а он как бы "дает задания" на генерацию астероидов в системе. Непосредственный вызов генерации выполняется позже. 2. Астероиды генерируются псевдо-рандомным образом. Т.е. функция рандома выдает одинаковый ряд чисел при каждом входе в систему или загрузке игры (оригинальная элита именно на этом факторе и была построена. Псевдо-рандомом генерировалось все - включая звездную карту, названия и описания систем). 3. Если при старте и при входе в систему функция псевдо-рандома вызывается в разном порядке разными модулями, то вполне возможна ситуация с разной генерацией астероидов.
Исходя из этого я могу предположить, что какой-то плагин в событии startUp вызывает псевдо-рандом или при входе в систему что-то лишнее вызывается (правда, тут проблемное событие я не вижу - популятор отрабатывает до shipWillExitWitchspace, а это (на сколько я могу судить) первое из событий в новой системе).
Буду еще копать эту ситуацию и попробую найти плагин, который так себя проявил. Вполне вероятно, что достаточно чуть подправить плагин для корректной работы популятора. [quote="stranger"]P.S. Две помарки (увы, сам этим грешу!)
В AsteroidRemover 0.3 номер версии скрипта остался объявлен как 0.2. Линк на AsteroidRemover 0.3 в личной рубрике выглядит так: MFDRestoreAfterLoad 0.3.oxz.[/quote]Исправил х 2.
[b]P.S.[/b] Ориентироваться на LogEvents я бы не стал: 1. Это сторонний плагин, который просто подписывается на все события (и включает в себя дополнительные обработки событий). 2. Сама игра может "оптимизировать" порядок событий. Например, чтобы после загрузке игры не генерировалось куча событий добавления корабля - они могут отрабатывать после выхода со станции.
[b]P.P.S.[/b] Если все подтвердится, то проблему с детерминированными астероидами можно решить и другим способом (есть "честный" рандом - "Math.random()"): 1. Повлиять на популятор через вызов рандомное число раз псевдо-рандом (правда, прямого способа вызвать псевдо-рандом я не нашел. Косвенный способ - генерация рандомных векторов). 2. Дополнительно заселить систему реально рандомными астероидами. 3. Подвинуть существующие астероиды на рандомную позицию недалеко от текущей.
[b]P.P.P.S.[/b] Стоит добавить, что против моей теории псевдо-рандома выступает то, что только часть астероидов генерируется на другом месте при перелете.
|
|
|
|
![](images/spacer.gif) |
24.08.16
|
|
To Max Дело об астероидах становится все чудливей и странноватей. Я наивно ожидал, что в случае, когда скрипт срабатывает, популятор засевает астероиды в системе, и после этого скрипт уничтожает все астероиды с меткой "были уничтожены в прошлых игровых сессиях". Вот, однако, выдержка из лога со включенным дебаггером: Код: 10:29:48.114 [AsteroidRemover]: INIT Asteroids in system: 48 10:29:48.114 [AsteroidRemover]: INIT {"k":"asteroid","p":[-26765.582275390625,1346.17919921875,225827.29272460938]} ... 10:29:48.117 [AsteroidRemover]: INIT {"k":"asteroid-alternative","p":[-9194560.439941406,-754837.4982910156,8001703.845214844]} 10:29:48.118 [AsteroidRemover]: LOAD Asteroids in system: 48 10:29:48.118 [AsteroidRemover]: REMOVE: {"k":"asteroid","p":[-26765.582275390625,1346.17919921875,225827.29272460938]} ... 10:29:48.121 [AsteroidRemover]: REMOVE: {"k":"asteroid-alternative","p":[-9174999.435302734,-777678.3796386719,7994339.953613281]} ... 10:29:49.002 [LogEvents]: Coriolis Station 330 spawned at 0 km 10:29:49.002 [LogEvents]: Asteroid 23001 spawned at 133 km 10:29:49.003 [LogEvents]: Asteroid 23084 spawned at 251 km 10:29:49.003 [LogEvents]: Asteroid 24115 spawned at 260 km
То есть получается, что три уцелевших в системе астероида засеяны после того, как отработал скрипт плагина. Выходит, популятор не засевает систему сразу, а загружает объекты в буфер и скрипт уничтожает их в этом буфере? Или я что-то упустил?
To Max
Дело об астероидах становится все чудливей и странноватей. Я наивно ожидал, что в случае, когда скрипт срабатывает, популятор засевает астероиды в системе, и после этого скрипт уничтожает все астероиды с меткой "были уничтожены в прошлых игровых сессиях". Вот, однако, выдержка из лога со включенным дебаггером: [code] 10:29:48.114 [AsteroidRemover]: INIT Asteroids in system: 48 10:29:48.114 [AsteroidRemover]: INIT {"k":"asteroid","p":[-26765.582275390625,1346.17919921875,225827.29272460938]} ... 10:29:48.117 [AsteroidRemover]: INIT {"k":"asteroid-alternative","p":[-9194560.439941406,-754837.4982910156,8001703.845214844]} 10:29:48.118 [AsteroidRemover]: LOAD Asteroids in system: 48 10:29:48.118 [AsteroidRemover]: REMOVE: {"k":"asteroid","p":[-26765.582275390625,1346.17919921875,225827.29272460938]} ... 10:29:48.121 [AsteroidRemover]: REMOVE: {"k":"asteroid-alternative","p":[-9174999.435302734,-777678.3796386719,7994339.953613281]} ... 10:29:49.002 [LogEvents]: Coriolis Station 330 spawned at 0 km 10:29:49.002 [LogEvents]: Asteroid 23001 spawned at 133 km 10:29:49.003 [LogEvents]: Asteroid 23084 spawned at 251 km 10:29:49.003 [LogEvents]: Asteroid 24115 spawned at 260 km [/code] То есть получается, что три уцелевших в системе астероида засеяны после того, как отработал скрипт плагина. Выходит, популятор не засевает систему сразу, а загружает объекты в буфер и скрипт уничтожает их в этом буфере? Или я что-то упустил?
|
|
|
|
![](images/spacer.gif) |
24.08.16
|
|
To Max
Увы, в AsteroidRemover v0.3 та же проблема. Уничтожение астероидов после входа в новую систему и до сохранения на ГС не запоминается. На этот раз дело точно не в том, что были уничтожены все астероиды: после прибытия в Leesti один астероид уцелел, но после стыковки с ГС и перезагрузки из сэйва засеялись все. На чистом дистрибутиве опыты не ставил, возможно, и правда какой плагин влияет, но это странно - ИМХО плагины если и подсевают астероиды, то после того, как отработал дистрибутивный популятор. Для полноты картины - я тестирую пакет после его конвертации в формат OXP. То есть он подгружается после пакетов OXZ. Но опять же - как это может повлиять на результат? Возможно, стоит предусмотреть в скрипте небольшую задержку, чтобы популятор гарантированно засеял астероиды до того, как скрипт их изымет? Возможно, как раз запуск большого количества плагинов приводит к задержке работы популятора и он засевает астероиды поверх уничтоженных (да, я понимаю, надо было включить this._DEBUG = true;, тогда бы было больше материала для размышлений). Вечером, наверное, повторю опыт.
P.S. Две помарки (увы, сам этим грешу!)
В AsteroidRemover 0.3 номер версии скрипта остался объявлен как 0.2. Линк на AsteroidRemover 0.3 в личной рубрике выглядит так: MFDRestoreAfterLoad 0.3.oxz.
To Max
Увы, в AsteroidRemover v0.3 та же проблема. Уничтожение астероидов после входа в новую систему и до сохранения на ГС не запоминается. На этот раз дело точно не в том, что были уничтожены все астероиды: после прибытия в Leesti один астероид уцелел, но после стыковки с ГС и перезагрузки из сэйва засеялись все. На чистом дистрибутиве опыты не ставил, возможно, и правда какой плагин влияет, но это странно - ИМХО плагины если и подсевают астероиды, то после того, как отработал дистрибутивный популятор. Для полноты картины - я тестирую пакет после его конвертации в формат OXP. То есть он подгружается после пакетов OXZ. Но опять же - как это может повлиять на результат? Возможно, стоит предусмотреть в скрипте небольшую задержку, чтобы популятор гарантированно засеял астероиды до того, как скрипт их изымет? Возможно, как раз запуск большого количества плагинов приводит к задержке работы популятора и он засевает астероиды поверх уничтоженных (да, я понимаю, надо было включить this._DEBUG = true;, тогда бы было больше материала для размышлений). Вечером, наверное, повторю опыт.
P.S. Две помарки (увы, сам этим грешу!)
В AsteroidRemover 0.3 номер версии скрипта остался объявлен как 0.2. Линк на AsteroidRemover 0.3 в личной рубрике выглядит так: MFDRestoreAfterLoad 0.3.oxz.
|
|
|
|
![](images/spacer.gif) |
16.08.16
|
|
To strangerПереработал скрипт на использование временного ID. Перебил астероиды в системе - сохранилось нормально. Но стоит учитывать, что при переходе между системами часть астероидов может генерироваться с другими координатами. Скачать 0.3: В личной рубрике. P.S. почему в 0.2 не отработало - вопрос открытый, если нет астероидов API корректно вернет пустой массив. P.P.S. Возможно, разница в генерации астероидов при старте игры и при выходе из гипера связана с плагинами - когда тестировал версию 0.1 на "чистой" установке астероиды совпадали.
[b]To stranger[/b]
Переработал скрипт на использование временного ID. Перебил астероиды в системе - сохранилось нормально. Но стоит учитывать, что при переходе между системами часть астероидов может генерироваться с другими координатами.
Скачать 0.3: [url=http://roolite.org/coriolis/viewtopic.php?f=11&t=678]В личной рубрике[/url].
P.S. почему в 0.2 не отработало - вопрос открытый, если нет астероидов API корректно вернет пустой массив. P.P.S. Возможно, разница в генерации астероидов при старте игры и при выходе из гипера связана с плагинами - когда тестировал версию 0.1 на "чистой" установке астероиды совпадали.
|
|
|
|
![](images/spacer.gif) |
15.08.16
|
|
To strangerПохоже, проблема в том, что были уничтожены все астероиды. В логе должно было быть зафиксирвоано падение скрипта, поспешил я в лог писать количество астероидов: Код: var t = system.shipsWithPrimaryRole("asteroid"); ... this._logger("SAVE Asteroids in system: " + t.length); if (t) { ....
P.S. К ID я не привязываюсь (привязка к координатам идет, но теперь я знаю, где найти хотя бы временный ID ![Wink ;)](./images/smilies/icon_e_wink.gif) спасибо LogEvents), популятор не ломаю (спавнится все, потом чистится лишнее). P.S.S. Если в аддоне установить "this._DEBUG = true;" то будет подробный лог по отслеживаемым астероидам (Основная роль "asteroid" и AI "dumbAI.plist"). Что появилось, что уничтожено, что подчистилось при загрузке.
[b]To stranger[/b]
Похоже, проблема в том, что были уничтожены все астероиды.
В логе должно было быть зафиксирвоано падение скрипта, поспешил я в лог писать количество астероидов: [code]var t = system.shipsWithPrimaryRole("asteroid"); ... this._logger("SAVE Asteroids in system: " + t.length); if (t) { .... [/code]
[b]P.S.[/b] К ID я не привязываюсь (привязка к координатам идет, но теперь я знаю, где найти хотя бы временный ID ;) спасибо LogEvents), популятор не ломаю (спавнится все, потом чистится лишнее). [b]P.S.S.[/b] Если в аддоне установить "this._DEBUG = true;" то будет подробный лог по отслеживаемым астероидам (Основная роль "asteroid" и AI "dumbAI.plist"). Что появилось, что уничтожено, что подчистилось при загрузке.
|
|
|
|
![](images/spacer.gif) |
14.08.16
|
|
Думаю, есть смысл реанимировать эту тему, чтобы не захламлять тему "Презентации наших OXP", предназначенную именно для... ну да, оповещения о новых разработках. To Max Пакет Asteroid Remover работает пока только частично. Стартуем в системе Diso и входим в Leesti. При входе в систему популятор генерирует 15 астероидов, детерминированный паттерн которых столь неимоверно доставляет. Код: 06:43:51.762 [LogEvents]: Player will exit witchspace 06:43:52.189 [LogEvents]: Player alert condition changed from 2 to 1 06:43:52.199 [LogEvents]: Coriolis Station 330 spawned at 358 km ... 06:43:52.464 [LogEvents]: Asteroid 14600 spawned at 225 km 06:43:52.464 [LogEvents]: Asteroid 24763 spawned at 219 km 06:43:52.464 [LogEvents]: Asteroid 17005 spawned at 210 km 06:43:52.464 [LogEvents]: Asteroid 612 spawned at 210 km 06:43:52.464 [LogEvents]: Asteroid 19905 spawned at 193 km 06:43:52.465 [LogEvents]: Asteroid 13111 spawned at 192 km 06:43:52.465 [LogEvents]: Asteroid 21887 spawned at 189 km 06:43:52.465 [LogEvents]: Asteroid 11207 spawned at 185 km 06:43:52.465 [LogEvents]: Asteroid 9096 spawned at 186 km 06:43:52.465 [LogEvents]: Asteroid 13990 spawned at 182 km 06:43:52.465 [LogEvents]: Asteroid 29680 spawned at 179 km 06:43:52.465 [LogEvents]: Asteroid 18362 spawned at 172 km 06:43:52.465 [LogEvents]: Asteroid 14933 spawned at 169 km 06:43:52.465 [LogEvents]: Asteroid 16313 spawned at 132 km 06:43:52.465 [LogEvents]: Asteroid 32463 spawned at 127 km Убиваем все астероиды, стыкуемся со станцией и сохраняемся на ней. Перезагружаем игру. После загрузки сэйва стартуем со станции и наблюдаем тот же паттерн - все 15 астероидов реинкарнировали, но под другими id. Код: 08:02:43.977 [LogEvents]: Navigation Buoy 12657 spawned at 10 km ... 08:02:43.977 [LogEvents]: Coriolis Station 330 spawned at 0 km 08:02:43.977 [LogEvents]: Asteroid 32373 spawned at 132 km 08:02:43.977 [LogEvents]: Asteroid 23001 spawned at 133 km 08:02:43.977 [LogEvents]: Asteroid 5101 spawned at 145 km 08:02:43.977 [LogEvents]: Asteroid 21494 spawned at 151 km 08:02:43.977 [LogEvents]: Asteroid 23310 spawned at 157 km 08:02:43.977 [LogEvents]: Asteroid 21672 spawned at 172 km 08:02:43.977 [LogEvents]: Asteroid 17102 spawned at 174 km 08:02:43.977 [LogEvents]: Asteroid 2142 spawned at 176 km 08:02:43.978 [LogEvents]: Asteroid 21942 spawned at 179 km 08:02:43.978 [LogEvents]: Asteroid 12538 spawned at 181 km 08:02:43.978 [LogEvents]: Asteroid 28671 spawned at 188 km 08:02:43.978 [LogEvents]: Asteroid 14641 spawned at 195 km 08:02:43.978 [LogEvents]: Asteroid 7211 spawned at 196 km 08:02:43.978 [LogEvents]: Asteroid 23084 spawned at 251 km 08:02:43.978 [LogEvents]: Asteroid 24115 spawned at 260 km Снова чистим астероиды. 13 штук уничтожено, осталось два. Возвращаемся на станцию и снова сохраняемся. Вот теперь после следующей перезагрузки все как положено. После старта со станции остались 2 астероида, причем у них те же id. Код: 08:33:29.004 [LogEvents]: Navigation Buoy 12657 spawned at 10 km ... 08:33:29.004 [LogEvents]: Coriolis Station 330 spawned at 0 km 08:33:29.004 [LogEvents]: Asteroid 23084 spawned at 251 km 08:33:29.005 [LogEvents]: Asteroid 24115 spawned at 260 km Вывод: если после старта геймер переместился в другую систему, корректное запоминание уничтоженных астероидов не происходит. P.S. Мне тут пришла в голову идея, что можно проблему детерминированных паттернов гораздо проще решить. Для меня лично проблема больше именно в воспроизводимом паттерне, а не в самой регенерации - глаз повторяющиеся паттерны цепляет помимо сознания. У меня возникла идея очень простого плагина, который просто сканирует популяцию астероидов и изымает часть популяции рандомно. При этом при каждом запуске отдельные элементы паттерна останутся на своих местах, но они будут давать разные мозаики и унылое ощущение deja vu разрушится. Я на неделю уезжаю, по возвращении, наверное, еще поразмыслю над этой идеей.
Думаю, есть смысл реанимировать эту тему, чтобы не захламлять тему "Презентации наших OXP", предназначенную именно для... ну да, оповещения о новых разработках.
To Max
Пакет Asteroid Remover работает пока только частично.
Стартуем в системе Diso и входим в Leesti. При входе в систему популятор генерирует 15 астероидов, детерминированный паттерн которых столь неимоверно доставляет. [code]06:43:51.762 [LogEvents]: Player will exit witchspace 06:43:52.189 [LogEvents]: Player alert condition changed from 2 to 1 06:43:52.199 [LogEvents]: Coriolis Station 330 spawned at 358 km ... 06:43:52.464 [LogEvents]: Asteroid 14600 spawned at 225 km 06:43:52.464 [LogEvents]: Asteroid 24763 spawned at 219 km 06:43:52.464 [LogEvents]: Asteroid 17005 spawned at 210 km 06:43:52.464 [LogEvents]: Asteroid 612 spawned at 210 km 06:43:52.464 [LogEvents]: Asteroid 19905 spawned at 193 km 06:43:52.465 [LogEvents]: Asteroid 13111 spawned at 192 km 06:43:52.465 [LogEvents]: Asteroid 21887 spawned at 189 km 06:43:52.465 [LogEvents]: Asteroid 11207 spawned at 185 km 06:43:52.465 [LogEvents]: Asteroid 9096 spawned at 186 km 06:43:52.465 [LogEvents]: Asteroid 13990 spawned at 182 km 06:43:52.465 [LogEvents]: Asteroid 29680 spawned at 179 km 06:43:52.465 [LogEvents]: Asteroid 18362 spawned at 172 km 06:43:52.465 [LogEvents]: Asteroid 14933 spawned at 169 km 06:43:52.465 [LogEvents]: Asteroid 16313 spawned at 132 km 06:43:52.465 [LogEvents]: Asteroid 32463 spawned at 127 km[/code] Убиваем все астероиды, стыкуемся со станцией и сохраняемся на ней. Перезагружаем игру. После загрузки сэйва стартуем со станции и наблюдаем тот же паттерн - все 15 астероидов реинкарнировали, но под другими id. [code]08:02:43.977 [LogEvents]: Navigation Buoy 12657 spawned at 10 km ... 08:02:43.977 [LogEvents]: Coriolis Station 330 spawned at 0 km 08:02:43.977 [LogEvents]: Asteroid 32373 spawned at 132 km 08:02:43.977 [LogEvents]: Asteroid 23001 spawned at 133 km 08:02:43.977 [LogEvents]: Asteroid 5101 spawned at 145 km 08:02:43.977 [LogEvents]: Asteroid 21494 spawned at 151 km 08:02:43.977 [LogEvents]: Asteroid 23310 spawned at 157 km 08:02:43.977 [LogEvents]: Asteroid 21672 spawned at 172 km 08:02:43.977 [LogEvents]: Asteroid 17102 spawned at 174 km 08:02:43.977 [LogEvents]: Asteroid 2142 spawned at 176 km 08:02:43.978 [LogEvents]: Asteroid 21942 spawned at 179 km 08:02:43.978 [LogEvents]: Asteroid 12538 spawned at 181 km 08:02:43.978 [LogEvents]: Asteroid 28671 spawned at 188 km 08:02:43.978 [LogEvents]: Asteroid 14641 spawned at 195 km 08:02:43.978 [LogEvents]: Asteroid 7211 spawned at 196 km 08:02:43.978 [LogEvents]: Asteroid 23084 spawned at 251 km 08:02:43.978 [LogEvents]: Asteroid 24115 spawned at 260 km[/code] Снова чистим астероиды. 13 штук уничтожено, осталось два. Возвращаемся на станцию и снова сохраняемся. Вот теперь после следующей перезагрузки все как положено. После старта со станции остались 2 астероида, причем у них те же id. [code]08:33:29.004 [LogEvents]: Navigation Buoy 12657 spawned at 10 km ... 08:33:29.004 [LogEvents]: Coriolis Station 330 spawned at 0 km 08:33:29.004 [LogEvents]: Asteroid 23084 spawned at 251 km 08:33:29.005 [LogEvents]: Asteroid 24115 spawned at 260 km[/code] Вывод: если после старта геймер переместился в другую систему, корректное запоминание уничтоженных астероидов не происходит.
P.S. Мне тут пришла в голову идея, что можно проблему детерминированных паттернов гораздо проще решить. Для меня лично проблема больше именно в воспроизводимом паттерне, а не в самой регенерации - глаз повторяющиеся паттерны цепляет помимо сознания. У меня возникла идея очень простого плагина, который просто сканирует популяцию астероидов и изымает часть популяции рандомно. При этом при каждом запуске отдельные элементы паттерна останутся на своих местах, но они будут давать разные мозаики и унылое ощущение deja vu разрушится. Я на неделю уезжаю, по возвращении, наверное, еще поразмыслю над этой идеей.
|
|
|
|
![](images/spacer.gif) |
31.08.15
|
|
To Sanata
"Правильной" ньютоновской физики в Элите не было, это я точно помню. Кобра летала именно так, как сейчас в Оолите: куда повернул, туда и полетел. Инерция появилась в сиквелах Элиты, а заодно пародия на небесную механику, типа выход на орбиту. Геймеры изрядно наматерились. Уж не знаю, как оно сейчас в пафосной Elite Dangerous - не удивлюсь, если все те же грабли. И все таки инерция в Оолите есть. Это хорошо заметно при сходе с джампа: при замыкании на массе корабль не останавливается как вкопанный, а пролетает еще около 10 километров. Инерция также ощущается при разгоне и торможении на обычном ходу - на набор полной скорости/торможение уходит время порядка секунды. Эффект заметен с джойстиком, где можно сектором газа мгновенно дать полный газ / полный стоп. Сделать полет "по инерции" как в жизни не выйдет, а вот более правдоподобную динамику разгона/торможения в Оолите 1.82 для корабля геймера сейчас реализовать элементарно. Здесь главное не увлечься реализмом и не забыть про игровой баланс. Более подробно об этих моментах я написал в Oolite physics.pdf (документ на русском языке, ссылка на мой бокс - Персональные страницы, в моей личной рубрике).
To Sanata
"Правильной" ньютоновской физики в Элите не было, это я точно помню. Кобра летала именно так, как сейчас в Оолите: куда повернул, туда и полетел. Инерция появилась в сиквелах Элиты, а заодно пародия на небесную механику, типа выход на орбиту. Геймеры изрядно наматерились. Уж не знаю, как оно сейчас в пафосной Elite Dangerous - не удивлюсь, если все те же грабли. И все таки инерция в Оолите есть. Это хорошо заметно при сходе с джампа: при замыкании на массе корабль не останавливается как вкопанный, а пролетает еще около 10 километров. Инерция также ощущается при разгоне и торможении на обычном ходу - на набор полной скорости/торможение уходит время порядка секунды. Эффект заметен с джойстиком, где можно сектором газа мгновенно дать полный газ / полный стоп. Сделать полет "по инерции" как в жизни не выйдет, а вот более правдоподобную динамику разгона/торможения в Оолите 1.82 для корабля геймера сейчас реализовать элементарно. Здесь главное не увлечься реализмом и не забыть про игровой баланс. Более подробно об этих моментах я написал в [color=#00FF00]Oolite physics.pdf[/color] (документ на русском языке, ссылка на мой бокс - Персональные страницы, в моей личной рубрике).
|
|
|
|
![](images/spacer.gif) |
30.08.15
|
|
В далёком 1993 затенял окна одеялом чтобы телевизор не отсвечивал и играл-играл в элиту. Как-же это было не просто с магнитофона грузит игру и сейв. Но это полбеды, Помню в той элите было очень трудно управлять КОБРОЙ, была космическая инерция. Разогнался, выключил двигатель и всё равно продолжаешь лететь вперёд. И чтобы остановится нужно было сделать кувырок на 180 градусов и опять же двигателем тормозить. Вращение гасить противофазой. А теперь представте как сложно было влететь в базу, УЖАС. ![Crying or Very Sad :cry:](./images/smilies/icon_cry.gif) Поэтому первым девайсом всегда был "докин компьютер". И воевать было сложно с таким управлением, панацеей были ракеты. Может у меня была НЕПРАВИЛЬНАЯ "элита" или неправильный "спектрум"? Пару месяцев назад рассказывал другу об этой эпической игре и полез в инет (мож на ютубе есть видюха ), вот тут то я и открыл для себя Оолиту. Первое что бросилось в глаза - УБРАЛИ эту ненавистную инерцию. Если создать "инерция.ОХР" это очень усложнит игру и добавит правдоподобности. Технически решаемый вопрос? Может кто-то захочет поиграть с таким управлением? ![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
В далёком 1993 затенял окна одеялом чтобы телевизор не отсвечивал и играл-играл в элиту. Как-же это было не просто с магнитофона грузит игру и сейв. Но это полбеды, Помню в той элите было очень трудно управлять КОБРОЙ, была космическая инерция. Разогнался, выключил двигатель и всё равно продолжаешь лететь вперёд. И чтобы остановится нужно было сделать кувырок на 180 градусов и опять же двигателем тормозить. Вращение гасить противофазой. А теперь представте как сложно было влететь в базу, УЖАС. :cry: Поэтому первым девайсом всегда был "докин компьютер". И воевать было сложно с таким управлением, панацеей были ракеты. Может у меня была НЕПРАВИЛЬНАЯ "элита" или неправильный "спектрум"? :x Пару месяцев назад рассказывал другу об этой эпической игре и полез в инет (мож на ютубе есть видюха ), вот тут то я и открыл для себя Оолиту. Первое что бросилось в глаза - УБРАЛИ эту ненавистную инерцию. Если создать "инерция.ОХР" это очень усложнит игру и добавит правдоподобности. Технически решаемый вопрос? Может кто-то захочет поиграть с таким управлением? :mrgreen:
|
|
|
|
![](images/spacer.gif) |
22.10.14
|
|
To GrayS Ну да, есть такое - Аддер в EliteWiki описан как имеющий складные крылья и способный к планетным посадкам. Беда в том, что писалось это еще в те времена, когда пакета Таргоида в помине не было и за базар никто не отвечал. В Элите геймер был привязан намертво к Кобре Марк Три, остальные корабли были чисто для антуража и писать об их свойствах и особенностях можно было что угодно. А теперь геймер начинает требовать: и где оно? Я думаю, если уж давать Аддеру возможность садиться на планету, то проще всего сразу укомплектовать его PLC и сделать такой Аддер как отдельный пакет. Это технически несложно. Думаю, обрабатывать износ PLC отдельно для Аддера по отдельному алгоритму не стоит. Эдак мы далеко уйдем. Почему владелец здоровенной Кобры Марк Три, к примеру, должен платить за установку теплозащиты столько же, как владелец Кобры Марк Один с ее намного меньшими габаритами? Другой вопрос, что штатных 2 т грузоподъемности Аддера для серьезных челночных перевозок маловато - чтобы окупить ремонт PLC стоимостью 2500 Кр, надо при профите 10 кредов с тонны груза совершить минимум 125 рейсов. Аддер окупился бы как такси земля-орбита при цене порядка 50...100 кр с пассажира - владелец Кобры Марк Три ради такого мизера связываться с этим бизнесом не будет. Однако для перевозки пассажиров даже между планетой и главной станцией нужна пассажирская каюта. Так что зона компетенции кораблика определяется: это именно что перевозки небольших партий контрабанды, курьерские перевозки и перевозки драгоценностей. Соответственно должен быть этот сегмент рынка. Однако и здесь кораблик слишком тихоходен для контрабандиста и курьера и слишком слабо вооружен для инкассатора. Теперь по поводу скорости посадки. Как раз на уровне кода я бы решил легко - при превышении скорости выше пороговой корабль теряет энергию и пилот просто вынужден сбросить скорость, чтобы не лишиться щитов и не разрядить энергостек до нуля. Причем даже мог бы по высоте напор смоделировать. Другой вопрос - а нужно ли это? Ничего интересного в процессе снижения с точки зрения пилотажа нет, как бы эти надуманные ограничения не обернулись очередным аркадным псевдосимулятором, как затея Петровича с "гравитацией". А что касается "потом эту темку пошерудить и собрать всё в одну кучу" - это сейчас просто, пока оно не утонуло. Почему и советую все идеи оформить в одном списке. И когда я буду готов приступить к работе, и правда проще будет. Тем более что к этому времени часть вопросов, возможно, придется рассмотреть под свежим углом зрения.
To GrayS
Ну да, есть такое - Аддер в EliteWiki описан как имеющий складные крылья и способный к планетным посадкам. Беда в том, что писалось это еще в те времена, когда пакета Таргоида в помине не было и за базар никто не отвечал. В Элите геймер был привязан намертво к Кобре Марк Три, остальные корабли были чисто для антуража и писать об их свойствах и особенностях можно было что угодно. А теперь геймер начинает требовать: и где оно? :D Я думаю, если уж давать Аддеру возможность садиться на планету, то проще всего сразу укомплектовать его PLC и сделать такой Аддер как отдельный пакет. Это технически несложно. Думаю, обрабатывать износ PLC отдельно для Аддера по отдельному алгоритму не стоит. Эдак мы далеко уйдем. Почему владелец здоровенной Кобры Марк Три, к примеру, должен платить за установку теплозащиты столько же, как владелец Кобры Марк Один с ее намного меньшими габаритами? Другой вопрос, что штатных 2 т грузоподъемности Аддера для серьезных челночных перевозок маловато - чтобы окупить ремонт PLC стоимостью 2500 Кр, надо при профите 10 кредов с тонны груза совершить минимум 125 рейсов. Аддер окупился бы как такси земля-орбита при цене порядка 50...100 кр с пассажира - владелец Кобры Марк Три ради такого мизера связываться с этим бизнесом не будет. Однако для перевозки пассажиров даже между планетой и главной станцией нужна пассажирская каюта. Так что зона компетенции кораблика определяется: это именно что перевозки небольших партий контрабанды, курьерские перевозки и перевозки драгоценностей. Соответственно должен быть этот сегмент рынка. Однако и здесь кораблик слишком тихоходен для контрабандиста и курьера и слишком слабо вооружен для инкассатора.
Теперь по поводу скорости посадки. Как раз на уровне кода я бы решил легко - при превышении скорости выше пороговой корабль теряет энергию и пилот просто вынужден сбросить скорость, чтобы не лишиться щитов и не разрядить энергостек до нуля. Причем даже мог бы по высоте напор смоделировать. Другой вопрос - а нужно ли это? Ничего интересного в процессе снижения с точки зрения пилотажа нет, как бы эти надуманные ограничения не обернулись очередным аркадным псевдосимулятором, как затея Петровича с "гравитацией".
А что касается "потом эту темку пошерудить и собрать всё в одну кучу" - это сейчас просто, пока оно не утонуло. Почему и советую все идеи оформить в одном списке. И когда я буду готов приступить к работе, и правда проще будет. Тем более что к этому времени часть вопросов, возможно, придется рассмотреть под свежим углом зрения.
|
|
|
|
![](images/spacer.gif) |
22.10.14
|
|
to ALEX_M и stranger ALEX_M: GrayS: он должен иметь посадочный модуль в базовой своей комплектации Не имеет. Да оно и понятно было, что не имеет. Ибо посадки на планету не были реализованы в Элите, да и в чистой Оолите тоже, это делают пакеты. Откуда вообще растут ноги про Аддер: Руководство тут на форуме: «Уж» (Adder) Выпускался Аутворлд Воркшопс (Outworld Workshops), незаконной компанией работающей без лицензии и с нарушением прав собственности других производителей - Спалдер (Spalder) и Прим Инкорпорейтед (Prime Inc). Суда класса Adder могут использоваться как в атмосфере, так и в космическом пространстве и часто применяются контрабандистами. Кроме того, наличие системы складных крыльев позволяет совершать посадку на планеты. Судно несет одну ракету типа Geret Starseeker. Насколько я помню в Элите тоже самое описание этого корабля. Так что по логике он без PLC должен уметь садиться. Но вот как это всё реализовать в коде? 1 - дать возможность Аддеру садиться без PLC, производить проверку только по работоспособности теплового щита; 2 - дать PLC в стандартную комплектацию Аддеру: ___а - при этом расчёт износа модуля для него вести по своему алгоритму; ___б - рассчитывать износ по общему алгоритму; 3 - оставить всё как есть, подчиняась золотому правилу сиса/программера: работает - отойди и не трогай. stranger: И просьба - собрать весь список идей по PLC в единый документ - я бы еще раз проглядел его, когда приступлю к работе над обновлением. Хех, да он вроде весь здесь ![Smile :)](./images/smilies/icon_e_smile.gif) . Хотя дополню, пока не забылось (легче потом эту темку пошерудить и собрать всё в одну кучу. 6 - Скорость. Корабли имеют разную скорость. И половина скорости (которую мы ставим при выходе в красную зону альтиметра) у Морригана составляет чуть меньше полной скорости Кобры МК-3. А, имхо, скорость при заходе на посадку не должна превышать какого-то порогового числа. И тут возникает 2 траблы: а - как это реализовать в коде. б - как указать пилоту на шкале скорости этот самый порог.
to ALEX_M и stranger
[quote="ALEX_M"][quote="GrayS"]он должен иметь посадочный модуль в базовой своей комплектации[/quote] Не имеет.[/quote] Да оно и понятно было, что не имеет. Ибо посадки на планету не были реализованы в Элите, да и в чистой Оолите тоже, это делают пакеты.
Откуда вообще растут ноги про Аддер: [quote="Руководство тут на форуме"]«Уж» (Adder) Выпускался Аутворлд Воркшопс (Outworld Workshops), незаконной компанией работающей без лицензии и с нарушением прав собственности других производителей - Спалдер (Spalder) и Прим Инкорпорейтед (Prime Inc). Суда класса Adder могут использоваться как в атмосфере, так и в космическом пространстве и часто применяются контрабандистами. [color=#008000]Кроме того, наличие системы складных крыльев позволяет совершать посадку на планеты.[/color] Судно несет одну ракету типа Geret Starseeker.[/quote] Насколько я помню в Элите тоже самое описание этого корабля. Так что по логике он без PLC должен уметь садиться. Но вот как это всё реализовать в коде? 1 - дать возможность Аддеру садиться без PLC, производить проверку только по работоспособности теплового щита; 2 - дать PLC в стандартную комплектацию Аддеру: ___а - при этом расчёт износа модуля для него вести по своему алгоритму; ___б - рассчитывать износ по общему алгоритму; 3 - оставить всё как есть, подчиняась золотому правилу сиса/программера: работает - отойди и не трогай.
[quote="stranger"] И просьба - собрать весь список идей по PLC в единый документ - я бы еще раз проглядел его, когда приступлю к работе над обновлением.[/quote] Хех, да он вроде весь здесь :). Хотя дополню, пока не забылось (легче потом эту темку пошерудить и собрать всё в одну кучу. 6 - Скорость. Корабли имеют разную скорость. И половина скорости (которую мы ставим при выходе в красную зону альтиметра) у Морригана составляет чуть меньше полной скорости Кобры МК-3. А, имхо, скорость при заходе на посадку не должна превышать какого-то порогового числа. И тут возникает 2 траблы: а - как это реализовать в коде. б - как указать пилоту на шкале скорости этот самый порог.
|
|
|
|
![](images/spacer.gif) |
22.10.14
|
|
GrayS: 1 - Имхо посадка на луну должна добавлять вдвое меньше к износу посадочного модуля, чем посадка на планету.
Логично. Я над этим думал. И это достаточно просто сделать. По хорошему, и теплозащита не нужна, но это сложнее реализовать в коде. GrayS: 2 - Все объекты, к которым можно пристыковаться, но нельзя сохраниться, сохраняют свои цены и ассортимент до перезагрузки. При каждой-же новой посадке ассортимент и цены обновляются.
Увы, здесь уязвимое место модели. Пакет In-System Market Restore не сохраняет рынки портов, которые создаются заново. Та же проблема с моими орбитерами. Решение требует трудоемкого квалифицированного кодирования. Я к этому не готов. GrayS: 3 - Имхо на лунах высокотехнологичных индустриальных планет должны быть агрофермы - правительство должно заботиться о пропитании своей планеты.
Эти агрофермы производят продукт исключительно для нужд своей системы и у них нет излишков продукции на экспорт. А принадлежа индустриальной системе, они в достатке снабжаются механизмами и электроникой для нужд производства. Так что получается еще одна локация, где побывать чисто из любопытства - рынка там нет. GrayS: 4 - Никогда не летал на Аддере (Уж), поэтому не знаю точно, но по описанию этого корабля он должен иметь посадочный модуль в базовой своей комплектации. Так-же возможно этому кораблю можно убрать износ данного модуля или сделать его более износостойким.
Только предустановленная теплозащита. И не думаю, что Аддер должен иметь какие-то преимущества в сравнении с более тяжелыми кораблями в плане износа ресурса - тогда уж распространять эти отличия на все корабли (износ PLC пропорционально весогабаритным характеристикам). И кстати, по логике изнашивается в первую очередь теплозащита, но платит геймер за ремонт PLC! Еще одна логическая дыра модели, унаследованная из канонического пакета Таргоида. GrayS: 5 - Хотелось бы видеть на верфи возможность заказа нужного корабля - заказал, предоплатил (частично/полностью), забрал через определённое время. Сделать возможность его нафаршировать (увеличение времени выполнения заказа), что-бы пересесть сразу на готовый. За дополнительную плату дать возможность фаршировать более высокотехнологичными вещами.
Трудоемкая реализация в скрипте. В любом случае независимо от моих ответов огромное спасибо за предложения. И просьба - собрать весь список идей по PLC в единый документ - я бы еще раз проглядел его, когда приступлю к работе над обновлением.
[quote="GrayS"] 1 - Имхо посадка на луну должна добавлять вдвое меньше к износу посадочного модуля, чем посадка на планету. [/quote] Логично. Я над этим думал. И это достаточно просто сделать. По хорошему, и теплозащита не нужна, но это сложнее реализовать в коде. [quote="GrayS"] 2 - Все объекты, к которым можно пристыковаться, но нельзя сохраниться, сохраняют свои цены и ассортимент до перезагрузки. При каждой-же новой посадке ассортимент и цены обновляются. [/quote] Увы, здесь уязвимое место модели. Пакет In-System Market Restore не сохраняет рынки портов, которые создаются заново. Та же проблема с моими орбитерами. Решение требует трудоемкого квалифицированного кодирования. Я к этому не готов. [quote="GrayS"] 3 - Имхо на лунах высокотехнологичных индустриальных планет должны быть агрофермы - правительство должно заботиться о пропитании своей планеты. [/quote] Эти агрофермы производят продукт исключительно для нужд своей системы и у них нет излишков продукции на экспорт. А принадлежа индустриальной системе, они в достатке снабжаются механизмами и электроникой для нужд производства. Так что получается еще одна локация, где побывать чисто из любопытства - рынка там нет. [quote="GrayS"] 4 - Никогда не летал на Аддере (Уж), поэтому не знаю точно, но по описанию этого корабля он должен иметь посадочный модуль в базовой своей комплектации. Так-же возможно этому кораблю можно убрать износ данного модуля или сделать его более износостойким. [/quote] Только предустановленная теплозащита. И не думаю, что Аддер должен иметь какие-то преимущества в сравнении с более тяжелыми кораблями в плане износа ресурса - тогда уж распространять эти отличия на все корабли (износ PLC пропорционально весогабаритным характеристикам). И кстати, по логике изнашивается в первую очередь теплозащита, но платит геймер за ремонт PLC! Еще одна логическая дыра модели, унаследованная из канонического пакета Таргоида. [quote="GrayS"] 5 - Хотелось бы видеть на верфи возможность заказа нужного корабля - заказал, предоплатил (частично/полностью), забрал через определённое время. Сделать возможность его нафаршировать (увеличение времени выполнения заказа), что-бы пересесть сразу на готовый. За дополнительную плату дать возможность фаршировать более высокотехнологичными вещами. [/quote] Трудоемкая реализация в скрипте. В любом случае независимо от моих ответов огромное спасибо за предложения. И просьба - собрать весь список идей по PLC в единый документ - я бы еще раз проглядел его, когда приступлю к работе над обновлением.
|
|
|
|
![](images/spacer.gif) |
21.10.14
|
|
GrayS: он должен иметь посадочный модуль в базовой своей комплектации Не имеет.
[quote="GrayS"]он должен иметь посадочный модуль в базовой своей комплектации[/quote] Не имеет.
|
|
|
|
![](images/spacer.gif) |
|