XGM Forum
Сайт - Статьи - Проекты - Ресурсы - Блоги

Форуме в режиме ТОЛЬКО ЧТЕНИЕ. Вы можете задать вопросы в Q/A на сайте, либо создать свой проект или ресурс.
Вернуться   XGM Forum > Warcraft> Академия: форум для вопросов> Желтая пресса: обучающие статьи
Ник
Пароль
Войти через VK в один клик
Сайт использует только имя.

 
J
expert
offline
Опыт: 48,447
Активность:
Оптимизация
Рассчитывается на то, что читатель нормально - хорошо владеет триггерами. Данная статья расскажет, как довести свой код до совершенства, отполировать и начистить до блеска.

Начнем с переменных:

Переменные



Типы переменных


Переменные это, если иначе сказать, - ссылки. Типов переменных очень много, даже больше чем стандартных которые находятся в “редакторе переменных” в “редакторе триггеров”. Но основных типов только 6:
  1. Boolean (логическая)
    Переменные принимающие значение Да/Нет
  2. handle (указатель)
    handle это указатель, указывающий на реальный игровой объект, сам по себе объект находиться в переменной не может, и потому при действиях над переменой, мы совершаем действие над объектом, который находится по указателю из этой переменой. У типа “handle” есть много наследников, которые тоже имеют наследников:
    Например: Тип переменой “unit” (указатель на юнита) является наследником типа переменой “widget”, которая в свою очередь является наследником “handle”.
    Т.е. это означается что каждыйunit” является “handle”, но не каждыйhandle” является “unit”.
  3. code (функция)
    В этой переменой может содержаться функция, вроде бы все должно быть понятно, но Только минус этого типа в том что он не может являтся массивом и быть созданым удаленым или измененым во время игры.
  4. string (строка)
    Просто набор символов
  5. integer (целое число)
    Целые числа, могут принимать значение от -2147483647 до 2147483647
  6. real (действительное число)
    Числа с плавующей запятой

