Quote:feanor, ты прав насчёт конечных размеров структур. У меня вертится идея добавить аналог RedirectMemoryBlock, но с NewSize последним параметром. Сейчас лимиты монстров/героев я получаю по способу HD-мода: считываю значение из какого-нибудь воговского цикла. Если бы был четвёртый параметр, можно было бы писать функции а-ля GetTownLimit => GetStructSize(addr) / SINGLE_ITEM_SIZE.

Не решает проблему с новой частью таблицы.

Какой бы не очень надуманный пример придумать..
Вот у нас есть, допустим, код для изменения стрелков в башнях. Там как раз таблица, 36 двордов на девять городов.
Есть использующий его скрипт, который в начале боя берет номер осаждаемого города, и допустим, берет-изменяет какие-то данные в этой таблице. Например, заменяет стрелков в зависимости от его отстройки.
Все довольны, все работает, Солмир строит Капитолий и получает косметических титанов в башнях.

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

Теоретически мы можем зарегистрировать редирект с избытком, захватив область памяти за верхним краем. Тогда UN:C по таблице стрелков десятого города будет отрабатывать правильно.
Но это концептуально неправильно, и, что важнее, как минимум (тут уже пошли теоретические вымышленные примеры, надо смотреть) способно грозить проблемами. Не дай бог у нас таблица стрелков упирается во что-то нужное другому скрипту, например, там какая-то другая таблица, или просто какие-то системные данные. Тогда у нас уже другой скрипт будет сходить с ума, причем, в отличие от чистого случая, на отладке вполне можно будет свихнуться.