ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!
|
| » Скриптописание - делимся опытом, задаем вопросы | страница 114 |
|
|
|
|
Канал X3: Reunion »
Модовый и скриптовый отсек X3: Reunion: «Скриптописание - делимся опытом, задаем вопросы» |
|
|
|
Chem
 780 EGP
         
Рейтинг канала: 15(2610)
Репутация: 248
Сообщения: 4751
Откуда: Киев
Зарегистрирован: 08.01.2007
   |
|
А карта для чего ?
добавлено спустя 16 секунд:
А сюжет (который уже в обже)
_________________
Умножим энтропию на 0 :-)
Последний раз редактировалось: Chem (14:35 11-10-2008), всего редактировалось 1 раз |
|
|
|
Xenon J
 1007 EGP
    
Рейтинг канала: 11(1675)
Репутация: 160
Сообщения: 3390
Откуда: Ксенонский сектор 472
Зарегистрирован: 30.03.2007
|
|
| BORON FRIEND : |
|
Я зол Такая полезная вещь для моддеров и никто ей не пользуется!
|
По той простой причине что он для версии 1.4, а на дворе 2.5 
| AlexYar : |
|
И кому-то повезло её перехватить до того момента, как я снял патч "с конвейера"
|
К сожалению, нам с z_m_a не повезло. А так очень полезная команда, для миномета например. И если б ещё мина в удаленном секторе взрывалась... 
_________________
Последний раз редактировалось: Xenon J (23:23 23-03-2023), всего редактировалось 16 раз
Последний раз редактировалось: Xenon J (17:05 11-10-2008), всего редактировалось 1 раз |
|
|
|
AlexYar
 1916 EGP
    
Рейтинг канала: 13(2096)
Репутация: 325
Сообщения: 32766
Зарегистрирован: 26.10.2003
|
|
| z_m_a : |
|
А вот как устанавливались мины, например, в New Income. Срабатывают. Скриптов на них нет. Принадлежат пиратам. Как их создали? Или такие можно установить только при создании карты или начале новой игры.
|
Да, эти мины установлены на карте. При старте новой игры при считке карты ф-ии построения карты в обже активируют мины.
| z_m_a : |
|
Или все-таки есть способ поставить скриптом активированную мину
|
Без ext-патча нет такого способа.
| Xenon J : |
|
По той простой причине что он для версии 1.4, а на дворе 2.5
|
Ну, вообще-то, последняя версия была для 2.0.02. И кому-то повезло её перехватить до того момента, как я снял патч "с конвейера" 
|
|
|
|
z_m_a
105 EGP
Рейтинг канала: 7(635)
Репутация: 20
Сообщения: 264
Откуда: Подмосковье
Зарегистрирован: 23.07.2007
|
|
| Xenon J : |
|
А так очень полезная команда, для миномета например.
|
Активированнык мины в удаленном секторе взрываются(я не использовал чтобы игру не нагружать, все равно удаленный бой условен). Для подрыва скриптом проблем тоже вроде нет. Вывернемся.  А для миномета она не нужна(это только если мины устанавливать заранее нужно, но получается что Tерн в ХТМ бесполезен - неужели никто не пробовал  ).
|
|
|
|
AlexYar
1916 EGP
Рейтинг канала: 13(2096)
Репутация: 325
Сообщения: 32766
Зарегистрирован: 26.10.2003
|
|
| z_m_a : |
|
Активированнык мины в удаленном секторе взрываются
|
В удаленном секторе проверка на близость объектов-целей производится раз в 30 секунд. За это время цель может не приближаясь к мине проскочить её, шанс детонации приближается к нулю В удаленке корабли не летают, а "скачут" с частотой прыжка так же раз в 30 секунд
Такие мины, как есть в х3, вообще лучше в миноукладчиках и минометах не использовать. Слишком тормозно реализовано.
|
|
|
|
z_m_a
105 EGP
Рейтинг канала: 7(635)
Репутация: 20
Сообщения: 264
Откуда: Подмосковье
Зарегистрирован: 23.07.2007
|
|
| AlexYar : |
|
Такие мины, как есть в х3, вообще лучше в миноукладчиках и минометах не использовать. Слишком тормозно реализовано.
|
Можно, если осторожно. Подрывать самому. Подтормаживает, но не критично. Зато эффектно.
Пример1
Пример2
|
|
|
|
AlexYar
1916 EGP
Рейтинг канала: 13(2096)
Репутация: 325
Сообщения: 32766
Зарегистрирован: 26.10.2003
|
|
| z_m_a : |
|
Можно, если осторожно.
|
Ну, в единичном использовании да, а в массовом - нерационально
Сам косяк зарыт глубоко в строении иксов в неправильной организации объектов (кораблей/станций), в результате чего поиск любой цели для мины связан с перебором всех объектов, которые могут быть целью. А если следить за дистанцией ближайшего объекта нужно постоянно, то поиски идут в цикле, причем с малой задержкой (для активного сектора).
Тормоза при такой организации просто неизбежны.
А другую организацию не сделать, потому что глубоко порылся второй косяк Это устаревшая сигнально-скриптовая система, которая для хбтф еще как-то прокатывала, а с резким увеличением кол-ва и типов кораблей в х3 уже становится огромной обузой и препятствием для нормальной навигации и поиска.
Почему Егософт до сих пор ничего не сделал в этом направлении - непонятно, ведь решение таких и подобных косяков очень простое.
|
|
|
|
kalyanov
84 EGP
Рейтинг канала: 5(126)
Репутация: 28
Сообщения: 34
Откуда: Беларусь, Могилев
Зарегистрирован: 03.06.2008
|
|
Народ.
1.Как программно можно узнать:запущен ли глобальный скрипт или не запущен ?
2. Что можно сделать с PID, кроме как получить его (get PID) ?
|
|
|
|
Арманкессилон
 1740 EGP
    
