Просмотр полной версии : Fixed-стрелки
Итак, эта тема создана! Некоторые совершенно напрасно полагают, что поддержка безлеверных стрелок якобы может прекратиться в следующих версиях игры. К таким людям вопрос: если останется поддержка фикседтреков вообще, то с чего бы кому-то убирать поддержку стрелок в них? Вообще, фиксед-стрелки созданы вовсе не для того, чтобы делать крестовины и подвижные остряки, а, как и все фиксед-трэки, для того чтобы иметь длину и форму по госту. Можно вообще не делать видимую мешь для этой стрелки, оставить только точки привязки для рельсов и использовать тэг "useadjoiningtracktype 1". Можно делать стрелки с процедурными рельсами без собственной анимации. Анимация - это уже наш внешний костыль, и её поддержку, конечно же, тоже никто не сможет убрать, потому что это скрипты.
Я провёл некоторые эксперименты, сделал опытные образцы. По моим понятиям, вполне себе реально построить на таких стрелках любую маршрутизацию, только она, само собой, должна учитывать существование этих стрелок. Я предлагаю (или даже навязываю) свою помощь в доделке нашей сигналки, но нужно знать, что именно нужно уметь делать.
Если говорить о поддержке любого SceneryWithTrack, то в общем случае всё выглядит так:
Proof of concept в студию.
Если хотите доказать, что фиксовые стрелки работают, покажите что:
1. Можно поймать Junction, Enter или аналог
2. Можно поймать Junction, Toggled или аналог
3. Можно встретить ее в GSTrackSearch и пойти по всем отклонениям
4. Можно однозначно идентифицировать, сохранить в супе и загрузить обратно
5. Можно пробежать по всем в одном общем списке всех таких стрелок, хоть нашем, хоть игровом
1. Да
2. Да
3. В GSTrackSearch встречается SceneryWithTrack, от него получаются все привязанные стрелки. Перебираются все варианты направлений стрелок (если стрелок 4, то 2^4=16 вариантов) и GSTrackSearch каждый раз выходит из начальной точки куда глаза глядят. Так мы пройдём по всем отклонениям.
4. Во-первых, сам SceneryWithTrack можно идентифицировать по ID, так как он - MapObject и поэтому GameObject. Во-вторых, каждая привязанная к нему JunctionBase является на самом деле JunctionBaseGameObject. Можно кастовать, можно использовать GameObject JunctioBase::GetGameObject(). Ну а сохранять всё это в супе не составляет труда.
5. Пробежать элементарно, если есть список :smile2233: А сформировать его можно, стартуя GSTrackSearch от светофоров и ходя по всем отклонениям, см. пункт 3.
---------------------------------
Разработка и внедрение описанного требует времени и сил. Но при некоторых условиях всё можно сделать по-бырику. Если мы договоримся о некоторой унификации и , например, поддержке только специальных SceneryWithTrack, наследуемых от нашего класса и с нужными тэгами в конфиге, или иной способ, то всё ещё проще. Я могу предложить такую концепцию:
- Не вводится никаких специальных SceneryWithTrack, поддерживаются все.
- Картостроитель в редакторе размещает на single-track стороне каждого соединения путей SceneryWithTrack-объекта специальный левер.
- Этот левер является класса, пусть JunctionLinked isclass Junction. В этом классе существует объект JunctionBase LinkedJunctionBase и процедура JunctionBase GetAssotiatedJunctionBase(), которая выдаёт соответствующую стрелку из скенери. Также в этом классе есть процедуры int GetDirectionLinked(), SetDirectionLinked(int) и другие аналоги, которые вызывают соответствующие функции в ассоциированной стрелке.
- Маршрутизация, работая с Junction (встречая Junction в GStrackSearch или перебирая все Junction в каком-либо списке), всегда проверяет Junction на isclass JunctionLinked. Если да, то вместо него работать с JunctionLinked::GetAssotiatedJunctionBase() либо с GetDirectionLinked(), SetDirectionLinked() и аналогами из класса JunctionLinked. Маршрутизация хранит этот левер в своих базах, списках, супах, как обычное Junction. World::GetJunctionList() также будет его возвращать.
- Откуда левер возьмёт свой объект LinkedJunctionBase? Поиск делается элементарно, только один раз при первом вызове любой функции этого класса. Можно сделать поиск и в Init(), но не вижу смысла затягивать этим загрузку карт.
- Если SceneryWithTrack анимирован и хотел бы визуально соответствовать направлению своих стрелок, то он может ловить сообщения "Junction" "Toggled" или быть специального класса, скажем, SceneryWithJunctions. Наш левер, если просечёт принадлежность скенери к SceneryWithJunctions, вызовет в нём специально объявленную процедуру StateChanged(). Чтобы вообще устранить из скенери handler-ы сообщений (если в этом имеется выигрыш для производительности), то маршрутизация должна работать со стрелкой только через наш левер класса JunctionLinked, который всегда будет вызывать StateChanged() в скенери класса SceneryWithJunctions.
Приведённая концепция чем хороша:
- При размещении стрелок на карте не нужно прокладывать невидимые пути, остаётся только разместить левер (который будет не лишним в TANE, ведь он сможет ещё и содержать теги для раскачки поезда при проезде стрелки, это одна из фич Тани). Из-за отсутствия невидимых путей стрелки можно без страха и упрёка двигать и поворачивать.
- Стрелки липнут друг к другу, поэтому вообще не нужно при добавлении на карту даже поворачивать стрелку, её можно сразу соединить или строго выровнять по предыдущей. TSM стрелки у меня не обладают этим свойством, думаю потому что у них kind "buildable" вместо "fixed track".
- Поддержка этой системы маршрутизацией делается естественным образом и очень быстро.
- Если Scenery со стрелками наследован от SceneryWithJunctions, то можно обеспечить, чтобы наш левер считывал ещё и информацию о том, переведена стрелка на отклонение или прямо. В этом случае отпадает необходимость в маркерах отклонения. Но тогда и маршрутизация должна поддерживать этот момент.
По описанному методу уже есть наработки - собственно, левер, и несколько стрелок, в том числе английская. TrackSearch всё находит, проблем не заметил. Дам потестить.
----------------------------------------
Как я уже говорил, считаю, что маршрутизация могла бы поддерживать вообще любые SceneryWithTrack и без вспомогательных леверов. Но для этого нужно придумать и реализовать всякие алгоритмы, чем я мог бы заняться, если бы получил ТЗ от автора. А вышеописанную схему можно реализовать в короткие сроки.
Спасибка за проделанную работу. В остальном пока не заинтересовал. В любом случае, пока не будет единого механизма получения списка всех стрелок на карте (именно JunctionBase) по типу JunctionBase[] GetJunctionList(void), я даже слышать не хочу вот это
Поддержка этой системы маршрутизацией делается естественным образом и очень быстро.
Поскольку это достаточно громкое заявление
Кстати сказать, даже в общем случае работа со Scenery, в которых есть только одна стрелка, достаточно тривиальна и может идти по упрощённому алгоритму.
Поскольку это достаточно громкое заявление
А ты не прочитал ничего небось. За спасибку спасибо.
пока не будет единого механизма получения списка всех стрелок на карте (именно JunctionBase) по типу JunctionBase[] GetJunctionList(void)
Причём здесь это? Концепцию я описал. Для неё достаточно Junction[] GetJunctionList()
Основная проблема - это то, что далеко не до всех стрелок можно добраться, только
стартуя GSTrackSearch от светофоров и ходя по всем отклонениям
По поводу "привязного" левера проблема кстати та же. Он не добавляется в список стрелок.
Nemo, я все прочитал. Во первых, как уже заметил Tram_, левер ссылка в список так же не попадает, к тому же - это очередной ненужный костыль.
Эрендир, я уже давно мечтаю заставить аурановцев сделать фиксед-стрелку, на которую отдельно добавляется левер.
TRam_, их бесполезно что-то заставлять. Вот если бы ты вложил на КС 8000, то тогда бы заставил, а так на халяву они ничего делать не хотят.
как уже заметил Tram_, левер ссылка в список так же не попадает
Да, проверил.
очередной ненужный костыль.
По-моему, стрелки с невидимыми рельсами, как сейчас - куда больший костыль. И ничего, пользуемся.
далеко не до всех стрелок можно добраться, только стартуя GSTrackSearch от светофоров и ходя по всем отклонениям
А какой интерес для маршрутизации представляют стрелки, до которых нельзя добраться от светофоров?
---------- Сообщение добавлено в 18:15 ---------- Предыдущее сообщение размещено в 18:12 ----------
У аурановцев ещё будет фича Interlocking Towers, вот интересно, как они со всем этим поступят.
куда больший костыль. И ничего, пользуемся.
Так от костылей нужно уходить, а не изобретать новые
А какой интерес для маршрутизации представляют стрелки, до которых нельзя добраться от светофоров?
Посмотри мою мультиплеерную маршрутизацию. Вот там они представляют интерес, поскольку ими диспетчер управляет через пульт.
Не уверен, что CustomJunction isclass Junction сработает. Нужен пруф.
Да и смысл, все равно методы ты не перегрузишь, АПИ будет новым и с классическими стрелками не взаимозаменяем. Зачем тогда вводить эту новую сущность? Проще будет работать с сразу со SceneryWithTrack.
который будет не лишним в TANE, ведь он сможет ещё и содержать теги для раскачки поезда при проезде стрелки, это одна из фич Тани
Теги для раскачки в конфиге левера?
http://s00.yaplakal.com/pics/userpic/8/4/1/av-414148.jpg
3. Можно встретить ее в GSTrackSearch и пойти по всем отклонениям
НЯП, JunctionBase GSTrackSearch.GetObject() не возвращает?
P.S. GetAssotiatedJunctionBase -> GetAssociatedJunctionBase.
что CustomJunction isclass Junction сработает
Сработает, только безсмысленно
Не уверен, что CustomJunction isclass Junction сработает.
Работает здесь всё, кроме того, что этих леверов нет в общем списке World-а. Не потому, что они наследуются, а потому, что стоят на объекте.
Да и смысл, все равно методы ты не перегрузишь, АПИ будет новым и с классическими стрелками не взаимозаменяем.
Объявлены все аналоги необходимых функций. Но я так понял, отсутствие в общем списке всё равно кидает нас.
Проще будет работать с сразу со SceneryWithTrack.
Это конечно лучше, если б кто дал ТЗ того, что нужно сделать...
Посмотри мою мультиплеерную маршрутизацию. Вот там они представляют интерес, поскольку ими диспетчер управляет через пульт.
А как так получается, что диспетчер управляет стрелками, до которых нельзя дойти от светофоров? Что это вообще за стрелки такие?
---------- Сообщение добавлено в 18:33 ---------- Предыдущее сообщение размещено в 18:28 ----------
НЯП, JunctionBase GSTrackSearch.GetObject() не возвращает?
Не возвращает. Возвращает SceneryWithTrack, и тогда мы перебираем не 2 направления одной стрелки, а все варианты для всех стрелок в объекте.
Теги для раскачки в конфиге левера?
Ага, очень будет удобно. Тем более что в свойствах это настраивается.
---------- Сообщение добавлено в 18:38 ---------- Предыдущее сообщение размещено в 18:33 ----------
Кстати сказать, GSTrackSearch возвращает этот SceneryWithTrack, даже если подходит к стрелке пошёрстно с отклонения, на которое она не переведена.
Кстати сказать, GSTrackSearch возвращает этот SceneryWithTrack, даже если подходит к стрелке пошёрстно с отклонения, на которое она не переведена.ну Junction тоже возвращается если не переведена. Это "следующий за ней" не возвращается.
---------- Сообщение добавлено в 17:02 ---------- Предыдущее сообщение размещено в 16:57 ----------
Да, ещё что мы забыли. По умолчанию SceneryWithTrack безымянные, в отличии от леверов. Потому если маршрутизация использует для генерации маршрутов имена, все стрелки должны быть проименованы либо вручную, либо перерасставлены с тегом автоименования.
---------- Сообщение добавлено в 17:03 ---------- Предыдущее сообщение размещено в 17:02 ----------
И самое последнее что мне не нравилось в этих стрелках (но с маршрутизацией это не актуально) - их положение не указывается на мини-карте.
Работает здесь всё, кроме того, что этих леверов нет в общем списке World-а. Не потому, что они наследуются, а потому, что стоят на объекте.
Не понял. Ты смешиваешь две вещи:
1. JunctionBase не попадает в список т.к. не является Junction
2. Наследуемый от Junction объект не попадает в список
2.1. Потому что он сделан как scenery а не mojunction
2.2. Потому что в список не попадают невалидные стрелки (т.е. те, где нет отклонения).
2.3. Еще какая-либо причина
Объявлены все аналоги необходимых функций.
Не нужны аналоги, нужны те же самые. Тогда это будет фасад. А у тебя все равно все системы надо перепиливать. Смысл тогда возиться с костылем?
Это конечно лучше, если б кто дал ТЗ того, что нужно сделать...
Дана произвольная горловина с простыми и двойными стрелками.
Задача: вывести на экран/в лог для каждого направления каждой стрелки направление следующей по этому пути стрелки.
Задача со звездочкой: Найти точные длины путей между стрелками (подозреваю, что и тут не все так просто, см далее).
Ага, очень будет удобно. Тем более что в свойствах это настраивается.
А какого вида настройки?
Не возвращает. Возвращает SceneryWithTrack, и тогда мы перебираем не 2 направления одной стрелки, а все варианты для всех стрелок в объекте.
И тут начинается веселье, т.к. нам неизвестны точные положения ни одной из стрелок. А методы для Track не работают.
Кстати сказать, GSTrackSearch возвращает этот SceneryWithTrack, даже если подходит к стрелке пошёрстно с отклонения, на которое она не переведена.
SceneryWithTrack — это объект с физическим размером. Когда мы проходим границу, GSTS возращает его. Стрелка находится внутри него, это лишь точка. И положение этой точки нам неизвестно. Мы в болоте, остается только трассировать все возможные варианты направлений.
Мы пришли в SWT. Допустим, он из 4 стрелок произвольно расположенных.
Мы не можем просто так взять и определить где ближайшая к нашему поиску. Начав искать от одной, мы можем пройти через другие, не узнав об этом. Потому надо проверять все.
Мы берем 1 стрелку, 3 других ставим во все возможные положения (для 2 — 16, для 3 — 81), проходим по всем направлениям выбранной (*2 или *3) и повторяем это надо сделать них для всех (*4).
Цель: найти путь, по которому мы вошли в SWT и все пути, выходящие из него.
Найдя их мы получаем все маршруты через SWT — мы знаем при каком положении стрелок с какого пути войдя в объект мы из него выйдем. Но мы вообще не представляем, как эти пути увязаны внутри него, не можем определить их длины, ничего, просто черный ящик.
А теперь представь, что внутри SWT мы встречаем светофор. Как он расположен? Ответить невозможно. Мы ведь взяли SWT из 4 стрелок. Это может быть съезд, английская стрелка, кусок горловины, да что еще создателю в голову взбредет.
Как видишь, поддержка SWT в общем случае — очень сложная задача.
С учетом неработающих JunctionBase.GetTrackInDirection и JunctionBase.GetDirectionToTrack — нерешаемая.
Потому они и никем и нигде не поддерживаются.
Конечно, все очень упрощается, если мы введем частные случаи. Это будут обычная стрелка, двойная, перекрестная, съезды и т.д. Каждый вариант SWT — это жестко заданная конфигурация путей и стрелок.
Исходя из вышесказанного, нам нужно уметь определять входы и выходы из SWT. Это проще всего сделать отметив их маркером.
Договоримся, что у нас есть известные маркеры нескольких цветов и что каждая стрелка в определенном варианте SWT имеет заранее определенный цвет. Это и вариант SWT указывается в конфиге.
Тогда на карте, ставив объектную стрелку, мы должны поставить маркер перед стрелкой с соответствующим цветом.
Тогда скрипт, встретив SWT будет ожидать маркер. Встретив маркер запоминает его, ищет по конфигу SWT, номер стрелки и тип объекта. И он знает в каком направлении пришел, и как пройти по этому объекту. Даже если мы встречаем светофор внутри него, мы уже будем знать, между какими стрелками он заключен, т.к. все стрелки промаркированы, а взаиморасположение стрелок задано в варианте SWT.
Вопрос только, сильно ли это облегчит нам жизнь это, стоит ли оно повышения сложности сканирующих пути скриптов?
Даже если JunctionBase.GetTrackInDirection и JunctionBase.GetDirectionToTrack работают, проще от этого не будет. Можно будет обойтись без костылей, но проще не будет.
Мы в болоте, остается только трассировать все возможные варианты направлений.ну, в случае леверов не особо проще.
Тогда скрипт, встретив SWT будет ожидать маркер. Встретив маркер запоминает его, ищет по конфигу SWT, номер стрелки и тип объекта. И он знает в каком направлении пришел, и как пройти по этому объекту.грубо говоря, z7-xPath и zxPath основаны на этой идее. Отличие только в том, что кроме маркеров, которые окружают стрелку, могут искаться другие стрелки, и направление стрелки определяется именно исходя из предыдущего объекта поиска.
Чисто теоретически, поиском из центра по JunctionBase.BeginTrackSearch(int direction), в случае если мы имеем только "простейшие" автоименуемые и имеющие отличительный тег стрелки, мы сможем найти всех соседей так же, как и в случае левера.
Проблема только в поиске списка. Самый тупой способ который я вижу - перебирать все ID всех объектов от 1 и до тех пор, пока 100 последовательных ID окажутся пустыми, на каст в SceneryWithTrack. Хорошо что это можно во время инициализации стрелок делать, а не каждый раз.
ну, в случае леверов не особо проще.
В случае с леверами все намного проще — можно определить соседей и составить граф. В случае с SWT есть только сам SWT и зависимость состояния стрелок и путей от входа до выхода. А внутри эти стрелки с путями могут хоть в клубок быть завернуты. Без маркировки или GetTrackInDirection ты его не распутаешь.
Это такой типичный черный ящик, где снаружи на панельке можно переключать стрелки, потом тебе завязывают глаза, заводят внутрь и выводят наружу. Как и через что ты прошел внутри ты не увидишь.
amd103, я ж понял. Поэтому и говорю, что для начала ввести "простейшие" автоименуемые и имеющие отличительный тег стрелки. По поводу того что ты сказал, да, можно определить где какой конец , но только зная внутренее устройство. Просто отдельно маркеры можно не добавлять, если 2 разных фикседтрака не соединяются 2мя и более выходами.
Автоименуемые — это, блин, autoname 1, что вводить-то?
Отличительный тег — ну сделаем мы этот тег для обычной простейшей стрелки. Перепилим все скрипты для поддержки этой стрелки. Потом вспомним, что бывают еще и не простейшие стрелки, и что, опять скрипты перепиливать?
Нет уж, надо сразу определяться — надо/не надо, стандарт, алгоритмы.
Я против. Существенное усложнение скриптов ради еще одного варианта с костылем? Прошиваемые стрелки — проверенная и отработанная технология.
При правильном подходе прошивка занимает 10 секунд. Сколько можно прошить стрелок за время, требуемое для разработки новых фиксов, создание стандарта, написание и отладку сканирующих скриптов, адаптацию СЦБ?
Я считаю, что для главных путей и небольших горловин подойдут прошиваемые объекты. Для больших горловин и удаленных мест — процедурные.
Для процедурных стрелок можно создать специальные адаптированные варианты путей (т.е. другие модели шпал и т.п.), для ЖБ это актуально.
tramwayz
17.09.2014, 19:26
Ну что я могу сказать: кодеры бьются, у моделлеров лбы трещат.
Нет уж, надо сразу определяться — надо/не надо, стандарт, алгоритмы.2 стандарта. Или только фиксед-стрелки, или только обычные. Мне в принципе не очень много перепиливать в zxPath для того чтобы на основе JunctionBase.BeginTrackSearch(int direction) (заработавшего кстати только в 3.7) перепилить поиски в генераторах маршрутов и в системе определения свободности участков.
---------- Сообщение добавлено в 18:33 ---------- Предыдущее сообщение размещено в 18:30 ----------
Ну что я могу сказать: кодеры бьются, у моделлеров лбы трещат.у картостроителей. Моделлерам кстати должно быть на это наплевать - фиксед-стрелка делается из обычной "анимированной" некоторыми правками конфига...
2 стандарта. Или только фиксед-стрелки, или только обычные.
Выкинуть поддержку обычных стрелок? Отличная шутка.
Мне в принципе не очень много перепиливать в zxPath для того чтобы на основе JunctionBase.BeginTrackSearch(int direction) (заработавшего кстати только в 3.7) перепилить поиски в генераторах маршрутов и в системе определения свободности участков.
Ага. Только логика этого поиска для SWT будет совсем другая.
Только логика этого поиска для SWT будет совсем другая.никто ж не спорит. Вклинивается GetAttachedJunctions. Ну и будут "мёртвые зоны" от края стрелки до точки поиска, которые нужно будет допроверять.
Выкинуть поддержку обычных стрелок? Отличная шутка.почему я поднял эту тему - аурановцы поломали сообщения типа Object,Leave для стрелок и прочих траксайдов, поэтому они выскакивают по нескольку раз на один и тот же поезд. Мне вот интересно, с фикседтраками всё то ж самое?
---------- Сообщение добавлено в 18:48 ---------- Предыдущее сообщение размещено в 18:45 ----------
P.S. аурановцы потом всплывут - "а что это русские опять старьё используют" :mocking:
Ну да, всего-то GetAttachedJunctions(). Все просто, пока мы работаем с простыми стрелками. Ведь на жд только стандартные марки простых стрелок и ничего более.
Ну и будут "мёртвые зоны" от края стрелки до точки поиска, которые нужно будет допроверять.
А разве мы не будем стартовать поиск во все стороны, чтобы найти своё положение?
Почему же клубок-то? Во-первых, я хочу сказать, что для JunctionBase-ов, приаттаченных к SWT, вполне себе работает GetTrackInDirection(int) - я пользуюсь ею. Кроме того, мы можем наравне со списком аттаченных стрелок получить список аттаченных Track-ов. Сущетвует int Track::GetDirectionToTrack(Track other). Делаем следующее. Получаем все пути в SWT, и случаем все друг с другом во всевозможных сочетаниях с помощью Track::GetDirectionToTrack(Track). И сразу получаем граф. Ну и понять, где какая стрелка не составит труда по GetTrackInDirection().
Ок, я исходил из тог, что GetTrackInDirection(int) неработоспособен.
А что с JunctionBase::GetDirectionToTrack(Track)?
Nemo, а порядок леверов и путей в списке сохраняется или "плавает" от сессии к сессии?
---------- Сообщение добавлено в 19:01 ---------- Предыдущее сообщение размещено в 19:00 ----------
исходил из тог, что GetTrackInDirection(int) неработоспособен.для леверов он неработоспобен. Видимо только для фикседтраков.
---------- Сообщение добавлено в 19:02 ---------- Предыдущее сообщение размещено в 19:01 ----------
А разве мы не будем стартовать поиск во все стороны, чтобы найти своё положение?я говорю о проверке свободности участка пути между 2мя стрелками. То есть нам надо будет искать от центра одной до границы другой и от центра другой до границы первой.
Он нигде не рабочий. Точнее он конечно работает, но неправильно.
а порядок леверов и путей в списке сохраняется или "плавает" от сессии к сессии?
Я много раз грузил одну и ту же сессию, меняя скрипты, ну немножко её редактировал. Всегда в одном порядке, соответствующем последовательности описания стрелок в конфиге SWT (контейнер junction-vertices).
Он нигде не рабочий. Точнее он конечно работает, но неправильно.
А в чем именно неправильность выражается?
amd103, ты же вроде тестил и должен знать.
Я послушал людей опытных, велосипед не изобретал и взял готовое решение :blush:
Он нигде не рабочий. Точнее он конечно работает, но неправильно.
А мне тоже интересно, в чём именно дело. Сам не сталкивался с проблемами.
SHEP Rom
18.09.2014, 00:31
Вау, какая вумная тема. Я правда нифига не понял, окромя того, что типа стрелки могуть быть хитро...сделанные и шибко вумные, но спасибу аффтару паставил, когда что. :yes:
SHEP Rom, в trainz есть объектные суперстрелки, которым не надо прокладывать пути, и к которым начиная с версии 3.7 можно подключить скриптовый поиск путевых объектов. Но на миникарте они не отображаются, полупрозрачных стрелочек не имеют, поэтому удобно их переключать исключительно маршрутизацией (иначе не поймёшь куда поедет твой поезд).
Ещё одна фитча таких стрелок - что они управляются скриптом совсем по-другому, нежели стрелки с левером. Более того, в одной такой стрелке может быть спрятана куча стрелок (например стрелка 2/9 полностью в сборе), и чтобы понять, следует ли с такими стрелками вообще связываться, если "в такую стрелку можно запихать целую станцию", мы тут развели дискуссию :wacko:
на миникарте они не отображаются
Честно говоря, от неё толку мало. Маршрут текущего поезда не подсвечивается, на больших станциях легко запутаться и ничего не понятно, стрелочки иногда закрыты другими стрелочками и переводятся не те стрелки, на которые щёлкаешь. Может у меня одного такие проблемы, не знаю.
полупрозрачных стрелочек не имеют, поэтому удобно их переключать исключительно маршрутизацией (иначе не поймёшь куда поедет твой поезд)
Это если у такой стрелки совсем нет скрипта, иначе она остряки двигает, или даже может сама стрелочки рисовать. Переключаются они вручную простым кликом мышкой на любую точку меша стрелки, впрочем эта возможность легко убирается или апгрейдится с помощью скрипта.
Kompozitor
18.09.2014, 01:11
Маршрут текущего поезда не подсвечивается
А можно сделать подсвечиваемым, как в Path Control? Или альтернативу мини-карте придумать, в виде браузера, убрав оттуда все ненужное, например? Интересно, будет ли такая возможность в новой игре?
поэтому удобно их переключать исключительно маршрутизацией
Или дефолтными командами. С ними все четко.
Добавлю, что анимация в них работает по дефолту. Но...
При попытке сделать в одном объекте несколько стрелок, их остряки приаттачились в 0,0,0. Можно бы на это и забить и мешами стрелки управлять полностью самим, однако наличие (анимированого) меша остряков/привода/стрелочек/etc для каждой стрелки является обязательным.
При клике по любой части объекта выполняется запрос на перевод стрелки, которая указана первой в конфиге. Как выше отмечено, это легко перегружается.
:ps:
"в такую стрелку можно запихать целую станцию"
А в метро так и будет:phil:
---------- Сообщение добавлено в 02:15 ---------- Предыдущее сообщение размещено в 02:13 ----------
Или дефолтными командами.
Опять же, смотря какими. Полагаю, в дефолте тоже полно всего, что не подозревает, что JunctionBase не обязательно Junction.
Маршрут текущего поезда не подсвечивается, на больших станциях легко запутаться и ничего не понятно, стрелочки иногда закрыты другими стрелочками и переводятся не те стрелки, на которые щёлкаешь. Может у меня одного такие проблемы, не знаю.
Такая же байда - часто невозможно перевести нужную стрелку из-за наложения с соседними, а если и получится, то отследить маршрут из-за наложений почти нереально, приходится ходить непосредственно по путям и следить по леверам или острякам.
Kompozitor
18.09.2014, 13:21
часто невозможно перевести нужную стрелку из-за наложения с соседними
Это зависит от расстановки. На смежных путях лучше леверы ставить не напротив друг друга. Хотя с объектными стрелками левер особо не подвигать. Но лучше пользоваться правилом уменьшения размера леверов.
Но лучше пользоваться правилом уменьшения размера леверов.
Это где это такое?! :nyam2:
Powered by vBulletin™ Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot
