Когда мы компилируем main.scm вместе со всеми миссиями и скриптами, все глобальные переменные получают свой ID (порядковый номер). Часть из них получает ID всегда один и тот же (например, $PLAYER_CHAR компилируется как $2, $PLAYER_ACTOR - $3 и т.п.). Это справедливо для всех глобальных переменных, которые определены в CustomVariables.ini

Этот порядковый номер означает номер ячейки в памяти игры, где хранится значение переменной. Понятное дело, этот номер должен быть уникальным для каждой переменной. Иными словами, каждая переменная должна быть скомпилирована с уникальным ID.

Все остальные переменные компилируются следующих образом. Если имя переменной не найдено в CustomVariables.ini, то она компилируется с номером, который идет следом за наибольшей использованной переменной в скрипте. Звучит сложновато, поэтому пояcню на примере:

Простой скрипт из 2х строк:

$PLAYER_CHAR = 1
$MYVAR = 1
$PLAYER_CHAR компилируется как $2. Значит, переменная $MYVAR, которая не содержится в CustomVariables.ini и имя которой не числовое, будет скомпилирована как $3. (на самом деле там будет не $3, потому что $3 зарезервировано для $PLAYER_ACTOR, поэтому $MYVAR получит первое свободное имя - $4

Другой пример

$PLAYER_CHAR = 1
$MYVAR = 1
$100 = 1
Наибольшая переменная в скрипте теперь $100, поэтому $MYVAR станет $101.

Такой механизм позволяет присвоить каждой переменной свое уникальное имя.

В main.scm все новые переменные получают имена при компиляции начиная с $10948, т.к. $10947 наибольшая переменная, использованная в оригинальном main.scm.

Теперь вернемся к CLEO-скриптам. Каждый раз, когда мы компилируем новый скрипт, компилятор не знает ничегошеньки про состояние main.scm и сколько переменных в нем использовалось. Он именует переменные с нуля каждый раз. Это значит, что если ты сделаешь два скрипта, в которых будет:

в одном скрипте

$MYVAR = 1
в другом скрипте

$MYVAR1 = 1
то обе переменные будут скомпилированы как:

$4 = 1
несмотря на то, что имена у них разные. И каждый раз компилятор будет в новом клео-скрипте именовать переменные, начиная с $4. Эффект, думаю, ясен. Переменные будут использовать одну и ту же ячейку памяти и менять значения друг друга. Если ты в одном скрипте запишешь актера в $MYVAR, а в другом в $MYVAR1 = 0, то когда первый скрипт обратится к $MYVAR, он прочитает не актера, а 0, т.к. обе переменные используют 4-ю ячейку памяти.

Другая ситуация - это выход за пределы памяти для глобальных переменных. Например, обычный stripped имеет размер памяти для глобальных переменных в 409 ячеек, поскольку наибольшая использованная переменная $ONMISSION это $409. Предположим, мы создали клео-скрипт:

$ONMISSION = 1
$MYVAR = 0
Как будет скомпилирована переменная $MYVAR, если вы поняли, о чем я говорил выше ? Правильный ответ $411. $ONMISSION это $409, поэтому переменная должна бы стать $410, но этот ID уже зарезервирован для $Help_SprayCan_Shown (см. CustomVariables.ini). Поэтому первый свободный номер это $411.

Вернемся теперь к stripped. Размер памяти-то у него так и остался - 409 (если бы $MYVAR = 0 компилировалась в майне, то память была бы увеличена до 411). Поэтому когда клео-скрипт будет работать с переменной $MYVAR, ее значения будут читаться и писаться за пределами дозволенной области памяти. В худшем случае, такие переменные будут менять код самого main.scm (опкоды и параметры), что неминуемо повлечет вылет.

Лос сантос:

If
0154: actor $PLAYER_ACTOR in_zone 'LA'
jf @SUR_11
1@ = 1536.256
2@ = -1672.488
3@ = 13.3828 (1-3 координаты для машины. Она туда будет подъезжать)
4@ = 1554.95
5@ = -1674.99
6@ = 15.3283 (4-6 координаты маркера для входа в участок. На него будет телепортация, чтобы копы нужного города в участке прогрузились)
8@ = 264.427 //(angle 270.0)
9@ = 77.4922 //(angle 270.0)
10@ = 1001.12 //(angle 270.0) (8-10 координаты камеры, в которой перс будет сидеть)
12@ = 1553.0872 //(angle 90.0)
13@ = -1675.318 //(angle 90.0)
14@ = 16.1953 //(angle 90.0) (12-14 координаты крыльца, на котором перс появляется)
16@ = 280
17@ = 596 (16-17 модели машины и копа. Зависит от местности)
18@ = 253.5915 //(angle 180.0)
19@ = 66.7442 //(angle 180.0)
20@ = 1003.6406 //(angle 180.0) (18-20 координаты СJ в участке. После освобождения из камеры сцена уплаты штрафа)
24@ = 253.3826 //(angle 0.0)
25@ = 65.6527 //(angle 0.0)
26@ = 1003.6406 //(angle 0.0) (24-26 координаты копа)
jump @SUR_30

0154: actor $PLAYER_ACTOR in_zone 'VE'
jf @SUR_10
1@ = 2306.533
2@ = 2435.295
3@ = 10.8203
4@ = 2337.0686
5@ = 2459.2703
6@ = 14.9687
8@ = 197.7129 //(angle 0.0)
9@ = 174.6622 //(angle 0.0)
10@ = 1003.0234 //(angle 0.0)
12@ = 2337.1001 //(angle 130.0)
13@ = 2455.95 //(angle 130.0)
14@ = 14.9687 //(angle 130.0)
16@ = 282
17@ = 598
18@ = 211.9096 //(angle 90.0)
19@ = 147.0739 //(angle 90.0)
20@ = 1003.0234 //(angle 90.0)
24@ = 210.7464 //(angle 270.0)
25@ = 147.3265 //(angle 270.0)
26@ = 1003.0234 //(angle 270.0)
jump @SUR_30

Остальные координаты долго искать, они у меня по трём предалфоверсиям раскинуты х))
Да и мне не надо с координатами. С командой gosub там хоть 1@, 2@, 3@ можно весь скрипт гонять для разных целей. А вот именно как переход организовать?

Был у меня макетик:
:XЗ
wait 0
20@ = Player.WantedLevel(...)
If
20 < 4
jf @Переходим на "20 > 3"
jump @XЗ+1

:XЗ+1
wait 0
If or
0154: not actor $PLAYER_ACTOR in_zone 'LA'
0154: not actor $PLAYER_ACTOR in_zone 'SF'
0154: not actor $PLAYER_ACTOR in_zone 'VE'
jf @Переходим на несельскую местность
jump @Идём на задание координат для колхоза. Но тут надо будет ещё как то замутить проверку, находится ли перс в зоне "Туманный округ" Ибо если он в колхозе вегаса, автоматически просто не доедет. Надо телепортировать. Пропускаем координаты

:XЗ+n
wait 0
If
20 > 3
И тут снова проверка на нахождение в городах, или в деревне, в сан фиеро ли, или в двух других. В общем муторно. И не факт, что сработает. Я просто хотел узнать, можно ли как нибудь сделать покороче