Рейтинг канала: 9(1184)
Репутация: 346
Сообщения: 13122
Откуда: Ставрополь
Зарегистрирован: 16.08.2007
|
|
1. Заходишь в редактор и смотришь global script tasks.
добавлено спустя 12 минут:
2. Не помню. Но, как минимум, можешь потом это значение писать в сообщениях. Можешь имя из него сделать - да как фантазия позволяет
_________________
Все астероиды не пересчитать!
Последний раз редактировалось: Арманкессилон (09:56 31-10-2008), всего редактировалось 1 раз |
|
|
|
kalyanov
84 EGP
Рейтинг канала: 5(126)
Репутация: 28
Сообщения: 34
Откуда: Беларусь, Могилев
Зарегистрирован: 03.06.2008
|
|
| Арманкессилон : |
|
1. Заходишь в редактор и смотришь global script tasks.
|
"Программно"
| Арманкессилон : |
2. Не помню. Но, как минимум, можешь потом это значение писать в сообщениях. Можешь имя из него сделать - да как фантазия позволяет
|
1. Можно ли "убить" процесс, зная его PID ?
2. Можно ли узнать работает ли еще процесс с таким-то PID ?
|
|
|
|
AlexYar
1916 EGP
Рейтинг канала: 13(2096)
Репутация: 325
Сообщения: 32766
Зарегистрирован: 26.10.2003
|
|
1. Можно убить и не зная ПИД.
2. Можно узнать и не зная ПИД.
Уже давно используется трюк с автообновлением глобальных скриптов, которые крутятся в цикле на постоянке.
ПИД-ом лучше сразу не заморачиваться, а придумать какой-то флаг смены версии (глоб.переменная, значение в файле-описателе и прочее) и по нему заставлять скрипт убивать самого себя с последующим вызовом обновленной копии (через "переходник").
Точно так же можно и узнавать, работает нужный тебе скрипт, или не работает. Например, в глоб.переменной выставлять нужный флаг.
Насчёт конкретно по ПИДу убивать - не помню скриптовой команды kill task , нету такой вроде. А без неё глобальные скрипты не прибить, кроме как только из самих себя.
|
|
|
|
X3-Protector
180 EGP
Рейтинг канала: 5(166)
Репутация: 20
Сообщения: 634
Откуда: Новосибирск
Зарегистрирован: 26.07.2008
|
|
| kalyanov : |
1. Можно ли "убить" процесс, зная его PID ?
2. Можно ли узнать работает ли еще процесс с таким-то PID ?
|
Я же тебе давал свой скрипт как пример - пади не стал смотреть, или не понял чего.
Там конкретное самоуничтожение происходит, процесса и всех следов деятельности, если в $Power.Config.Command при проверке окажется значение 0, а это значение при активации UnInstall заносится в локальную переменную каждого корабля на котором запущен скрипт. С глобальным точно так же, если в глобальной переменной при проверке есть нечто особенное, например "STOP"/"UPDATE"/"DELETE", то выполнение скрипта можно легко перенаправить на подготовку к удалению, тоесть все дела на дефолт или там короче как надо, а после чего он самоликвидируется из глобального стека. В моём случае 1220 стек корабля, но я же его не просто вытряхивал из стека, иначе были бы последствия с количеством апгрейдов на корабле , я так неподумав сначало сделал, а потом только замутил "самоунинсталл" ...
... Добавлено 10.11.2008
Господа скриптеры, у меня такой вопрос, и ответ на него нужен чёткий и ясный, обязательно аргументированный и подкреплённый реальными фактами, и пожалусто без пустой фантазии и ссылок на неподтверждённые слухи, темболее намёков на самостоятельное выяснение истины - физически нет такой возможности, давно бы уже всё выяснил сам.
|
Какие могут быть не хорошие последствия в памяти после такого кода? (кликните здесь для просмотра)
$VarList.ID = 10
while $VarList.ID
. dec $VarList.ID =
...
. skip if not $VarList == null
. . $VarList = array alloc: size= 0
. $VarCell = array alloc: size= 2
. $VarCell [ 0 ] = $VarName
. $VarCell [ 1 ] = $VarData
. append $VarCell to array $VarList
. * resize array $VarCell to 0
. * $VarCell = null
...
end
|
Закоментированные команды естественно означают то что их нет, собственно говоря в этом то вся проблема - я не знаю точно и наверняка, обязательно ли разрушать массив? Я надеюсь всё же на то, что достаточно будет его пересоздать а старая копия массива находящаяся в памяти автоматом будет разрушена скрипт-движком. Я бы даже не церемонился с этим вопросом, но мне страшно представить то, каким размером будут сохранёнки и сколько памяти будет жрать игрушка после нескольких месяцев работы такого кода, и в тоже время мне не нужны лишние движения в коде, из за чего собственно этот вопрос и встал. Откуда такое опасение? Видел как-то подобный(закоментированному) код в каком-то скрипте, с тех пор меня мучают сомнения о безполезном содержимом в памяти...
_________________
Я давно уже не в форме, я уже совсем не тот, но не стоит делать вызов, я прославленный пилот... |
|
|
|
AlexYar
1916 EGP
Рейтинг канала: 13(2096)
Репутация: 325
Сообщения: 32766
Зарегистрирован: 26.10.2003
|
|
| X3-Protector : |
. skip if not $VarList == null
. . $VarList = array alloc: size= 0
|
Ну здесь точно ошибка. Наличие массива нужно проверять командой size of array.
А в целом, если на массив в игре не осталось ссылок, то движок игры прибьёт его в памяти.
|
|
|
|
X3-Protector
180 EGP
Рейтинг канала: 5(166)
Репутация: 20
Сообщения: 634
Откуда: Новосибирск
Зарегистрирован: 26.07.2008
|
|
| AlexYar : |
|
Ну здесь точно ошибка. Наличие массива нужно проверять командой size of array.
|
Именно этот массив я вытаскиваю из локальной переменной, соответственно его размер или больше нуля, или значение равно null - я не сохраняю массив в локальной переменной если он пустой, то есть делаю проверку на длину и если длина равна 0 то в локалку записываю значение null, короче полностью удаляю локальную переменную.
| AlexYar : |
|
А в целом, если на массив в игре не осталось ссылок, то движок игры прибьёт его в памяти.
|
Допустим, но в какой момент, сразу после команды $VarCell = Value, или $VarCell = array alloc: size= Number, или только после return Value - в какой именно момент скрипт-движок делает проверку и чистит память от недоступных/потерянных/забытых/выброшенных массивов?
_________________
Я давно уже не в форме, я уже совсем не тот, но не стоит делать вызов, я прославленный пилот...
Последний раз редактировалось: X3-Protector (18:52 10-11-2008), всего редактировалось 4 раз(а) |
|
|
|
AlexYar
1916 EGP
Рейтинг канала: 13(2096)
Репутация: 325
Сообщения: 32766
Зарегистрирован: 26.10.2003
|
|
| X3-Protector : |
|
то есть делаю проверку на длину и если длина равна 0
|
Ну так это не проверка на длину. На размер надо проверять именно командой размера массива, а не
if $array == null
| X3-Protector : |
|
в какой именно момент скрипт-движок делает проверку и чистит память от недоступных/потерянных/забытых/выброшенных массивов?
|
По идее, если во внешние (вне данного скрипта) переменные ссылки на массив не сохраняются, то после завершения работы скрипта массивы будут уничтожены. А вот если массив(ссылка) был сохранён в глобальную переменную, тогда очищать его просто необходимо, иначе сэйвы будут расти.
С локальными переменными объектов есть небольшой косяк, там при смерти объекта я не нашел в коде принудительного очищения переменных (они хранятся вне объекта, поэтому движком не уничтожаются при его смерти). И если переменные самому не очищать, то с постоянной ротацией кораблей/станций в игре замусоривание сэйвов будет неизбежно.
Последний раз редактировалось: AlexYar (20:40 10-11-2008), всего редактировалось 1 раз |
|
|
|
X3-Protector
180 EGP
Рейтинг канала: 5(166)
Репутация: 20
Сообщения: 634
Откуда: Новосибирск
Зарегистрирован: 26.07.2008
|
|
| AlexYar : |
Ну так это не проверка на длину. На размер надо проверять именно командой размера массива, а не
if $array == null
|
Тебе весело, а я вот  - всеравно спасибо что хочеш помоч.
| AlexYar : |
|
(они хранятся вне объекта, поэтому движком не уничтожаются при его смерти)
|
Я не об этом, я о том, что если в долгоиграющем скрипте постоянно создавать новые массивы используя один идентификатор $VarCell, то по логике любого программиста старый массив остаётся в памяти но не имеет на него указателя, то есть он просто хранится в памяти потому что его не удалили из памяти, но доступа уже к нему нет, та как его адрес не известен. А идентификатор переменной $VarCell, теоритически, до изменения значения данной переменной, содержал указатель на массив расположенный в памяти. Ну короче смысл всего написанного в том, что если в переменную $VarCell записать прежнее значение указателя на завалявшийся в памяти массив, то теоритически из за того что скрипт-движёк не удалил массив из памяти в момент перезаписи значения в переменной $VarCell, доступ к массиву будет полностью востановлен. А надо бы удалять массив сразу после изменения указателя на данный массив, точнее сказать перед записью в переменную $VarCell нужно сначало удалить из памяти массив, а потом присвоить новое значение переменной $VarCell.
...
|
Ещё мельче (кликните здесь для просмотра)
Я всёже надеюсь что ты меня понял, но всеравно попытаюсь разжевать ещё проще:
Идетификатор переменной $VarCell содержит указатель на область памяти( $VarCell=WORD PTR DS:[SI]), в которой записан массив размером 100 байт. Потом я перезаписываю содержимое переменной $VarCell абсолютно на другой тип данных( $VarCell=DWORD $02468ACE), соответственно я изменяю не сам массив размером 100 байт, а только перезаписываю 4 байтную область памяти в совсем другом месте, на которую указывает один из идентификаторов в системном массиве идентификаторов(во загнул то ), в общем размер переменной $VarCell всего 4 байта, в ней либо указатель на массив, либо число, либо короче что угодно.
Так вот меня и беспокоит то, что после перезаписи всего лиш указателя $VarCell, я теряю связь с областью памяти в которой расположен теперь уже на всегда потерянный массив, который невозможно удалить применив соответствующую команду. В скрипт-движке нет команд преобразователей сегментных указателей на данные в доступной скрипт-движку памяти, как например есть в том же Паскале(Function Ptr(seg,ofs):Pointer и Addr(Var)).
...
Кароче, блин, я хочу что бы было так:
Создаю массив $VarCell=DB $00,$00,$00,$00,$00,$00,$00,$00...
Изменяю массив $VarCell[7]=$07...
Читаю из массива $07= $VarCell[7]...
Удаляю массив $VarCell=null...
Это всё сказка в которую очень сильно хочется верить  ...
|
|
Вот как это примерно выглядит в памяти(REAL) (кликните здесь для просмотра)
ADDRES | DTYPE | COUNT | RECORD | Что примерно это значит | | 0000:0000 | | | 00 00 00 00 | ID_ARRAY Условный адрес массива идентификаторов в скрипт-движке | | 0000:0000 | | | 00 00 01 00 | ID_ARRAY[0].Ptr=(Pointer=0001:0000) | | 0000:0004 | | | 56 61 72 4C 69 73 74 00 | ID_ARRAY[0].Str=(CharStr='VarList') | | 0000:000С | | | 08 00 01 00 | ID_ARRAY[1].Ptr=(Pointer=0001:0008) | | 0000:0010 | | | 56 61 72 43 65 6C 6C 00 | ID_ARRAY[1].Str=(CharStr='VarCell') | | 0001:0000 | 04 00 | 01 00 | 00 00 02 00 | ID_ARRAY[0].Ptr^$VarList=(Pointer=0002:0000) | | 0001:0008 | 04 00 | 01 00 | 10 00 02 00 | ID_ARRAY[1].Ptr^$VarCell=(Pointer=0002:0014) | | 0002:0000 | 04 00 | 04 00 | 00 00 03 00 | ID_ARRAY[0].Ptr^$VarList^[0]=(Pointer=0003:0000) | | 0002:0008 | | | 0A 00 03 00 | ID_ARRAY[0].Ptr^$VarList^[1]=(Pointer=0003:000A) | | 0002:000C | | | 12 00 03 00 | ID_ARRAY[0].Ptr^$VarList^[2]=(Pointer=0003:0012) | | 0002:0010 | | | 1A 00 03 00 | ID_ARRAY[0].Ptr^$VarList^[3]=(Pointer=0003:001A) | | 0002:0014 | 04 00 | 04 00 | 22 00 03 00 | ID_ARRAY[1].Ptr^$VarCell^[0]=(Pointer=0003:0022) | | 0002:001C | | | 2A 00 03 00 | ID_ARRAY[1].Ptr^$VarCell^[1]=(Pointer=0003:002A) | | 0002:0020 | | | 36 00 03 00 | ID_ARRAY[1].Ptr^$VarCell^[2]=(Pointer=0003:0036) | | 0002:0024 | | | 42 00 03 00 | ID_ARRAY[1].Ptr^$VarCell^[3]=(Pointer=0003:0042) | | 0003:0000 | 01 00 | 06 00 | 41 72 67 6F 6E 00 | ID_ARRAY[0].Ptr^$VarList^[0]^=(CharStr="Argon") | | 0003:000A | 04 00 | 01 00 | E8 03 00 00 | ID_ARRAY[0].Ptr^$VarList^[1]^=(LongInt=1000) | | 0003:0012 | 04 00 | 01 00 | E8 6E 03 00 | ID_ARRAY[0].Ptr^$VarList^[2]^=(LongInt=225000) | | 0003:001A | 04 00 | 01 00 | FF FF E4 44 | ID_ARRAY[0].Ptr^$VarList^[3]^=(LongInt=-7100) | | 0003:0022 | 04 00 | 01 00 | 00 00 00 00 | ID_ARRAY[1].Ptr^$VarCell^[0]^=(LongInt=1000) | | 0003:002A | 01 00 | 08 00 | 43 6C 61 73 73 54 4C 00 | ID_ARRAY[1].Ptr^$VarCell^[1]^=(CharStr="ClassTL") | | 0003:0036 | 01 00 | 08 00 | 43 6C 61 73 73 4D 31 00 | ID_ARRAY[1].Ptr^$VarCell^[2]^=(CharStr="ClassM1") | | 0003:0042 | 00 00 | 00 00 | | ID_ARRAY[1].Ptr^$VarCell^[3]^=(null) |
|
Дык куда деётся содержимое массивов, уничтожается сразу после изменения $VarCell или навсегда остаётся безхозным после утраты указателя, пока скрипт работает? Скорей всего просто теряется в дебрях сегментов памяти(тут мы вспоминаем цитату из фильма "Я робот" - У них появляются секреты, им снятся сны), потому что кто-то поленился и сделал так как сделал, надеюсь это всё в ОБЖах спрятано и есть хоть малейший шанс исправить этот касяк.
_________________
Я давно уже не в форме, я уже совсем не тот, но не стоит делать вызов, я прославленный пилот...
Последний раз редактировалось: X3-Protector (02:00 11-11-2008), всего редактировалось 4 раз(а) |
|
|
|
AlexYar
1916 EGP
Рейтинг канала: 13(2096)
Репутация: 325
Сообщения: 32766
Зарегистрирован: 26.10.2003
|
|
| X3-Protector : |
|
если в долгоиграющем скрипте постоянно создавать новые массивы используя один идентификатор $VarCell, то по логике любого программиста старый массив остаётся в памяти но не имеет на него указателя, то есть он просто хранится в памяти потому что его не удалили из памяти, но доступа уже к нему нет, та как его адрес не известен
|
Ну опять же теоретически, чтобы избежать захламления памяти, нужно после записи массива, или значения в массив, сделать прерывание (поставить wait).
И всё. Во время прерывания скрипт остановится, и память будет очищена от всех массивов с потерянными ссылками.
А если ещё точнее хочешь услышать, то спроси у CheckerTwo.
А по ассемблерному мне не надо писать, я в нём не шпрехаю
|
|
|
|
X3-Protector
180 EGP
Рейтинг канала: 5(166)
Репутация: 20
Сообщения: 634
Откуда: Новосибирск
Зарегистрирован: 26.07.2008
|
|
| AlexYar : |
Ну опять же теоретически, чтобы избежать захламления памяти, нужно после записи массива, или значения в массив, сделать прерывание (поставить wait).
И всё. Во время прерывания скрипт остановится, и память будет очищена от всех массивов с потерянными ссылками.
|
О, это то что нужно - огромное тебе СПАСИБО, пока что будем считать что теория является действительностью!!!
| AlexYar : |
|
А если ещё точнее хочешь услышать, то спроси у CheckerTwo.
|
М-м-м, я спрошу как нибудь  .
| AlexYar : |
|
А по ассемблерному мне не надо писать, я в нём не шпрехаю
|
За то я в Сях не "шпрехн дзю дойч", вообще, даже ни разу в глаза не видел ...
_________________
Я давно уже не в форме, я уже совсем не тот, но не стоит делать вызов, я прославленный пилот...
Последний раз редактировалось: X3-Protector (01:53 11-11-2008), всего редактировалось 2 раз(а) |
|
|
|
kalyanov
84 EGP
Рейтинг канала: 5(126)
Репутация: 28
Сообщения: 34
Откуда: Беларусь, Могилев
Зарегистрирован: 03.06.2008
|
|
| X3-Protector : |
|
мне страшно представить то, каким размером будут сохранёнки и сколько памяти будет жрать игрушка после нескольких месяцев работы такого кода
|
Я тоже раньше задавался этим вопросом.
AlexYar прав.
| AlexYar : |
|
если на массив в игре не осталось ссылок, то движок игры прибьёт его в памяти.
|
Я проверял это следующим образом:
1. Создал массив;
2. Накачал в него оочень много данных (можно в цикле пихать любой мусор);
3.Сохранил в сохраненку (убедился что сохраненка увеличилась на несколько мегабайт);
4. массив = null или массив = array alloc... или массив = 5;
5. сохранил(убедился что сохраненка занимает мало места).
P.S.: ГТ пишешь ?
|
|
|
|
X3-Protector
180 EGP
Рейтинг канала: 5(166)
Репутация: 20
Сообщения: 634
Откуда: Новосибирск
Зарегистрирован: 26.07.2008
|
|
| kalyanov : |
|
(убедился что сохраненка занимает мало места)
|
Спасибо за помощ, теперь я знаю точно - я видел в неком скрипте самый что нинаесть лишний код, который написал некий скриптер, который собственно говоря не знает что к чему и разобраться не счёл нужным, и тому подобное из за чего такой скриптер как я и ты парили голову над этой безсмыслецей - в результате тебе респект, а тому скриптеру наоборот, антиреспект .
| kalyanov : |
|
P.S.: ГТ пишешь ?
|
Ну-у-у-у-у , как тебе сказать  , я сейчас занимаюсь одной очень интересной альтернативой, в общем мне как-то пока некогда, ну и всё такое - короче я интерпритатор команд пишу, кстати очень умный и функциональный, и хочу его сделать максимально идеальным с точки зрения эффективности кода и потребления памяти, плюс его синтаксические свойства и возможности плод моего давнего но пока невоплощённого изобретения. Когда увидеш моё творение, то понастоящему убедишся в том что скрипт-движок позволяет очень многое, даже не смотря на то что в нём многого пока не достаёт.
Ну и немного из раздела фантастики  (кликните здесь для просмотра)
Например нет такой команды, из за чего приходится изобретать сложный велосипед:
get value from: maintype=<Var/Number> subtype=<Var/Number> ID code=<Var/String>
Я сейчас составляю скриптовую альтернативу этой команды, которая будет из строки в специальном формате возвращать указатель на товар, сектор, корабль, станцию, контейнер, астероид и всё всё всё что имеет maintype, subtype, или ID code, или всё вместе, или взаимозаменяемо, или просто даже по соответствию типов аргументов для поиска. Короче, максимум три идентифицирующих строковых аргумента, замудрённая обработка данных и результат равен ожидаемому значению, при этом туда и обратно - это лиш малая часть возможностей будующего интерпритатора команд ...
|
_________________
Я давно уже не в форме, я уже совсем не тот, но не стоит делать вызов, я прославленный пилот... |
|
|
|
|
|
|
|
|
Канал X3: Reunion ->
Модовый и скриптовый отсек X3: Reunion: «Скриптописание - делимся опытом, задаем вопросы» |
|
|
| К списку каналов | Наверх страницы |
Цитата не в тему: Нельзя всем дать все. Потому что всех много, а всего мало. (правда о жизни от BuH'a)
|
| » Скриптописание - делимся опытом, задаем вопросы | страница 114 |
|
