RailUnion.net

А если это чудо будет ещё и под *nix пахать то ещё лучше =)

Неужели для кого-то это может быть приятной новостью? А вы в курсе что MSTS был изначально кросс-платформенным, а потом Microsoft убила Linux версию... (именно поэтому там все конфиги в utf8 а не windows кодировке)

Мне идея с ДЛЛ кажется неудачной. Скрипты будут гибче, не нужно будет колупаться с линковкой, экспортом\импортом, писать заголовочники.

Это неудобство планировалось обойти так: сделать SDK для написания устройств - фактически болванка DLL которая ничего не делает, но содержит все ф-ции, которые будующий автор устр-ва просто будет реализовывать. В пустые строки вписывать свой код. Все вопросы импорта экспорта уже должны быть решены на стадии болванки.
В конце концов можно написать одно единственное устройство - ScriptHandler которое будет вставляться в каждый вагон. А работать так: читать скрипт из указанного текстового файла и выполнять его. Какой скрипт, какие возможности - на совести автора этого устройства. Мне скрипты кажутся наиболее удобными из-за того что меняя их не нужно менять исходный код самой программы - это и скорость разработки и удобство для сторонних разработчиков. Но встает большой вопрос производительности (даже самые быстрые скрипты будут в 10-100 раз медленнее исходного кода на C++), как следствие сразу ограничение на возможную детальность логической модели. Думаю у любого продукта конечным потребителям пофиг как сделано и через что(в плане скрипты не скрипты...) - а вот когда тормозит - неприятно.

только потоки писать - за**шься, память выделять - зае**шься, делать связки через память для вызова ф-ции одной DLLки по желанию другой - зае**шься...

Планировалось что код в DLL не знает о том что он внутри DLL и не знает о других DLL, но у него есть доступ к свойствам вагона. Это дерево которое в том числе складывается из свойств устройств (картинки уже выложил). Если например Клуб в одном устройстве а ЭПК в другом и КЛУБ-у надо сорвать ЭПК - он лезет в вагон в соответствующее свойство ставит там 1 вместо 0 - а ЭПК реагирует на это свойство.

ты таким подходом, может, пневмосистему и сделаешь, но КЛУБ - никогда

Почему? По факту наоборот. Пневмосистема нечто общее для всего состава - ее в одном устройстве не описать. Устройства могут дополнять ее и взаимодействовать с ней. А клуб самодостаточный агрегат который всего лишь работает со своими данными и срывает ЭПК...

break писал(а):Но встает большой вопрос производительности (даже самые быстрые скрипты будут в 10-100 раз медленнее исходного кода на C++)

Статические скриптовые языки никто не отменял.

break писал(а):Если например Клуб в одном устройстве а ЭПК в другом и КЛУБ-у надо сорвать ЭПК - он лезет в вагон в соответствующее свойство ставит там 1 вместо 0 - а ЭПК реагирует на это свойство.

Ужас.

Признаюсь честно всякие глупые комментарии людей неразбирающихся меня жутко бесят и отталкивают от мыслей возможности распространения проекта в принципе. Крайне сложно воспринимать без эмоций то что ты стараешься делать хорошо как только можешь...

Статические скриптовые языки никто не отменял.

- нет понятия таких языков - есть статическая типизация которая может присутствовать как в скриптовом так и в компилируемом языке программирования
- скриптовые языки с компиляцией в промежуточный байт-код, снимают стадию парсинга исходника, но не стадию виртуальной машины языка которая в 10-100 раз может выполняться медленнее. Скрипты не предназначены для решения задач придирчивых к производительности. Это языки бизнес логики, и умности NPC - зачастую в различных конторах даже программисты разделяются на программистов "C++" и "скриптеров".

Ужас.

...

Придирайтесь к словам, что ж. Только работа КЛУБа тоже не является задачей, придирчивой к производительности.

Только работа КЛУБа тоже не является задачей, придирчивой к производительности.

Да на счет этого согласен, а вот Работа ВР(и многих пневмо устройств) к сожадению является т.к. зависит от давлений в резервуарах, которые могут быстро изменяться (экстренное торможение и не только).

