George писал(а):Учитывая, что GRF8, объясни, откуда вообще может требоваться смена ID?
Обещанное по поводу сдвига ID.
У меня в NML не фигурируют конкретные ID. Я использую дружественные имена типа _3es5k или ammendorf_k_k. Конкретные ID NML подставляет сама, и делает это в порядке объявления блоков item (). Для меня важно, что она это делает именно в порядке объявления и последовательно, конкретные значения по барабану. Тем более, что openttd при вкл. динамическом пуле должна подстраивать ID разных наборов, обеспечивая их совместное использование в игре.
Исходники представляют собой набор файлов по принципу один ПС - один файл. Но некоторые элементы, обладающие логической общностью, объявлены в одном файле. Например, вагоны-болванчики dummy, которые невидимы и цепляются ко всему ПС размером 9-16. Есть ещё отладочные параллелепипеды align car. Есть ещё группа unit, используемая для тендеров и всяких хитрых многовагонных сочленёнок типа рефрижераторной секции, emu/dmu и др.
Исторически в начале объявлены условно "служебные" элементы: dummy, затем unit, затем align car, затем идёт ПС.
В секции dummy было объявлено 7 элементов, размером от 1 до 7. Восьмой я увы упустил.
Естественно, я его добавил в тот же файл, где были 7 dummy, поэтому ID сдвинулись вниз на 1.
Кроме этого, рефсекцию я реализовал 2-мя способами, когда-то об этом писал и предлагал оценить обе. Выбрал один вариант, но поскольку к тому времени были запрограммированы ещё ПС, и все последовательно, чтобы не ломать совместимость, я эту "вторую" рефсекцию не удалил, а перевёл в группу отладочного транспорта, который просто скрывается от игрока по флажку в настройках. Рефсекция была сделана 3-мя элементами. Соотвественно, при её удалении элементы, объявленные после неё, сдвинулись вверх на 3 позиции.
Однако, я бы хотел, чтобы сдвиг ID в наборе не воспринимался как некий ахтунг, и шопипец.
Набор в альфа-состоянии, в нём может изменится всё и вся. Например, скорее всего придётся пересмотреть модель больших вагонов и перейти на "тройки". Если, конечно, разработчики не сделают чего-то революционного, типа поддержки процедур или возможность получать ID и др. переменные соседей. Но на Б-га надейся, а сам не плошай.
Сдвиги и перемещения ID обязательно будут происходить. Однако, я постараюсь, чтобы эти действия производились как можно реже.
Тому есть 2 серьёзные причины. Обязательности, не редкости.
1. Исходники предназначены для чтения и понимания, поэтому там всё д.б. просто, понятно и красиво. Dummy-болванчики д.б. объявлены в одном файле. И если понадобятся ещё болванчики - буду двигать ещё. Если будет выкидываться транспорт из набора - тоже буду двигать. Будет рефакторинг исходников с целью их лучшего восприятия или реализации алгоритмов - буду двигать.
2. Выше я сказал, что ID назначаются NML по порядку объявления. Что же произойдёт, если объявление будет таким: d1, d2, .., d6, d7, u1, u2, .., _2es5k, d8. Казалось бы, мы объявляем всё новое в конце, ID двигать не надо. Предположим, что мы игнорируем п.1 выше, и хотим запутать себе исходники, и нам наплевать, что никто в них не разберётся без пол-литра, даже я сам.
Объявляя группы ПС блоками я решаю задачу сравнения. Чтобы определить, что у нас любой болванчик (от 1 до
, мне достаточно двух (!) сравнений. Чтобы анализируемый элемент был >= минимального d1 и <= максимального d8. Но если я их объявлю не блоком, а где Б-г на душу положит, то мне придётся произвести N сравнений. Хорошо, если болванчиков 2. А если 8? Подпрограмм нет, все функции приходится "разворачивать" в одно ветвистое дерево. Макросы хоть и помогают, но они не могут заменить п/п.
Если кто думает, что болванчики - фигня, то я с такими солидарен.
Но возьмём желаемую функцию про отопление. Если мы объявим блок вагонов с отоплением типа А и потом захотим при присоединении таких вагонов к локомотивам с таким отоплением делать одни действия, а без него - другие, то как мы их различим? Если они будут объявлены блоком, то за 2 сравнения. А если как зря? Понимаете, о чём я? А у нас есть электровозы такого тока, другого тока, вагоны такие-сякие, и объявляются и появляются в наборе они по мере рисования, по готовности.
А у нас не одни отопления задуманы. Как только задумка выливается в использования функции выпуска состава из депо или присоединения элемента к составу -- сразу возникает вопрос, сколько сравнений придётся произвести. И это количество должно быть конечным и достижимым. Даже с п/п это будет непросто, а сейчас - совсем тяжко.
Объявления логических групп ПС непрерывными блоками облегчает программирование и снижает нагрузку на игру, когда она будет вызывать все эти деревья функций в реальной игре из кучи ПС. Но зарезервировать позции на все случаи жизни мы не можем. Что это будет за набор, захавывающий под себя любимого 1000 ID, из которых "живых" будет 100 или 150?
Поэтому мы будем добавлять новый ПС в конец, а потом по мере необходимости переупорядочивать его в блоки. И это будет не один раз. Таков процесс разработки. Не вижу в этом никакой трагедии. Неудобство вижу. Думаете, я не бросил несколько игр и не начал заново тестируя ту или иную функцию?
Есть просьба к читающим: посодействуйте разработчикам, чтобы они сделали те же подпрограммы на NML. Это реально поможет разработке. Я пока, увы, питоном владею мало-мало. Внутри NML активно использует п/п, надо только выставить "наружу" этот функционал.