Точность расположения объектов в редакторе маршрута

[Zabor]

Старая тема, которая не дает мне покоя и в сотни раз замедляет строительство маршрута.

Речь о нестыковке секций пути в редакторе, путем длительных изысканий удалось установить следующее:

Координаты начала секции записываются в W файл с точностью до 6 знаков (параметр Position), т.е. может быть 616.345 или 35.2445 но никак не 452.7852, поскольку число до запятой определяется местом на тайле его изменить невозможно, для точности позиционирования остаются знаки после запятой, будут это тысячные или десятитысячные определяется разрядностью первого числа.

Как правило, первое число состоит из 3 знаков, и точность расположения секции определяется тысячными, как оказалось тут тоже все не просто, вот пример линковки трака к окончанию предыдущего:



В данном примере N предыдущий трак, N+1 следующий, сетка образуется возможными записями в W файле с шагом в одну тысячную.

Конец трака N естественно промахивается мимо точек координатной сетки, следующий трак может быть прилинкован (записаны координаты в W) только в точках A, B, C, D, во всех случаях будет смещение относительно оси пути предыдущего трака и так называемый "непровар" с киданием ПС в сторону смещения.

Кроме того, редактор делает стандартную ошибку выбора ближайшей точки, например в этой ситуации:



Точной стыковкой по оси пути будет точка D, однако редактор выберет B.

В данный момент ничего кроме ручной коррекции таких ошибок в W файле найти не удалось, это адский труд - на каждой секции: проверка, открытие W файла, коррекция, пересборка БД, проверка, повторная коррекция, перерсборка БД, проверка, Ок?, - запись в "тетрадочку".

Путем несложных расчетов можно примерно рассчитать срок выхода маршрута - ~10-15 лет, приходится искать выход дальше.


Удалось установить следующие нюансы:

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

- при добавлении новой секции (или перестыковке) в БД заносятся (добавляются) новые координаты именно с точностью до десятитысячной, которые возвращает редактор.

- запись координат в W файл ограничивается редактором на уровне 6 знаков, вне зависимости от положения запятой (точки).

Соответственно аккуратно уложенный и состыкованный путь, построенный путем добавления секций (внесение в БД координат с точностью до десятитысячной) будет разрушен пересборкой БД т.к. будут использованы данные из W файлов, округленные до тысячной в результате стыки "как бык написал".

В тоже время без пересборки невозможно внести в БД корректированные руками секции, получается замкнутый круг, в результате требуется пересборка и проверка после каждой секции.

Исправит ситуацию внесение редактором координат в W файлы с точностью 7 знаков (десятитысячные), проверено, что такие записи корректно обрабатываются при пересборке БД и проблем не возникает даже на краях тайлов.

Но подлый редактор снова грубо округлит все записи до 6 знаков при сохранении тайла .


Уф… разжевал проблему, предельно подробно, главный вопрос - как заставить редактор записывать координаты в W из 7 знаков, уверен, что это возможно, исходные данные есть в наличии, тот же QDirection он записывает на несколько порядков точнее, осталось только найти где изменить параметр, возможно и в train.exe в NEX редакторе …

Камрады, какие есть соображения по поводу где искать?

PS извиняюсь за много букв, иначе не объяснить, за ними стоят месяцы работы и проблема очень острая, очень прошу не засорять тему рекомендациями "забить", "не парится" и т.д., требуется совет и помощь.

[Im-Ho-Tep]

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

[Zabor]

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

Еще поубивавшись над реестром и конфигурационными файлами пришел к выводу, что эта гадость в виде округления зашита в код EXE файла, помучил его в NEX, PE Explorer, понял, что самому не осилить, ну не менять же по очереди все "6" в коде на "7" если этот параметр вообще записан в двоечном или шестнадцатеричном виде.

Есть идея написать авторам BIN патча, но с моим машинным английским могут и послать, хотя у них наверняка есть исходники и подсказать что поменять труда не составит.

Пересмотрел горы маршрутов, везде шестиразрядное число, значит еще никто не делал изменений (или никому нафиг не нужно), есть опасения, что там не все так просто как замена пары байт в EXE.

На данный момент уперся в тупик

[Im-Ho-Tep]

В свое время (когда мы с Витей активно делали кой-чего), я решал эту проблемму "от обратного" - выгонял от проблемных трэков в обратном (уже уложенном) направлении и уже там сводил (на полигоне координат ххх.ххх).
Еще есть прикол с угоном трэков при изменении угла их наклона (чтобы не расписывать - тема была на "сам знаешь где"). Опять таки, частично решается методом "от обратного".

[Zabor]

Как я уже не изгалялся, мне еще с координатами маршрута "не повезло", при практически прямом главном ходе 99% тайлов пересекается под углом, обратно пробовал, даже QDirection вставки при проблемном сведении переложенных участков научился подкручивать т.к. страшно даже подумать о повторном сведении скорректированных треков.

Попробую написать челобитную =)), тут выложу для коррекции инглиша, может помогут с изменением кода, иначе совсем труба, смотрю на часы после очередного пути всего лишь одной станции - 3-4 часа и понимаю, что не видать мне Белоострова в этом году…

[Zabor]

Проект челобитной, сваял как мог =))


Hello!

Help to solve please a problem of the editor of routes with record in W files of parameter "Position" from 6 signs on X and Y an example: Position (283.948 18.4804-589.711).

The track section should correct manually and constantly to update base paths, periodically manual editing has no success, the editor of a route cuts off works again to 6 signs.

Prompt please displacement and bytes which need to be changed in train.exe 1.7.051922 that he wrote down in W a file parameter Position of kind Position (283.9483 18.4804-589.7115).