Что же касается производительности статически типизируемых (так уж и быть!) языков и кода на С++, прошу просмотреть это, или это, или сотни других тестов. Цифры в 10-100 не вижу.

Это неудобство планировалось обойти так: сделать SDK для написания устройств - фактически болванка DLL которая ничего не делает, но содержит все ф-ции, которые будующий автор устр-ва просто будет реализовывать. В пустые строки вписывать свой код. Все вопросы импорта экспорта уже должны быть решены на стадии болванки.

Зачем, если можно сделать скрипты, делающие что угодно? Ты создаешь ограничения на пустом месте.

он лезет в вагон в соответствующее свойство ставит там 1 вместо 0 - а ЭПК реагирует на это свойство.

А если в вагоне по дефолту свойства нет? КЛУБ, кстати, состоит не только из КЛУБа и ЭПК, там огромное количество входных и выходных цепей, десятки, которые в стандартную схему вагона не вписываются. Это, кстати, одна из причин, по которым для каждой серии ПС разрабатывается отдельный проект установки КЛУБ.

Крайне сложно воспринимать без эмоций то что ты стараешься делать хорошо как только можешь...

Без проблем — закрывай тему, сливай только пресс-релизы в нее. Нет обсуждения — нет анальной обиды.

о не стадию виртуальной машины языка которая в 10-100 раз может выполняться медленнее

Ой-вей. Дай б-г, если падение составляет 20%.

Это языки бизнес логики, и умности NPC - зачастую в различных конторах даже программисты разделяются на программистов "C++" и "скриптеров".

И тут мы вспоминаем Обливион, в котором вся игровая логика выполнена на скриптах, Готику, Кризис, ХЛ, что угодно. Тоже 10-100 раз?

Работа ВР(и многих пневмо устройств) к сожадению является т.к. зависит от давлений в резервуарах, которые могут быстро изменяться (экстренное торможение и не только)

и? логики не вижу. Пересчёт всех давлений линейный, для корректной работы вполне достаточно 100 пересчётов в секунду

agmike писал(а):

break писал(а):Если например Клуб в одном устройстве а ЭПК в другом и КЛУБ-у надо сорвать ЭПК - он лезет в вагон в соответствующее свойство ставит там 1 вместо 0 - а ЭПК реагирует на это свойство.

Ужас.

согласен

Зачем, если можно сделать скрипты, делающие что угодно? Ты создаешь ограничения на пустом месте.

Никаких ограничений не вижу - нормальный подход - плагины, устройства - так абсолютно везде. По поводу устройства которое будет выполнять скрипт также писал.

А если в вагоне по дефолту свойства нет? КЛУБ, кстати, состоит не только из КЛУБа и ЭПК, там огромное количество входных и выходных цепей, десятки, которые в стандартную схему вагона не вписываются. Это, кстати, одна из причин, по которым для каждой серии ПС разрабатывается отдельный проект установки КЛУБ.

Клуб при загрузке в вагон сам создает свои свойства - вагон это за него не делает, также ЭПК. Если само устройство ЭПК не было загружено - клуб при первом обращении автоматом создает свойство к которму обращается (при этом разработчик клуба об этом не заботится - он пишет как всегда - обращение к полю дерева свойств) Т.к. ЭПК нет то на это свойство ничто не отреагирует. Устройства сами цепляются за свойства за которыми хотят наблюдать. Могут за свои - могут за свойства других устройств. Могут за свойства вагона или поезда.

Без проблем — закрывай тему, сливай только пресс-релизы в нее. Нет обсуждения — нет анальной обиды.

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

Ой-вей. Дай б-г, если падение составляет 20%.

А приведенные тесты нельзя так напрямую учитывать - там рассматривается время полного перебора и доступа к элементам в Hash, Map, и других контейнерах. Конкретно в пневматике решается система уравнений что напорядок сложнее, и не будет корректно работать в скриптах т.к. время на расчет будет уходить больше чем время одного шага. Также не желаю особо развивать эту тему. Дело в том что задачей этого сима было сделать пневмосистему на уровне имитации - т.е. если есть 20 вагонов и в каждом ВР - то считать их все - а не считать один и потом применять алгоритмя затухания и т.д. То есть создать реальную модель системы.