Есть типы переменных (не integer'ы), которые тоже могут принимать целое значение, например “unittype”, хотя это переменная не является integer'ом, она ее заменяется для типов юнитов (для удобства) (она равна например ‘A000’, ‘B05O’ и т.д. (в 256 значной системе исчисления))

integer-ы в варе могут быть в 4-ех системах исчисления:
  1. 8-ти значная
    Чтобы указать, что это именно 8-ти значная, перед значением ставят “0”, т.е. “0<значение>
  2. 10-ти значная
    Ну это обычные числа
  3. 16-ти значная
    Чтобы указать, что это именно 16-ти значная, перед значением ставят “0x”, т.е. “0x<значение>
  4. 256-ти значная
    Чтобы указать, что это именно 256-ти значная, значение выделяют одинарными кавычками, т.е. “ <значение>

Когда вы пользовались триггерами, вам было необходимо при математических действиях, чтобы внести в целую переменную реальное число – вам надо было перевести его сначала в целое с помощью определенной триггерной функции в типе “Преобразование”, это все правильно. Т.к. чтобы внести в целое число реальное, надо сначала реальное представить в виде целого. НО:
При внесении в реальную переменную целого числа, его надо было переводить в реальное число, в джазе этого делать необязательно, т.к. по сути это разные типы переменных.. но вар автоматически использует приведение целово к реальному числу, а тратить время, чтобы перевести его в реальное с помощью функции I2R(I) необязательно. А вот при возвращении функцией, какое либо число real/integer приведения не происходит, потому нужно точно указывать тип переменой.

Обнуление


У переменых типа integer, real, boolean есть некая “область видимости”, по выходу из этой области – переменная удаляется. У всех остальных переменных этой “области” нет, а значит, их нужно обнулять вручную
Код:
Set <переменная> = null

Если ее не обнулить, то они останется в памяти компьютера навсегда по протяжению игрового процесса, и тем самым в большом количестве будет вызывать тормоза!

функции


Их виды:
  1. native функции
    Это функции, которые находятся непосредственно в самом движке вара, и не могут быть изменены или добавлены стандартными методами. Они находятся в common.j

  2. BJ функции
    Это функции, которые являются дополнительными и могут быть созданы самим джазером, они состоят из native функции и/или других BJ функций. Они находятся в blizzard.j
native функции не вызывают утечек если ими пользоваться правильно, а вот четверть функций BJ вызывают утечку даже при правильном с ними обращении.
Одна из многих проблем этих функций в том, что в них создаются локальные переменные типа “handle” и не обнуляются в конце, и вызывают лишнее загрязнение памяти (иначе - "утечки"), и именно поэтому большинство джаззеров (включая меня) настроены против BJ. Я всегда пользуюсь native функциями (в 80% случаев), а юзаю BJ - только в том случае, если они не вызывают утечек, и содержат много других используемых функций (потому что иначе пришлось бы один и тот же массив функций писать в большинстве кодов, и это приводило бы к “очень большому коду” и “трудно читаемости”).
Пример таких функций, которые вызывают утечки это практически все BJ функции по изменению multiboard-а - они не только громоздкие (из-за того, что сделаны двойными циклами т.к. рассчитаны на указание в их параметры нуля), но еще вызывают утечку из-за не обнуленной переменой - потому их можно сократить…

К примеру, вот так:


Обычная BJ функция по изменению текста в ячейке multiboard-а:
Код:
function MultiboardSetItemValueBJ takes multiboard mb, integer col, integer row, string val returns nothing
    local integer curRow = 0
    local integer curCol = 0
    local integer numRows = MultiboardGetRowCount(mb)
    local integer numCols = MultiboardGetColumnCount(mb)
    local multiboarditem mbitem = null    //!Эта переменная, при присвоении ей позже значения не обнуляется в конце кода!
    loop
        set curRow = curRow + 1
        exitwhen curRow > numRows
        if (row == 0 or row == curRow) then
            set curCol = 0
            loop
                set curCol = curCol + 1
                exitwhen curCol > numCols
                if (col == 0 or col == curCol) then
                    set mbitem = MultiboardGetItem(mb, curRow - 1, curCol - 1)
                    call MultiboardSetItemValue(mbitem, val)
                    call MultiboardReleaseItem(mbitem)
                endif
            endloop
        endif
    endloop
endfunction

Это то как это можно сократить - жертвуя относительно немногим:
Код:
function MultiboardSetItemValueBJ takes multiboard mb, integer col, integer row, string val returns nothing
    local multiboarditem mbitem = MultiboardGetItem(mb, row - 1, col - 1)
    call MultiboardSetItemValue(mbitem, val)
    call MultiboardReleaseItem(mbitem)
    set mbitem = null
endfunction

И есть еще много BJ функций, которые сами по себе независимо вызывают утечки.

Также все функции требуют время на вызов, чем больше это время тем сильнее будет подтормаживать игра во время их вызова, но правда это время измеряется долями микросекунды, так что в не динамических триггерах это имеет малое значение, ну а вот в динамических...:
Это означает что плохо вызывать функции, которая вызывает другую нужную нам функцию. Например:
Код:
function DestroyEffectBJ takes effect whichEffect returns nothing
    call DestroyEffect(whichEffect)
endfunction

По сути это функция делает то же что и в ней содержащаяся, так какой смысл юзать функцию DestroyEffectBJ? Если можно напрямую воспользоваться DestroyEffect. И это весьма слабый пример, некоторые функции вызывают функции нужные нам только через 2-4 функции:

Например:
Нам нужно создать одного юнита - мы это делаем на триггерах с помощью специальной функции - CreateNUnitsAtLoc:
Код:
function CreateNUnitsAtLoc takes integer count, integer unitId, player whichPlayer, location loc, real face returns group
    call GroupClear(bj_lastCreatedGroup)
    loop
        set count = count - 1
        exitwhen count < 0
        call CreateUnitAtLocSaveLast(whichPlayer, unitId, loc, face)
        call GroupAddUnit(bj_lastCreatedGroup, bj_lastCreatedUnit)
    endloop
    return bj_lastCreatedGroup
endfunction

Обратите внимание, что там все происходит через цикл, в котором используется сама функция создающая юнита, а именно CreateUnitAtLocSaveLast:
Код:
function CreateUnitAtLocSaveLast takes player id, integer unitid, location loc, real face returns unit
    if (unitid == 'ugol') then
        set bj_lastCreatedUnit = CreateBlightedGoldmine(id, GetLocationX(loc), GetLocationY(loc), face)
    else
        set bj_lastCreatedUnit = CreateUnitAtLoc(id, unitid, loc, face)
    endif
    return bj_lastCreatedUnit
endfunction

В ней уже используются if-ы, нормальное создание юнитов уже выполняется с помощью нормальной native функции - CreateUnitAtLoc:
Код:
native CreateUnitAtLoc takes player id, integer unitid, location whichLocation, real face returns unit

И что получается? В триггерах мы пользовались функцией для создания юнита, которая через 2 функции, через цикл, и через if и создавала юнита, а все можно было сделать сразу с помощью одной native функции!


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

Самый простой пример:
Код:
function Func takes nothing returns nothing
    if GetUnitState(GetTriggerUnit(), UNIT_STATE_MANA) < 1000 then
        if GetUnitState(GetTriggerUnit(), UNIT_STATE_MANA) > 500 then
            call SetUnitState(GetTriggerUnit(), UNIT_STATE_LIFE, RMaxBJ(0,GetUnitState(GetTriggerUnit(), UNIT_STATE_LIFE) - 500))
        endif
        if GetUnitState(GetTriggerUnit(), UNIT_STATE_MANA) <= 500 then
            call KillUnit (GetTriggerUnit())
            call TriggerSleepAction (5)
            call RemoveUnit (GetTriggerUnit())
        endif
    endif
endfunction

Эта функция делает GetTriggerUnit() мертвым, если жизней меньше 500, или отнимает 500, если у него жизней больше 500, но меньше 1000

Обратите внимание, как много в ней функций, практически половину из них можно убрать, используя переменные. Вот, что должно получиться:
Код:
function Func takes nothing returns nothing
    local unit u    = GetTriggerUnit()
    local real live = GetUnitState(u, UNIT_STATE_MANA)
    if live < 1000 then
        if live > 500 then
            call SetUnitState(u, UNIT_STATE_LIFE, live - 500)
        endif
        if live <= 500 then
            call KillUnit  (u)
            call TriggerSleepAction (5)
            call RemoveUnit(u)
        endif
    endif
    set u = null
endfunction

Обратите внимание, что мы сократили функции GetTriggerUnit и GetUnitState, и, в общем, количество функций уменьшилось на 8. Да и текст принял вполне читаемый вид (Это тоже имеет довольно важное значение).

Игровые объекты


Мы рассмотрели переменные, и как их обнулять, переменная - это ссылка на определенный игровой объект, но обнуление переменой не значит что и удалится объект по ссылке из переменой, объект нужно удалять отдельно (ДО(!) обнуления переменой) с помощью специальной функции. т.к. иначе после обнуление переменой ссылка на объект потеряется, и его нельзя будет удалить.
К примеру эффекты удаляются с помощью DestroyEffect
Юниты: RemoveUnit
Декорации: RemoveDestructable
Точки: RemoveLocation
Триггеры: DestroyTrigger
Таймеры: DestroyTimer
и т.д.

Правда некоторые объекты не удаляются... т.е. DestroyTrigger не полностью удаляет триггер... перед этим еще нужно удалить все его действия выключить подождать секунду и потом удалить.. и обнулить
Но даже это может не спасти от утечек.. потому между выбором - таймер или периодический триггер - выбирайте таймер.

Например - спел... в нём создается много эффектов, и не удаляются, а это значит, что информация по положению эффекта, по его типу остается в памяти на всегда. Обращаться с локальными переменными между функциями очень трудно, т.к. обязательно нужно следить, чтобы ссылка на этот спецэффект не была потеряна, и чтобы он рано или поздно был удален из игры, тоже касается юнитов (в основном имеется в виду "дами-юниты").
Самая распространенная утечка - это точки, они очень слабо загрязняют память компа, но их так много! что это одна из серьезных утечек. Например, давайте разберем простое периодическое перемещение юнита: на триггерах эта выглядит просто... событие в период 0.04, и в нем движение юнита в какую не было сторону, НО большинство триггерщиков используют в подобных перемещениях полярные координаты - что очень ошибочно, т.к. они вызывают куча утечек, вот к примеру разберем периодический триггер с действием:
Боевая единица - Move unit instantly to ((Position of unit) offset by len towards ang degrees), facing ang degrees
где:
unit - переменная перемещаемого юнита
len - расстояние, на которое будет перемещен юнит
ang - Под каким углом

Этот триггер переведенный в джазз:
Код:
function Trig_go_Actions takes nothing returns nothing
    call SetUnitPositionLocFacingBJ( udg_unit, PolarProjectionBJ(GetUnitLoc(udg_unit), udg_len, udg_ang), udg_ang )
endfunction

//===========================================================================
function InitTrig_go takes nothing returns nothing
    set gg_trg_go = CreateTrigger(  )
    call TriggerRegisterTimerEventPeriodic( gg_trg_go, 0.04 )
    call TriggerAddAction( gg_trg_go, function Trig_go_Actions )
endfunction

давайте обращу внимание на недочеты в этой функции:
  1. TriggerRegisterTimerEventPeriodic
    Код:
    function TriggerRegisterTimerEventPeriodic takes trigger trig, real timeout returns event
        return TriggerRegisterTimerEvent(trig, timeout, true)
    endfunction

    Если вы поняли о чем говорилось раньше... то эту функцию можно сократить другой, которую она использует.

  2. SetUnitPositionLocFacingBJ
    Код:
    function SetUnitPositionLocFacingBJ takes unit whichUnit, location loc, real facing returns nothing
        call SetUnitPositionLoc(whichUnit, loc)
        call SetUnitFacing(whichUnit, facing)
    endfunction

    также можно заменить двумя отдельными функциями - отдельно перемещение, отдельно поворот.

  3. GetUnitLoc
    Код:
    constant native GetUnitLoc takes unit whichUnit returns location

    эта функция создает точку, которая не удаляется.

  4. PolarProjectionBJ
    Код:
    function PolarProjectionBJ takes location source, real dist, real angle returns location
        local real x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD)
        local real y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD)
        return Location(x, y)
    endfunction

    этУ функцию во первых можно раскрыть, во вторых она тоже создает точку которая не удаляется.
