1)

Очень сильно нагружает циклы даже если проверять с фиксированым значением.
Избегайте наличия нескольких "exitwhen" внутри сложных конструкций, вы рискуете убить поток.
2)

Каждое целое число может быть числом с плавающей точкой, но не наоборот.
Внутри функций цисло с плавающей точкой обязательно должно иметь точку, или вы получите несовпадение типов.
3)

Невозможно обнулить, эти значения обрабатываются автоматически.
4)

Могут иметь значение "null" для boolean это равносильно false, а для строки "(null)".

Использование строки null приводит к вертолёту, но всё же вы можете вывести это значение функциями вывода текста.
5)

Можно вернуть постредством РБ как интегер, и наоборот, тут для строки можно добится еще одного значения "Вертолёт" обращение к строке которой несуществует посредством РБ крашит вар, это хорошо видно при загрузке игры в которой задействован этот метод.

DeT добавил:
пачиму так?
подробнее плиз

DioD строка разве не (null)

ммм... а можно вопрос поразвёрнутей?

Гут, добавил бы что integer, real, string надо инициализировать перед действиями вида set i = i + 1
(local real r = 0, local integer i = 0, local string s = ""(особенно при работе со строками))
Не помню, надо ли инициализировать boolean перед действием типа set b = not b

делал 100 раз, и в сложных консрукциях... почемуто никаких дефектов незамечал...

DioD чет я заметил усмешку в твоем голосе... почему? в основном - в спелах. спелы не покажу...

просто запущенный цикл с изменением целого и вывода(BJDebugMsg'om) его выполнился у меня 808 раз,с exitwhen i == 1000000 796 помоему,в то время как изменение значения set i = i + 1(без BJDebugMsg) и exitwhen'om срабатывал 23074,тоесть при exitwhen i == 23074(при exitwhen i == 100000 i было равно 23076,а без exitwhen'a 42857),на 1 больше и цикл не завершается, тоесть убивание потока происходит и без exitwhen'a, но он тоже влияет, тоесть максимальное количество циклов напрямую зависит от количества функций и exitwhen'ов. Кстати при затухании цикла и его невыполнении цикл не заканчиваетс и все функции после него не выполняются.

p01nTT добавил:
далее: проверка цикла с 2мя переменными показала: без exitwhena: 23077 и 23076,с 15789 и 15789,с 2мя exitwhen'ами: 12000 и 12000,с нативкой CreateTrigger() без exitwhen'a - 21429 и 21428,
с BJDebugMsg("a") и без exitwhena - 810 раз, тоесть BJ функции нагружают цикл в 100ни раз больше чем exitwhen, но exitwhen нагружает больше чем нативки раза в 1.5-2,то есть нельзя сказать что exitwhen сильно нагружает цикл

p01nTT вообщем как я и говорил... но нативки нагружают поток поразному, одни больше други меньше, такчто судить о том что чтото нативки быстрее/медленее exitwhen врятли можно

Jon ну это да, но всё таки если сравнивать BJ нативки и exitwhen, то exitwhen ~ native << BJ
следовательно exitwhen не особо сильно нагружает поток

да это известно кроме того что буль может быть нуль ?! мне кажетьса это ничего хорошего... это относительно...

Сильно повторяемые строчки кода грузят поток пропорционально сумме времени на вызов всех функций внутри них. exitwhen выполняется всегда при каждом проходе цикла и функционально эквивалентен if.

Поэтому тормоза в случае сильно тяжелых потоков и функций можно уменьшить, переделав сложное условие в nested if