И тут мы вспоминаем Обливион, в котором вся игровая логика выполнена на скриптах, Готику, Кризис, ХЛ, что угодно. Тоже 10-100 раз?

Я считаю да - если задачи расчета физики и отрисовки графики выполняются 1000 раз в секунду - то логики 10 и этого будет достаточно для нормальной работы NPC.

и? логики не вижу. Пересчёт всех давлений линейный, для корректной работы вполне достаточно 100 пересчётов в секунду

Мне вообще непонятно что вы тут называете линейностью. Нарастание давления в резервуарах при соединении не линейно. Расчет всей системы еще более нелинеен (даже если рассматривать устойчивые процессы в каждый момент времени, пренебрегая градиентом давления в каждом конкретном соединении), кроме того есть масса засад - сделать корректный расчет чтобы не было зависимости от порядка прохождения по резервуарам, не нарушалась стабильность системы при соединении резервуара с больши объемом с резервуаром с маленьким объемом и др. Не думаю что это вообще реально сделать на скриптах именно из-за производительности - не будет возможности использовать многопоточность для распараллеливания вычислений.

Если например Клуб в одном устройстве а ЭПК в другом и КЛУБ-у надо сорвать ЭПК - он лезет в вагон в соответствующее свойство ставит там 1 вместо 0 - а ЭПК реагирует на это свойство.

Ужас.

согласен

Хотелось бы все таки комментарий.. Старнно что вы господа пугаетесь классического приема программирования под названием "Листенер".

Дело в том что задачей этого сима было сделать пневмосистему на уровне имитации - т.е. если есть 20 вагонов и в каждом ВР - то считать их все

моя система пересчитывает - надо 20, надо 130 вагонов. Только теперь делаю собственном абсолютно реалистичный ВР - итого число параметров на каждый вагон увеличилось с 5 до 10

(+на лок 3-4 параметра)

Старнно что вы господа пугаетесь классического приема программирования под названием "Листенер".

перепроверять параметры раз в 1/n долю секунды желательно применять только для непрерывно меняющихся параметров. В остальных случаях лучше применять обработчик события, ИМХО. А событий-то много: от включения тумблера до набора очередной позиции (т.к. они фиксированные). Можно конечно и перепроверкой всех параметров (ВЛ10-1628) но вероятность возникновения совершенно непонятных глюков сильно повышается.

рs подумай что-нибудь с КС. Чувствую, это будет проблема №2 твоего сима (проблемой №1 пока считаю рельсы и особенно стрелки)

моя система пересчитывает - надо 20, надо 130 вагонов. Тол...........

Реальный машинист вашу систему тестил? Сказал что похоже? А мою ДА! (но слава богу неточности и ошибки есть так что есть куда стремится)

В остальных случаях лучше применять обработчик события

Так вот листенер и нужен для ловли обработчиков событий! - никакого комментария по поводу "Ужас." "Согалсен" я не получил...

Так вот листенер и нужен для ловли обработчиков событий!

так на ловлю процессорное время тратится. Еслит обработчик всё сам сделает во всех модулях - это намного рациональнее.

Реальный машинист вашу систему тестил?

и реальные тоже.

так на ловлю процессорное время тратится.

Как же меня бесит когда люди не разбираются в том что говорят - на что тратится ??? почитай в гугле про паттерн программирования Листенер - че ты треш со мной о том в чем ни бум бум (это при всем уважении без обид - по другому я достучаться не могу уже...)

и реальные тоже.

и сказали что похоже я надеюсь?
Ну что ж остановимся на том что я выбрал неправильный подход...в пневматике ПРИЗНАЮ (уверен дискуссия дальне приведет к аналогичным выводам по всем пунктам)

А событий-то много: от включения тумблера до набора очередной позиции (т.к. они фиксированные). Можно конечно и перепроверкой всех параметров (ВЛ10-1628) но вероятность возникновения совершенно непонятных глюков сильно повышается.

уписаться просто - а повесить листенера только на 1 единственное событие кот. нам нужно и ничего не проверять (читай не тратить процессорное время) - как и работает моя система - вызывает только восклицание "УЖАС"...

тумблер - поле int
позиция - поле int

вешаем листенер на нужное поле и усе