это получается 50 не удаленных объектов в секунду. подобный триггер будет слабо как-то влиять на игру... а что если таких триггеров будет 10, и они будут создавать еще больше лишних точек - тогда игра начнет тормозить уже через несколько минут.
Исправим все эти недочеты:
Код:
function Trig_go_Actions takes nothing returns nothing
    local real X = GetUnitX(udg_unit)+Cos(udg_ang*0.0174)*udg_len
    local real Y = GetUnitY(udg_unit)+Sin(udg_ang*0.0174)*udg_len
    call SetUnitPosition(udg_unit, X, Y   )
    call SetUnitFacing  (udg_unit, udg_ang)
endfunction

//===========================================================================
function InitTrig_go takes nothing returns nothing
    set gg_trg_go = CreateTrigger()
    call TriggerRegisterTimerEvent( gg_trg_go, 0.04, true               )
    call TriggerAddAction         ( gg_trg_go, function Trig_go_Actions )
endfunction

Обратите внимание на Cos(udg_ang*0.0174) и тот же Sin, почему так?
а просто BJ функция
Код:
function CosBJ takes real degrees returns real
    return Cos(degrees * bj_DEGTORAD)
endfunction

использует обычные градусы, и умножает на bj_DEGTORAD, чтобы перевести их в радианы, а сама функция Cos уже и находит косинус радиан этого угла, но т.к. bj_DEGTORAD - константа, то можно сразу вместо нее записать численное значение, это ~ 0.0174.
И смотрите: нет ни одной точки, если есть выбор между юзанием точек или ее координат, я выбираю координаты. Для все native функций работающих на точках, есть аналоги работающие на их координатах, например: SetUnitPositionLoc и SetUnitPosition, CreateUnitAtLoc и CreateUnit, и т.д.
И что получилось? код начал работать в два раза быстрее и без утечек.

