Просмотр полной версии : Точность расположения объектов в редакторе маршрута
Старая тема, которая не дает мне покоя и в сотни раз замедляет строительство маршрута.
Речь о нестыковке секций пути в редакторе, путем длительных изысканий удалось установить следующее:
Координаты начала секции записываются в W файл с точностью до 6 знаков (параметр Position), т.е. может быть 616.345 или 35.2445 но никак не 452.7852, поскольку число до запятой определяется местом на тайле его изменить невозможно, для точности позиционирования остаются знаки после запятой, будут это тысячные или десятитысячные определяется разрядностью первого числа.
Как правило, первое число состоит из 3 знаков, и точность расположения секции определяется тысячными, как оказалось тут тоже все не просто, вот пример линковки трака к окончанию предыдущего:
http://i082.radikal.ru/0907/c2/1d20173e7fdf.gif
В данном примере N предыдущий трак, N+1 следующий, сетка образуется возможными записями в W файле с шагом в одну тысячную.
Конец трака N естественно промахивается мимо точек координатной сетки, следующий трак может быть прилинкован (записаны координаты в W) только в точках A, B, C, D, во всех случаях будет смещение относительно оси пути предыдущего трака и так называемый "непровар" с киданием ПС в сторону смещения.
Кроме того, редактор делает стандартную ошибку выбора ближайшей точки, например в этой ситуации:
http://i078.radikal.ru/0907/c0/bc13015fda22.gif
Точной стыковкой по оси пути будет точка D, однако редактор выберет B.
В данный момент ничего кроме ручной коррекции таких ошибок в W файле найти не удалось, это адский труд - на каждой секции: проверка, открытие W файла, коррекция, пересборка БД, проверка, повторная коррекция, перерсборка БД, проверка, Ок?, - запись в "тетрадочку".
Путем несложных расчетов можно примерно рассчитать срок выхода маршрута - ~10-15 лет, приходится искать выход дальше.
Удалось установить следующие нюансы:
- при пересборке БД она прекрасно понимает значения координат с точностью до десятитысячной, т.е. например 557.2545 будет корректно обработано и точность стыковки будет идеальной.
- при добавлении новой секции (или перестыковке) в БД заносятся (добавляются) новые координаты именно с точностью до десятитысячной, которые возвращает редактор.
- запись координат в W файл ограничивается редактором на уровне 6 знаков, вне зависимости от положения запятой (точки).
Соответственно аккуратно уложенный и состыкованный путь, построенный путем добавления секций (внесение в БД координат с точностью до десятитысячной) будет разрушен пересборкой БД т.к. будут использованы данные из W файлов, округленные до тысячной в результате стыки "как бык написал".
В тоже время без пересборки невозможно внести в БД корректированные руками секции, получается замкнутый круг, в результате требуется пересборка и проверка после каждой секции.
Исправит ситуацию внесение редактором координат в W файлы с точностью 7 знаков (десятитысячные), проверено, что такие записи корректно обрабатываются при пересборке БД и проблем не возникает даже на краях тайлов.
Но подлый редактор снова грубо округлит все записи до 6 знаков при сохранении тайла http://www.trainsim.ru/forum/images/smiles/spiteful.gif.
Уф… разжевал проблему, предельно подробно, главный вопрос - как заставить редактор записывать координаты в W из 7 знаков, уверен, что это возможно, исходные данные есть в наличии, тот же QDirection он записывает на несколько порядков точнее, осталось только найти где изменить параметр, возможно и в train.exe в NEX редакторе …
Камрады, какие есть соображения по поводу где искать?
PS извиняюсь за много букв, иначе не объяснить, за ними стоят месяцы работы и проблема очень острая, очень прошу не засорять тему рекомендациями "забить", "не парится" и т.д., требуется совет и помощь.
Im-Ho-Tep
19.07.2009, 11:49
Zabor, а я тебе давно (http://trainsim.ru/forum/showpost.php?p=85118&postcount=517) говорил, что проблемма в фиксированной шестиразрядности записи редактором координат в .w-файл, а ты не верил. ;)
Пока не приперло глубоко не копал, как началась перекладка готовых путей по электронному профилю со вставкой массы 10 метровок оно сразу вылезло, поначалу выводил до десятитысячной руками и был очень доволен стыковкой, потом "случайно" сохранил тайл в редакторе, увидел этот беспредел и сразу поверил :russian:.
Еще поубивавшись над реестром и конфигурационными файлами пришел к выводу, что эта гадость в виде округления зашита в код EXE файла, помучил его в NEX, PE Explorer, понял, что самому не осилить, ну не менять же по очереди все "6" в коде на "7" если этот параметр вообще записан в двоечном или шестнадцатеричном виде.
Есть идея написать авторам BIN патча, но с моим машинным английским могут и послать, хотя у них наверняка есть исходники и подсказать что поменять труда не составит.
Пересмотрел горы маршрутов, везде шестиразрядное число, значит еще никто не делал изменений (или никому нафиг не нужно), есть опасения, что там не все так просто как замена пары байт в EXE.
На данный момент уперся в тупик :(
Im-Ho-Tep
19.07.2009, 12:13
В свое время (когда мы с Витей активно делали кой-чего), я решал эту проблемму "от обратного" - выгонял от проблемных трэков в обратном (уже уложенном) направлении и уже там сводил (на полигоне координат ххх.ххх).
Еще есть прикол с угоном трэков при изменении угла их наклона (чтобы не расписывать - тема была на "сам знаешь где"). Опять таки, частично решается методом "от обратного".
Как я уже не изгалялся, мне еще с координатами маршрута "не повезло", при практически прямом главном ходе 99% тайлов пересекается под углом, обратно пробовал, даже QDirection вставки при проблемном сведении переложенных участков научился подкручивать т.к. страшно даже подумать о повторном сведении скорректированных треков.
Попробую написать челобитную =)), тут выложу для коррекции инглиша, может помогут с изменением кода, иначе совсем труба, смотрю на часы после очередного пути всего лишь одной станции - 3-4 часа и понимаю, что не видать мне Белоострова в этом году…
Проект челобитной, сваял как мог =))
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 ?
Надо определиться куда слать, как я понимаю админу сайта mstsbin.uktrainsim.com ?Игорь, писать лучше в guest book на сайте автора (http://mstsbin.uktrainsim.com/eng/eng.html). Свой адрес писать необязвтельно, а вот e-mail нужно вписать в соответствующую графу над сообщением. Но Jiri Vanca (Džordž), давно забил на дальнейшее развитие своего проекта.
Всё же попытка - не пытка.
Я отправил тебе ЛС.
APK-LVDZ
19.07.2009, 14:52
Может быть, вам поможет установка Error Bias = 0?! Делается эта вещь при выборе режима выделения текстур тайла с последующим нажатием на правую кнопку мыши, и в появившемся меню выбирается опция Error Bias, где надо установить 0. Эта функция отвечает за порог ошибки местности. Т.е. вы когда строите, а потом и едете, обычно некоторые части земли меняются, если вы приближаетесь к ним, так сказать, лучше вырисовываются. Быть может, при "0" таких ошибок не будет?
Большое спасибо, написал, будем ждать…
Алексей, это я уже к сожалению пробовал в параметре TerrainErrorScale маршрута, безрезультатно ((.
ScreenMaker
19.07.2009, 15:04
Знающие английский проверьте плиз.
Дорогой (Привет) ...
У меня возникла проблема с РМ. Я обнаружил, что РМ записывает в файлы *.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)).
Надеюсь на Вашу помощь, большое Вам спасибо.
Подпись.
=====================
Первое - это то, что я записал в нормальном виде с того, что мне удалось перевести с английского. Дальше я перевел на английский, а затем опять на русский, чтобы было видно, что увидит англоязычный чел.
>>> Фаргус - только качественные переводы ;)
ScreenMaker, спасибо, это уже пригодится для переписки с автором, если в гостевой не ответят, выглядит лучше, правда обратный перевод сильно зависит от того, на чем переводить и в каком режиме.
ScreenMaker
19.07.2009, 15:14
Я переводил мозгами...
(как мог ;))
Кстати, там есть парочка незначительных грамматических ошибок, но смысл текста по идее именно тот, что в обратном последнем переводе. То есть получатель поймет то, что от него хотят, я уверен.
>>> а если не поймет, будем говорить по другому :)
Высока вероятность, что автор Bin патча не ответит, ответы в гостевой выборочны, многие вопросы остаются без ответов…
Тем временем пришлось "сходить на компромисс" в грузовом парке Парголово секции A5, главный путь я руками корректирую, боковые нитки уже никак не скорректируешь, там иногда бывают чудовищные ошибки, вот это уже зло непобедимое.
Перекладывать однопутными это еще больший мазохизм + там еще и профиль, это многократный рост числа объектов.
Добиться от редактора записи в W 7 разрядного числа единственный приемлемый выход, но как непонятно, вопрос к программистам - раз в БД при добавлении пишется именно 7 знаков, значит, число есть в памяти, возможен ли его перехват и подмена записи в W файл?
Привет Zabor. Пишу что делать.
вот адрес и значения: 003A6CBC: 67 66
Исправь по адресу 003A6CBC значение 67 на 66.
lyolik, так в моем возрасте реально схватить сердечный приступ.
Пришел с работы - чуть с кресла у компа не свалился от такого сообщения, это по самым скромным оценкам фактически пятикратное ускорение строительства путей маршрута, с такими вещами не шутят, однако.
Исправил, - запись в W файл параметров позиции секции 9 знаков, при перезаписи файла (следующем сохранении) устойчиво!
Такой точности стыковки ниток в БД нет ни на одном из просмотренных мной (более сотни) маршрутов.
Как тебе это удалось?
Как может сказаться на других функциях или этот байт отвечает исключительно за округление?
ps я подключал к проблеме двух знакомых программистов, именно программистов, а не сисадминов (сам сисадмин, толку то с этого) - оба не смогли решить проблему, я в шоке, рассказывай скорее как нашел.
add
Выезд путеизмерителя на контрольную секцию - СТЫК НЕ ОПРЕДЕЛЕН! Т.е. его просто нет, ошибка стыковки секции с уклоном 0,135 менее чувствительности моего измерителя, т.е. стыка просто нет!
И это без какой либо коррекции, за 1 минуту - шлеп секцию и получите.
Едрен батон, ВСЕ секции и статика переписаны в W на 6 знаков после запятой :eek:
[впал в ступор, тупо смотрит в W файл и пытается понять КАК?]
Как тебе это удалось?
Помогли люди.
Как может сказаться на других функциях или этот байт отвечает исключительно за округление?
Если я правильно помню, то только за округление. Для всех записываемых чисел с запятой.
Шок прошел, немного потестил, как ни странно, но на стыках тайлов даже такая точность не дает идеальной стыковки, упертая вещь МСТС, но все в допуске, можно пренебречь.
Подожди как для всех цифр? Высоту в позиции и QDirection он так и писал, значит какое-то разделение значений у него все же есть.
Обратную совместимость проверял? Я в смысле как пойдет маршрут на обычном (без правки) exe.
И какие параметры "зацепило"?
ps Хорошие люди тебе помогли, если тест пройдет успешно - за такие вещи нужно памятник ставить, лично для меня это несколько лет свободного времени убитого на коррекцию тупости МСТС.
Подожди как для всех цифр? Высоту в позиции и QDirection он так и писал, значит какое-то разделение значений у него все же есть.
Там для всех чисел с точкой этот атрибут используеться.
Обратную совместимость проверял? Я в смысле как пойдет маршрут на обычном (без правки) exe.
Нет. Ездил на правленом.
И какие параметры "зацепило"?
Надо смотреть по файлам сценария, путей, трафика и сравнивать до и после. Я точно не знаю, но есть такое предположение. Если готовый маршрут переложить то бывает ошибка.
Совсем офф, но пока тема горяча....а какой байт отвечает за количество, имена и командные клавиши анимации деталей типа дверей в ПС? Я уже тут даже тему специальную завел для ответа)
http://www.trainsim.ru/forum/showthread.php?t=4902&page=3
Может уважаемые добрые люди и здесь помогут?:)
lyolik, подложил обратно exe без правки - все Ок, в принципе закономерно, БД не изменяется и симулятор использует траекторию записанную в БД с той точностью как записано, он туда вновь стыкуемые секции и писал достаточно точно, а вот при переборке (когда данные берутся из W) начинался ужас со стыковкой.
Изменять путь проложенный в правленой версии из обычной пробовал - без проблем.
Насчет всех цифр, похоже "досталось" QDirection, раньше записывался до 9 знаков после запятой, теперь до 6 как и Position.
А что если другие значения кроме 66?
add
Очень интересные эксперименты =)), в исходном варианте было % g (67), мы задаем f (66) может это заглавные буквы разрядности? Пробую разные варианты, при d (64) он пишет вообще без запятой до 10 разрядов, при Q (51) выдал во всем файле "Position ( Q Q Q )" :)
По соседним сходным значениям он понимает e, u, d и 0.2 но 0.2 это уже выход за смещение, очень интересно…
% p (70) Position ( 60000000 00000000 A0000000 )
QDirection ( 00000000 40000000 00000000 40000000 ) весело :)
===============
Изрядно погуглив пришел к выводу что мы имеем дело с модификатором точности и кодом формата функции printf (почитать можно тут (http://ru.wikipedia.org/wiki/Printf) и тут (http://c2p.ru/c/printf.html), исходя из этого получается, что приемлемым вариантом будут только коды g и f.
Как я понимаю это коды вывода числа с плавающей точкой и "по умолчанию" число знаков после запятой (точки) как раз равно 6, g это более короткий вариант формата f (Билл скотина!).
Меняя код % g (67) на % f (66) мы указываем функции printf выводить в W файлы числа в "полном формате" f, но по умолчанию он ограничен 6 знаками, что для QDirection вероятно недостаточно, да и нужно стремиться к совместимости со "стандартным" вариантом, там максимум 10 разрядов.
Почитав описание функции решил обнаглеть и попробовать указать число знаков явным образом записав в файл %0.8f выйдя за пределы строки, ожидал ошибки, но как ни странно все работает и я явно "перестарался" ( т.е. симулятору плевать на ".8" ):
TrackObj (
UiD ( 382 )
SectionIdx ( 38110 )
Elevation ( 0.0000019c9c )
CollideFlags ( 535 )
FileName ( A1t2_6mtrConcrete.s )
StaticFlags ( 00200180 )
Position ( 877.4630135478814 17.0998995478814 375.0440065478814 )
QDirection ( 0.0000015478814 0.3445125478814 0.0000015478814 0.9387825478814 )
VDbId ( 4294967294 )
StaticDetailLevel ( 0 )
)
Курим описание функции дальше…
ps могу конечно ошибаться ибо не программист, но ИМХО путь указанный lyolik
правильный, тут совсем нелишней была бы помощь программистов.
Рано я так обрадовался, получается, что мы меняем шило на мыло вот изменения в записи стрелки до правки кода формата вывода в W файл и после:
Elevation ( 0.000916297 )
JNodePosn ( -4973 15341 -734.123 22.4526 -586.943 )
FileName ( A1tPnt7_5dLft.s )
Position ( -734.123 22.4526 -586.943 )
QDirection ( 0.000450976 0.176259 8.07508e-005 0.984344 )
Elevation ( 0.000916 )
JNodePosn ( -4973 15341 -734.122986 22.452600 -586.942993 )
FileName ( A1tPnt7_5dLft.s )
Position ( -734.122986 22.452600 -586.942993 )
QDirection ( 0.000451 0.176259 0.000081 0.984344 )
Elevation - точность возросла
JNodePosn - точность возросла
Position - точность возросла
QDirection - тут все очень спорно, по некоторым значениям точность возросла, по некоторым снизилась в зависимости от разрядности исходника, а с некоторыми происходят странные метаморфозы, например третье значение 8.07508e-005 -> 0.000081 совсем неясно чем это грозит, понятно только что "e-005" какой-то бред, но столь значительное изменение целых с 8 на 0 пугает.
Что еще настораживает - а не пишем ли мы теперь обрезанные до 6 знаков после точки значения в БД? Ведь столь серьезное увеличение точности Position должно было дать практически идеальные стыки ниток в БД, однако, на деле это не совсем так, хотя и в допуске.
Также не очень понятно, почему код формата %e не мешал записывать в параметр QDirection значения вида 0.000450976 при этом обрезая значения в Position строго на шести разрядах независимо от числа знаков после точки, зато %f порезал или дотянул все значения всех параметров до 6 знаков после запятой.
Вероятно то, что писать в Position определяется где-то еще отдельно.
Еще странность варианты типа %.3f, %.8f, %.9f никакого впечатления на MSTS не производят.
Grebnev постараюсь узнать, что можно сделать. Правда я не совсем понял что нужно.
Zabor например третье значение 8.07508e-005 -> 0.000081 совсем неясно чем это грозит, понятно только что "e-005" какой-то бред,
"e-005" это 10 в степени -5. Все правильно там.
Наверное нужно делать с нуля маршрут и сценарии с правленой точностью, а смешивание с обычной точностью дает сбой. Скорее это улучшение только для разработчиков. Готовый продукт править нельзя.
lyolik, совершенно понятно, что для разработчиков, причем озабоченных стыковкой, таких какнапример я, многие на эти ошибки просто не обращают внимания, не говорю, что это плохо, лично сам с ними смириться не могу.
Со значением понятно, а вот почему QDirection пишется без правки с такой точностью как нужно не очень.
Со значением понятно, а вот почему QDirection пишется без правки с такой точностью как нужно не очень.
Может это значение осталось от предыдущего раза? Я заметил, что перезапись идет только частичная. Если не двигать объекты, то они не перезаписываються. Возможно идет перезапись только w файлов на которых было изменение места объекта.
При перезаписи W файла "исправляются" все значения у всех объектов, т.е. во всем файле, перезапись соответственно происходит если сдвинуть любой, даже статический объект.
Прогнал пару км на правленом exe (%f) - субъективно "непроваров" меньше, но они есть все равно, видимо улучшив одно ухудшили другое =((.
Может нужно пересборку маршрута сделать. Возможно "непровар" это когда строили путь из двух точек навстречу и в этой точке уже нельзя застыковать идеально. Длина рельса не позволяет.
Дык я пересборку и делал - подъездной путь, который лежал на отметке старого профиля пересробрал весь на новой высоте, без нудной проверки стыковки после КАЖДОЙ секции, потом поехал, на 1 км 4 "непровара", 2 из которых вне допуска…
Получается единственный путь - декопилировать файл, добавить как полагается %.9f затем компилировать обратно, но это уже задача для программистов, у меня сейчас пока настроение освободить безвозвратно 95 ГБ на диске, надеюсь это временно.
ps большое тебе спасибо за подсказу, в exe много нашел нового, вывод практически всех параметров повязан на printf.
Еще странность варианты типа %.3f, %.8f, %.9f никакого впечатления на MSTS не производят.
У меня работает. Если ставлю тип %.3f то 3 цифры после запятой, типа %.4f то четыре.
Странно, скинь мне exe через обменник ссылкой в личку, может я что-то не так или не той программой делаю?
хорошо, только чуть позже. минут 10
Ок, и заодно если не сложно чиркни чем правишь, возможно мой простой "16Edit" не годится, хотя никогда раньше не подводил :confused: .
Я правлю Hiew. Я сейчас не могу подключиться к своему компьютеру, вышлю чуть позже. У меня патч 1.8
У меня все правит с одной точностью. Сделал 9 знаков, все параетры записывает с точностью 9.
Файл тебе оправил по лс.
lyolik, спасибо, хм, байт в байт как у меня :confused:, с той лишь разницей, что твой exe работает, а у меня ерунду записывает в значения, походу редактор меня подвел, в какой версии Hiew-а правил?
add
Стоп! Редактор тут ни причем, я смотрел на запись %.9f, а надо было дальше глаза сдвинуть :D.
lyolik, ты чего сделал то? В оригинале было:
http://pic.ipicture.ru/uploads/090816/NCrl7GclNZ.jpg
ты сделал так:
http://pic.ipicture.ru/uploads/090816/B83Upz47KJ.jpg
Просто так легко и непринужденно убил следующий параметр %02x тогда твоя запись корректна, но кто полег за это смертью храбрых? :)
Или что теперь МСТС не сможет вывести в виде шестнадцатеричного числа без знака (%x)?
add
Попытался спасти следующий параметр, сократив его до %x с сохранением 20 и 00, - даже при 7 знаках БД опадает при следующем открытии маршрута как озимые.
Похоже сносимый параметр влияет на записи в БД, так можно "доиграться до ручки", игры с точностью QDirection отличной от оригинальной могут для меня кончится тем, что я пролечу как фанера над Парижем мимо Зеленогорска при продолжении маршрута.
Получается слегка не там копаем, этот параметр (код и модификатор точности) влияет на все записи в файлы сразу и безусловно, ИМХО надо поискать как формируются значения QDirection и Position ведь QDirection спокойно проходит с заданной точностью через %e.
По Position нашел пару строк вида %6.2f получается ширина как раз 6 знаков, но .2 не увязывается с тем, что записано в W и тем что можно получить, меняя параметр в указанном тобой смещении, скорее всего это простой вывод в поле окна свойств.
Grebnev, узнавал сказали одним байтом исправить нельзя. Нужно переписыфвать много кода.
Zabor, я не разбираюсь очень в этом, правил как ты написал в предыдущих сообщениях. Параметр %02x затер потому что не влазил нормально %.9f. Надо знать хватает точности 9 или нет. Польза есть или увеличение точности не принесло желаемого результата?
Дык я и говорю - %.9f корректно не влезает, затирание ..%02x… кончается падением БД при следующем открытии маршрута ((.
От просто "f" вместо "g" польза есть, но это не 100% решение т.к. снижается точность в других параметрах (влияет на все записи), возможно и в записях БД, проще говоря выигрыш есть, но неизвестно чем это может кончится, особенно в части совместимости, и руками править секции все равно придется.
Вот если бы переписать файл в части добавления байт для записи %.9f и сохранения %02x полностью это, наверное, решило проблему на 100% т.к. точности в 9 знаков после запятой во всех параметрах наверняка будет достаточно, при условии что %02x сохранится.
Но как это сделать могут подсказать только программисты, при простом добавлении все сместится и наверняка будет каша, это же не исходник, а скомпилированный исполняемый файл...
Попробуй так. Я не проверял, но сказали должно работать.
002930D7: B8 48
002930D8: 6C 6E
003A6E48: 00 20
003A6E4A: 00 25
003A6E4C: 00 2E
003A6E4E: 00 39
003A6E50: 00 66
Уезжаю на пару дней в другой округ. По возможности напишу если будут вопросы.
Grebnev, узнавал сказали одним байтом исправить нельзя. Нужно переписывать много кода.
Конечно, я понимаю это)) А вообще цена вопроса существует какая-то?. Возможно удастся организовать отплату труда программеров.
Алексе́й, какая-то существует конечно, я где-то про это уже писал, надо оговаривать, тут разные варианты:
- вот компилированный файл, он работает, я проверял, что, как и зачем там менялось военная тайна (сам не помню, просил Васю, Петю, что они там делали, не знаю), при замене версии патча улетит в помойку (на другой не повторить), вероятность появления "непровара" ХХ %, совместимость с исходным файлом не проверялась, "на свой страх и риск" и т.д. - это одно.
- исходный код файла заданной версии, перечень внесенных изменений, объяснение причин нарушения точности стыков и методов их ликвидации, проверенный на beta тестировании (у меня) готовый файл, методы внесения описанных изменений в exe другой версии, исправленный код исключает данную ошибку полностью и не затрагивает другие функции симулятора/редактора - это совсем другое.
Конфиденциальность исходников (при требовании программиста и исправленного файла), оплату работы гарантирую, но естественно в разумных пределах, я не рокфеллер =)).
MSTS это всего лишь хобби, о цифрах с четырьмя нолями речь не идет, но за гарантированное устранение тупой ошибки орлов била убивающей практически ежедневно 3-4 часа моего свободного времени я готов заплатить приемлемую сумму, это работа, которая потребует квалификации и времени программиста, она естественно должна оплачиваться.
Да, это все лирика, я согласен.
Кстати у меня непроваров стыков рельсов на ровном месте никогда небыло, а вот с простыми объектами вылезают постоянно т.е. ставишь забор из нескольких частей ровно, после перезапуска части стоят криво. И началось это после сканирования компа антивирем во время работы в редакторе. До этого ненаблюдалось...
На "ровном месте" это без уклонов?
Тут ИМХО скорее всего сказывается особенность МСТС придавать объектам (включая секции пути) истинные размеры после перезагрузки маршрута, например "старая" и только что положенная линейки будут не равны, после перезагрузки маршрута уравняются.
Соответственно выровненные длинные секции забора могут начать "плясать" из-за изменения размеров и "округления" углов разворота после перезагрузки маршрута, это легко проверить, выровняв пару повторно и перезагрузить маршрут, если они снова не "убежали" дело в этом.
Хотя антивирь мог и что-то испортить перехватив запрос МСТС к какому либо файлу.
На "ровном метсте" это при ровном стыковании секций.
А при сканировании объекты (например платформа) даже меняли длину.
Zabor А ты игру переустанавливал ? результатов не принесло ?
Кстати раньше при сканировании ни чего особо старался не запускать, никакие бяки не выскакивали, получается не даром говорят, при сканировании лучше ни чего не открывать )
Слава, даты модификации файлов проверял, но на случай полтергейста устанавливал на второй машине "с нуля" (заодно забэкапил дефотные системные файлы), тестовый маршрут в "нулевой" - тоже самое.
Тут дело не в глюке, а на 80% в моих личных требованиях к пути и точности, которую может MSTS обеспечить, знаю, что это тормозит строительство минимум в пять раз, но такой уж характер - если что-то не устраивает никогда не смирюсь, буду перекладывать и корректировать 10 метров пути хоть 18 раз, но будет так как нужно, тут уж ничего не поделаешь, такой я упертый =)).
Оставшиеся 20% - это откровенные ляпы MSTS в стыковке на краях тайлов, их можно найти практически в любом маршруте, особенно, где есть хорошо сделанный профиль.
:o для меня осталось загадкой, что такое "при ровном стыковании секций".
Zabor
Про "непровары стыков": путь уложен без зазоров между треками, а ПС все ровно бъется, как на зазорах ?
Вот уложеный путь без зазоров - это и есть "ровное стыкование секций" Профиль тут не причем :D
С простыми объектами бывает, но почему пути не сохраняются с необходимой точностью... может уж думаю, не в винде ли дело ? у меня то тоже на одном компе все норм, а на другом сикось-накось... (я про статич. объекты, а с треками никогда такого не видел) %)
Слава, профиль тут как раз еще как причем, чем больше угол стыкуемых секций (неважно подъем или спуск) тем больше вероятность некачественной стыковки и тем больше ошибка при её возникновении.
Не не видел, а не замечал/не обращал внимание это разные вещи.
Zabor как успехи? Есть положительные моменты или еще нет? Я пробовал, но не могу определить есть улучшения или нет. пока балуюсь с прокладкой путей, учу редактор. Что скажут опытные маршрутостроители про повышение точности, с какой точностью лучше строить маршрут?
Не знаю как у Zaborа, у меня результат такой - на опытном маршруте, построеном с модифицированым exe (там где 67 на 66) отказывается работать программа ленты с tch-club.ru
Ленты я не пишу =)), а по непроварам пока тайм-аут, занялся застройкой при стандартном exe, для автодорог, тротуаров и прочей статики точности достаточно.
Пути как перекладывал с ручной коррекцией так и перекладываю т.к. нет времени на изучение всех возможных последствий модификации, МСТС меняет сразу разрядность всех параметров записываемых в W, не только Position, чем это черевато пока непонятно.
Nikk, спасибо заинформацию.
Я тоже не пишу, но в программе реализованы голосовые сообщения САУТ, так что ,думаю, пользуются ею многие
vBulletin® v3.8.12 by vBS, Copyright ©2000-2025, Jelsoft Enterprises Ltd. Перевод: zCarot