Ок, и заодно если не сложно чиркни чем правишь, возможно мой простой "16Edit" не годится, хотя никогда раньше не подводил :confused: .

Я правлю Hiew. Я сейчас не могу подключиться к своему компьютеру, вышлю чуть позже. У меня патч 1.8

У меня все правит с одной точностью. Сделал 9 знаков, все параетры записывает с точностью 9.
Файл тебе оправил по лс.

[B]lyolik[/B], спасибо, хм, байт в байт как у меня :confused:, с той лишь разницей, что твой exe работает, а у меня ерунду записывает в значения, походу редактор меня подвел, в какой версии Hiew-а правил?

add
Стоп! Редактор тут ни причем, я смотрел на запись %.9f, а надо было дальше глаза сдвинуть :D.

[B]lyolik[/B], ты чего сделал то? В оригинале было:
[IMG]http://pic.ipicture.ru/uploads/090816/NCrl7GclNZ.jpg[/IMG]

ты сделал так:
[IMG]http://pic.ipicture.ru/uploads/090816/B83Upz47KJ.jpg[/IMG]

Просто так легко и непринужденно убил следующий параметр %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

Уезжаю на пару дней в другой округ. По возможности напишу если будут вопросы.

Ок, пошло в тест...

[QUOTE=lyolik;106794]Grebnev, узнавал сказали одним байтом исправить нельзя. Нужно переписывать много кода.

[/QUOTE]

Конечно, я понимаю это)) А вообще цена вопроса существует какая-то?. Возможно удастся организовать отплату труда программеров.

Алексе́й, какая-то существует конечно, я где-то про это уже писал, надо оговаривать, тут разные варианты:

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

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

Конфиденциальность исходников (при требовании программиста и исправленного файла), оплату работы гарантирую, но естественно в разумных пределах, я не рокфеллер =)).

MSTS это всего лишь хобби, о цифрах с четырьмя нолями речь не идет, но за гарантированное устранение тупой ошибки орлов била убивающей практически ежедневно 3-4 часа моего свободного времени я готов заплатить приемлемую сумму, это работа, которая потребует квалификации и времени программиста, она естественно должна оплачиваться.

Да, это все лирика, я согласен.

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

На "ровном месте" это без уклонов?

Тут ИМХО скорее всего сказывается особенность МСТС придавать объектам (включая секции пути) истинные размеры после перезагрузки маршрута, например "старая" и только что положенная линейки будут не равны, после перезагрузки маршрута уравняются.

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

Хотя антивирь мог и что-то испортить перехватив запрос МСТС к какому либо файлу.

На "ровном метсте" это при ровном стыковании секций.
А при сканировании объекты (например платформа) даже меняли длину.
[B]Zabor[/B] А ты игру переустанавливал ? результатов не принесло ?
Кстати раньше при сканировании ни чего особо старался не запускать, никакие бяки не выскакивали, получается не даром говорят, при сканировании лучше ни чего не открывать )

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

Тут дело не в глюке, а на 80% в моих личных требованиях к пути и точности, которую может MSTS обеспечить, знаю, что это тормозит строительство минимум в пять раз, но такой уж характер - если что-то не устраивает никогда не смирюсь, буду перекладывать и корректировать 10 метров пути хоть 18 раз, но будет так как нужно, тут уж ничего не поделаешь, такой я упертый =)).

Оставшиеся 20% - это откровенные ляпы MSTS в стыковке на краях тайлов, их можно найти практически в любом маршруте, особенно, где есть хорошо сделанный профиль.

:o для меня осталось загадкой, что такое "при ровном стыковании секций".