Любой объект надо обязательно создавать в переменной, если мы будет создавать ее как оператор функции, например, так:
Код:
call SetUnitPositionLoc (udg_unit, GetUnitLoc(udg_unit))

То ссылка на точку GetUnitLoc(udg_unit) затеряется, и мы не сможем указать какой объект надо удалить, потому надо делать все через переменные:
Код:
local location loc = GetUnitLoc(udg_unit)                                
call SetUnitPositionLoc (udg_unit, loc)
call RemoveLocation (loc)
set loc = null

Проверка


Как же проверить, много утечек или нет? Очень просто, каждый игровой объект имеет уникальный номер, его можно получить использую модуль RB, с помощью функции:
Код:
function H2I takes handle h returns integer
return h
return 0
endfunction

Уникальные номера всех создаваемых объектов типов handle выстраиваются по порядку, если какой-то из объектов удаляется, его уникальный номер освобождается, и его место займет следующий созданный объект.

Потому если периодически будет создаваться какой-нибудь объект и на экран будет выводиться его номер, и после объект будет удаляться, то выведенное сообщение на экран было бы равно количеству объектов на карте.

Например, создаем периодический триггер в 0.1 сек., создаем в нем все действия, что было сказано выше:

Создайте триггер под названием "check", удалите все содержимое, и вставьте это:
Код:
function Trig_check_Actions takes nothing returns nothing
    local timer Timer = CreateTimer ()
    local string S = I2S(H2I(Timer))
    call DisplayTextToForce( GetPlayersAll(), S  )
    call DestroyTimer (Timer)
    set S = ""
    set Timer = null