Very much I hope for your help, thanks.

Russia, St.-Petersburg, Igor Zaborin email …..


Знающие английский проверьте плиз.

Надо определиться куда слать, как я понимаю админу сайта mstsbin.uktrainsim.com ?

[sfateev]

Сообщение от Zabor

Надо определиться куда слать, как я понимаю админу сайта mstsbin.uktrainsim.com ?

Игорь, писать лучше в guest book на сайте автора. Свой адрес писать необязвтельно, а вот e-mail нужно вписать в соответствующую графу над сообщением. Но Jiri Vanca (Džordž), давно забил на дальнейшее развитие своего проекта.
Всё же попытка - не пытка.
Я отправил тебе ЛС.

[APK-LVDZ]

Может быть, вам поможет установка Error Bias = 0?! Делается эта вещь при выборе режима выделения текстур тайла с последующим нажатием на правую кнопку мыши, и в появившемся меню выбирается опция Error Bias, где надо установить 0. Эта функция отвечает за порог ошибки местности. Т.е. вы когда строите, а потом и едете, обычно некоторые части земли меняются, если вы приближаетесь к ним, так сказать, лучше вырисовываются. Быть может, при "0" таких ошибок не будет?

[Zabor]

Большое спасибо, написал, будем ждать…

Алексей, это я уже к сожалению пробовал в параметре TerrainErrorScale маршрута, безрезультатно ((.

[ScreenMaker]

Знающие английский проверьте плиз.

Дорогой (Привет) ...

У меня возникла проблема с РМ. Я обнаружил, что РМ записывает в файлы *.w в параметре Position координаты, состоящие из 6-ти цифр, например: Position (283.948 18.4804 -589.711).

Вручную корректировать указанный параметр бесполезно так как РМ при любом новом сохранении опять обрезает данные до 6-ти знаков. // Что имелось ввиду в первой части, я так и не въехал...

Напомните (укажите), пожалуйста, байты и их размещение в train.exe 1.7.051922, которые нужно изменить, чтобы они записывали параметр Position в файлах *.w с другим разрядом, например 7-значным (Position (283.9483 18.4804-589.7115)).

Очень надеюсь на Вашу помощь, спасибо.

Игорь Заборин, Санкт-Петербург, Россия.
emailbox@web.com

=====================

Dear (Hello) ... // but 'Dear' it`s better, I think...

I have a problem with Route Editor (RE). I discovered that RE write a 6-digit values of objects coordinates in parameter 'Position' in '*.w' files, for example Position (283.948 18.4804 -589.711).

Also I discovered that it`s useless to edit the values of that parameter in '*.w' files, because after any new changes saving RE cuts that values to 6-digit.

Please, remind (show) me the bytes and them placement in 'train.exe' version 1.7.051922, which needs to be changed so as the values of parameter 'Position' was written in more than 6-digit form (Position (283.9483 18.4804-589.7115)).

I hope on Your help, thankyou very much.

Igor Zaborin, St.-Petersburg, Russia.
email@web.com

=====================

Дорогой (Привет) ... // Что в скобках - выбрать, сишные комменты - выкинуть

У меня есть проблема с РМ. Я обнаружил, что РМ записывает 6-значные значения координат объектов в параметре 'Position' в файлах '*.w', например Position (283.948 18.4804 -589.711).

Также я обнаружил, что бесполезно редактировать значия этого параметра в файлах '*.w', так как после любого нового сохранения РМ обрезает те значения до 6-ти знаков.

Пожалуйста, напомните (укажите, покажите /*все равно одно слово будет*/) байты и их размещение в файле 'train.exe версии 1.7.051922, которые нужно изменить, чтобы значения параметра 'Position' были записаны в более, чем 6-ти значном виде (Position (283.9483 18.4804-589.7115)).

Надеюсь на Вашу помощь, большое Вам спасибо.

Подпись.

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

>>> Фаргус - только качественные переводы

[Zabor]

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

[ScreenMaker]

Я переводил мозгами...
(как мог )

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

>>> а если не поймет, будем говорить по другому

[Zabor]

Высока вероятность, что автор Bin патча не ответит, ответы в гостевой выборочны, многие вопросы остаются без ответов…

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

Перекладывать однопутными это еще больший мазохизм + там еще и профиль, это многократный рост числа объектов.

Добиться от редактора записи в W 7 разрядного числа единственный приемлемый выход, но как непонятно, вопрос к программистам - раз в БД при добавлении пишется именно 7 знаков, значит, число есть в памяти, возможен ли его перехват и подмена записи в W файл?

[lyolik]

Привет Zabor. Пишу что делать.

вот адрес и значения: 003A6CBC: 67 66

Исправь по адресу 003A6CBC значение 67 на 66.

[Zabor]

lyolik, так в моем возрасте реально схватить сердечный приступ.

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

Исправил, - запись в W файл параметров позиции секции 9 знаков, при перезаписи файла (следующем сохранении) устойчиво!

Такой точности стыковки ниток в БД нет ни на одном из просмотренных мной (более сотни) маршрутов.

Как тебе это удалось?
Как может сказаться на других функциях или этот байт отвечает исключительно за округление?

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

add

Выезд путеизмерителя на контрольную секцию - СТЫК НЕ ОПРЕДЕЛЕН! Т.е. его просто нет, ошибка стыковки секции с уклоном 0,135 менее чувствительности моего измерителя, т.е. стыка просто нет!

И это без какой либо коррекции, за 1 минуту - шлеп секцию и получите.

Едрен батон, ВСЕ секции и статика переписаны в W на 6 знаков после запятой

[впал в ступор, тупо смотрит в W файл и пытается понять КАК?]