Т.к. ЭПК нет то на это свойство ничто не отреагирует. Устройства сами цепляются за свойства за которыми хотят наблюдать.

Вот у меня есть КЛУБ, САУТ и КОН, все одновременно хотят контлировать ЭПК. Как быть?

далее проше не развивать...- бессмыслено - пойдут взаимные оскарбления, потом опять почистите форум - и т.д.

Код: Выделить всё

 AlexanderG (03:24:13 7/01/2010)
http://radikal.ru/F/s45.radikal.ru/i108/0911/68/dc4e862d8773.jpg.html
http://www.imagepost.ru/?v=Club_Background.png

Нужно мнение машиниста — что выглядит реалистичнее?

 Colonel_13 (14:52:15 8/01/2010)
Первый фотка, а второй как то не очень. Да еще координа вместо координата и кнопки внизу не так немного расположены.

 AlexanderG (14:52:42 8/01/2010)
Вот насчет этого человек с пеной у рта доказывал, что оно круче, чем фототекс

 Colonel_13 (14:20:46 9/01/2010)
Пусть пускает пену дальше. :-D

Я считаю да - если задачи расчета физики и отрисовки графики выполняются 1000 раз в секунду - то логики 10 и этого будет достаточно для нормальной работы NPC.

Ок, почему тогда мои скрипты в ТРС работают? Кстати. Заявление о 1000FPS в играх полностью дискредитирует тебя как человека, имеющего отношение к геймдеву.

до набора очередной позиции (т.к. они фиксированные)

Не всегда.

Реальный машинист вашу систему тестил? Сказал что похоже? А мою ДА!

Мою тестил, сказал что очень похоже. При том, что там скриптов немного, в основном тонкая настройка ТРСовского движка.

че ты треш со мной

Ну чо, поцан, садись на корты, перетрем поцанские темы. Сам с какова района буде? А закурить е?

уписаться просто - а повесить листенера только на 1 единственное событие кот. нам нужно и ничего не проверять (читай не тратить процессорное время) - как и работает моя система - вызывает только восклицание "УЖАС"...

Мы люд простой, с ДЛЛ мало работали. Покажи на примерах кода, как, например, я могу зажечь лампочку в кабине, или запустить сканирование пути, дабы выяснить расстояние до светофора.

break писал(а):А приведенные тесты нельзя так напрямую учитывать - там рассматривается время полного перебора и доступа к элементам в Hash, Map, и других контейнерах. Конкретно в пневматике решается система уравнений что напорядок сложнее, и не будет корректно работать в скриптах т.к. время на расчет будет уходить больше чем время одного шага. Также не желаю особо развивать эту тему. Дело в том что задачей этого сима было сделать пневмосистему на уровне имитации - т.е. если есть 20 вагонов и в каждом ВР - то считать их все - а не считать один и потом применять алгоритмя затухания и т.д. То есть создать реальную модель системы.

Что-то ты как-то избирательно заметил одни тесты и не заметил другие. Так вот, математические тесты там тоже были. К тому же ничего не мешает задать типы и алгоритмы в движке, а их использование перенести в скрипты. Разумеется, не все — газодинамику нет смысла переносить в скрипты.

если задачи расчета физики и отрисовки графики выполняются 1000 раз в секунду

Давно не видел в играх 1000 кадров в секунду.

Не думаю что это вообще реально сделать на скриптах именно из-за производительности - не будет возможности использовать многопоточность для распараллеливания вычислений.

http://www.mono-project.com/Scripting_With_Mono

Если например Клуб в одном устройстве а ЭПК в другом и КЛУБ-у надо сорвать ЭПК - он лезет в вагон в соответствующее свойство ставит там 1 вместо 0 - а ЭПК реагирует на это свойство.

Ужас.

согласен

Хотелось бы все таки комментарий.. Старнно что вы господа пугаетесь классического приема программирования под названием "Листенер".

Хех, первое мало похоже на листенер.

И еще, ты наверняка прекрасный программист и разработчик ПО и т.д., все же, то, что нужно сообществу лучше самого сообщества никто не знает. Я не программист, опыт минимальный, но на то, отчего будут лишь неудобства, указать-то могу.