endfunction

На экран будут выводиться цифры... начиная с "миллиона с копейками", значение имеет не величина этого номера, а его то насколько он изменяется в процессе игры...


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

Отредактировано Jon, 10.10.2006 в 13:58.
Старый 06.10.2006, 14:51
FoK_KruGer
<3 Vocal Trance
offline
Опыт: 19,940
Активность:
Цитата:
Cos(udg_ang*0.0174) и тот же Sin,

О_о знакомая вещь ;)
Jon - добавь как можно сократить "Событие" ( когда триггер в код переводишь )
НУ а так - моладэц и т.п.
О_о прочитал 2-й раз --- стало еще понятнее.... щас 3-й...

Отредактировано FoK_KruGer, 06.10.2006 в 16:23.
Старый 06.10.2006, 16:10
Sergey
Старейший
offline
Опыт: 44,363
Активность:
Jon, отличная статья. Поздравляю :).
Старый 06.10.2006, 16:18
Reptai1

offline
Опыт: 2,293
Активность:
Да статья супер... Вот и нашлись ответы на мои вопросы!
Старый 06.10.2006, 17:05
Кет

offline
Опыт: 111,109
Активность:
я не джассер, но Джону всё равно кланяюсь за сие творение...
Старый 06.10.2006, 21:06
exploder
iOS zealot
offline
Опыт: 19,394
Активность:
В следущий раз поменьше катов... они раздражают... Статья хорошая...
Старый 06.10.2006, 21:16
bugmaker
invulnerable
offline
Опыт: 2,282
Активность:
статья отличная. Джон - маладец - так подробно расписал основные недочеты и часто случающиеся ошибки, по вине неаккуратной оптимизации =) и вообще будет полезна многим людям. Ты незря потратил время написав статью ;)
Старый 07.10.2006, 00:21
remal
нечто
offline
Опыт: 2,087
Активность:
гм.... читал по диагонали, но тем не менее не уидел самого главного:
надо трезво оценивать с какими утечками надо бороться, а с какими нет! если у нас пусть даже 50 утечек в одном месте, но это место вызывается 2 раза за игру, то тут даже и заморачиваться не стоит. а вот если у нас переодический триггер с периодом 0.1, то он должен быть идеальным.
ЗЫ: ну и вопросик к статье: где результаты тестов?
Старый 07.10.2006, 07:00
WarCrafter
Покидаю вместе с форумом
offline
Опыт: 28,930
Активность:
Спасибо мне за то. что правил ошибки, опечатки, доводил до более приемлимого вида тэговое оформление статьи :bis:
Старый 07.10.2006, 07:06
J
expert
offline
Опыт: 48,447
Активность:
Sergey пасиба, я сторалсо!:) никто не помогал... даже WarCrafter-ер
Цитата:
Сообщение от exploder
В следущий раз поменьше катов

просто я нелюблю когда больше количество статьи занимют коды.. потому и сунул их в каты

Jon добавил:
WarCrafter лжот:p

Отредактировано WarCrafter, 07.10.2006 в 07:14.
Старый 07.10.2006, 07:08
WarCrafter
Покидаю вместе с форумом
offline
Опыт: 28,930
Активность:
ну я чуть-чуть помог )

WarCrafter добавил:
Цитата:
WarCrafter лжот

WarCrafter жжот ;)
Старый 07.10.2006, 07:15
J
expert
offline
Опыт: 48,447
Активность:
remal, я написал "как?", что касается "где?" - это уже дело читателя, вот я например даже единствено используемый тригер в игре вмегда довожу до совершенства.


Отредактировано Jon, 07.10.2006 в 12:09.
Старый 07.10.2006, 07:39
DioD

offline
Опыт: 45,134
Активность:
CODE тип константа, не может быть массивом создан или удалён в игре.
Еще его можно вернуть как интегер но вот интегер как код вернуть не получиться.
про строку бред
local string S = ""
здесь набора символов нет, но это строка, конечно цеплятся к словам это глупо, но тут это явная ошибка
про реалы и интегеры
.0 != 0
для доказательства используем следующую конструкцию.
constant function ZZ takes integer X returns real
return X
return .0
endfunction
constant function ZZ takes integer X returns real
return X
return 0
endfunction
Так что то что написано в описании статьи будет долго и счастливо вызывать глюки особенно при ретурн баге и кеше.
У всех типов переменных кроме handle есть некая “область видимости”
Сюда относятся строки и код, так как переменные делятся на общие и локальнологические.
локальнологическими могут быть только локальные переменные базового типа INTEGER
так как строка и реал будут сохранены в кеш движка после первого использования навсегда а вернее до появления некоторого количества других строк и реалок они не могут быть локальнологическими.
В качестве доказательства этих строк можете проанализировать метод обработки строк ридсетапом ну или вот такой функцией.
constant function I2SRB takes integer VALUE returns string
return VALUE
return ""
endfunction
0-21 создаются в БЖ 21-до 66584 строки создающиеся уже скриптом вашей карты
скажу прямо это еще не все недочёты по статье, достаточно взять команду
DestroyTrigger(X)
1 Не останавливает триггер
2 Не удаляет действие
3 При вызове функций через вэйты крашит вар
4 При вызове функций после вэйтов всем объектам выдаёт один хэндл
Таким образом перед удаление тригера необходимо удалить все его действия выключить подождать секунду удалить включить и потом обнулить.
Старый 07.10.2006, 09:14
exploder
iOS zealot
offline
Опыт: 19,394
Активность:
DioD, в большинстве случаев происходит приведение integer к real, за исключением случая когда эти типы возвращаются функцией, который ты собственно и привел.
---
Еще я бы посоветовал добавить в статью, пару слов о важности очистки уже не используемых данных в кэш.
Старый 07.10.2006, 10:54
DioD

offline
Опыт: 45,134
Активность:
интересно зачем тогда я привёл доказательства именно эту функцию
Старый 07.10.2006, 10:58
exploder
iOS zealot
offline
Опыт: 19,394
Активность:
Просто вся постановка твоей фразы и этот контр пример, приводила к мысли, что приведение этих типов вообще не происходит...
Старый 07.10.2006, 11:05
dk

offline
Опыт: 60,293
Активность:
Разместил на сайте. +1000ехр
Посмотреть можно тут.
Старый 10.10.2006, 11:23
DioD

offline
Опыт: 45,134
Активность:
поздравляют с отправкой статьи содержащей в себе грубые ошибки что искать придёться долго и счастливо.
даже очень счастливо.
Старый 10.10.2006, 11:50
NETRAT

offline
Опыт: 83,712
Активность:
DioD набор может быть пустым =) вообще, трактовка строки достаточно распространенная...
Если уж быть точным, то строка - это тот же обьект, который хранится в таблице строк, из которой он не может быть удален, то есть чем меньше обьектов типа строка в карте, тем меньше лаги

Статья отправлена в премодерацию, предлагаю все это обмозговать еще раз ...
Старый 10.10.2006, 12:27
J
expert
offline
Опыт: 48,447
Активность:
хоть бы сказали че нетак....:(
все что было сказано выше уже поправлено, если нед то напимните еще раз...:)
Старый 10.10.2006, 12:40

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы можете скачивать файлы

BB-коды Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход



Часовой пояс GMT +3, время: 19:02.