вместе с пожеланиями пишем предложения по реализации.
флуд и общие фразы наказуемы :), предварительное чтение кода приветствуется. если есть сомнения как та или эта штука работает задаем вопросы и возможно получаем ответы.... собственно, для того топ и поставлен.
пффф... потому что так проще и красивее. ) тут упрощать-то нечего! фи... что значит - как?! он и сейчас узнаёт, что перед ним кирпич. а с вэйпоинтами ещё лучше будет узнавать. потому что наметит путь и сразу сосчитает, есть ли на этом пути кирпичи, и посему может узнать это не только вообще, но и заранее. =) а объёмы вычислений - представляю прекрасно. практически такие же, как были. ) единичка-нулик. или есть точка кирпича, или нету. вот только не надо говорить, что процессор не выдержит такого количества вычислений. ) тысячу точечек обработает и не почешется. движок выдерживает и гораздо больше частиц, со своими спецэффектами, скинами, уронами, углами, скоростями и кучкой совсем не имеющих значения, но имеющих количество факторов. а здесь и вычислять в принципе нечего. по поводу вэйпоинтов. ИМХО ты чего-то глючишь. =) чтобы вэйпоинты не влияли на тактику - это вообще что-то невообразимое. =) потому что для любого командного режима, ботам надо будет оценить, во-первых, все возможные пути, а это уже проблематично: на практике бот нифига не определит оптимальные варианты. как минимум потому, что человеческие издевательства над строгостью тактики бот не поймёт никогда. если собственно человек не будет его, бота, учить ездить по карте. а во-вторых, вэи могут в себя включать абсолютно всё. проходимые/непроходимые места, места, где лучше не ездить, где можно покемперить, куда лучше заныкаться с таким-то оружием, и вообще, где примерно находится цель битвы (т.е. сам по себе бот пути к флагу или ещё какой цели не найдёт. во всяком случае, оптимального пути. а если и найдёт - это значит, что человеку останется взять пушку, встать в нычок и отстреливать ботов, едущих к цели, одного за другим ^_^). они, вэи, должны включать в себя всю тактику и стратегию вообще.
поведение. имею ввиду форсмажорные обстоятельства. =) когда надо стрелять в кого-нибудь, уворачиваться, или иметь какую-нибудь загвоздку относительно цели битвы (например, если неподалёку от бота брошеный флаг валяется).
угу.
с маской. и? =) ну, для начала допустим, что код всё же будет оптимизирован, и простого теста для каждой точки, не пересеклась ли она с какой-нибудь изо всех остальных, не будет. =) это всё равно что сейчас для каждой точки танка в каждый тик времени проверять, например, не ударился ли об неё диск риппера. =) а во-вторых, не такие уж и большие нагрузки... в конце концов, нынешний квадратик вполне свободно обрабатывается, и коллизии имеются. допустим даже, что четыре стононы квадратика гооораздо лучше, чем десять сторон чуточку видоизменённого контура. чтобы обрабатывались не точки, а линии, и не десять, а четыре линии. тогда мы имеем вариант делать ислкючительно прямоугольные маски - только ширина и длина. вариант вроде как самый-самый оптимальный, лишних затрат никаких. =) и это имеющийся минимум. максимум - полная попиксельная система, и пофиг: к тому времени, как начнётся реализация всей этой канители, процессоры в четыре раза круче нынешних будут...
пересечение линий, да. именно поэтому затраты на расчёт будут в среднем в десять раз меньше перточечных. =) не думаю, что десяток лишних граней контура затормозят игру по самое это самое.
он и сейчас узнаёт, что перед ним кирпич. а с вэйпоинтами ещё лучше будет узнавать. потому что наметит путь и сразу сосчитает, есть ли на этом пути кирпичи, и посему может узнать это не только вообще, но и заранее (.....)
я не говорю что это невозможно сделать. я говорю что только на определение помех на пути будет затрачено адское количество времени -- для определения стоит объект на пути или нет, придется перебирать все объекты. разница чувствуется?
цитата:
для любого командного режима, ботам надо будет оценить, во-первых, все возможные пути, а это уже проблематично: на практике бот нифига не определит оптимальные варианты
это все учтено. я имею ввиду оценку путей -- да, именно на этой оценке тактика и строится, и вот тут-то как раз проблемы нет. классы вейпойнтов и функция нахождения пути до ближайшей контрольной точки уже написаны, и по идее работать должны на ура.
цитата:
вэи могут в себя включать абсолютно всё. проходимые/непроходимые места, места, где лучше не ездить, где можно покемперить, куда лучше заныкаться с таким-то оружием, и вообще, где примерно находится цель битвы (т.е. сам по себе бот пути к флагу или ещё какой цели не найдёт. во всяком случае, оптимального пути.
эти задачи по идее стоят не перед вэями, а перед функцией которая и поле и вэи обрабатывает. инс предлагал к вэям прицепить еще приоритетность, но усли учесть мобильность контрольных точек на карте это теряет смысл.
цитата:
взять пушку, встать в нычок и отстреливать ботов, едущих к цели
с этим отдельно разбиратсья надо. что делать пока не знаю, можно так -- при смерти бота искать ближайший к точке смерти вейпойнт (или пару-тройку вп) и немного увеличивать его (их) непроходимость. если убивают часто - со временем путь выбирается другой. если путь единственный, то тут уж ничего сделать нельзя; разве что в CTF/доминации еще проверку на выгодность атаки/защиты проводить, -- типа что выгодней идти до базы или держать оборону. вообще вопрос интересный, честно говоря еще не думал.
цитата:
вэи, должны включать в себя всю тактику и стратегию вообще
..... все широкие обобщения ошибочны, включая и данное утверждение (с) :)
цитата:
поведение. имею ввиду форсмажорные обстоятельства. =) когда надо стрелять в кого-нибудь, уворачиваться, или иметь какую-нибудь загвоздку относительно цели битвы (например, если неподалёку от бота брошеный флаг валяется).
не очень понял..... цель битвы (соответственно цель пути) и есть флаг (точка). стрелять -- да, независимость от пути движения вводить надо, то есть преследование убрать.
цитата:
ну, для начала допустим.....
дальше не понял возражаешь ты или нет :)) да, можно работать с маской только когда контуры пересекаются, то есть не всегда, -- но зачем? с набором линий гораздо проще, даже если их не 4 а больше будет.
Сегодня отправил Инсу модель новой пушки с изображением, пулей и характеристиками. Это снайперская пушка. Скорость снаряда выше гаусса. Три выстрела залпом и 2.5 секунды на перезарядку. Бетон не пробивает, зато пробивает навылет кирпичь. Вообщем, снайперское оружие.
ЗЫ. Инс, забыл в письме указать, что взрыв пули такой же как у тяжёлой пушки. И след за ней тоже.
> я не говорю что это невозможно сделать. я говорю что только на определение помех на пути будет затрачено адское количество времени -- для определения стоит объект на пути или нет, придется перебирать все объекты. разница чувствуется? ну ты блин даёшь. ) все объекты... изверг. ну, для начала уточню, что вэи как в, например, CS - нафиг не нужны, потому что глючны. гораздо удобней сделать зональное распределение: то есть, иметь виды зон, типа, где кемперить, где ходить, где стоять, где лучше всего ездить, какой путь к цели основной, какой побочный, и так далее. чем умнее будут боты, тем больше можно придумать вариантов. и потом достаточно взять зональную "кисть" и разрисовывать карту. оптимальнейший вариант. а для определения, есть ли объект, не надо никого перебирать. ) бот ведь в любом случае будет, как и сейчас, смотреть, куда едет, покудова едет, и каким образом он дотуда доедет. сейчас он определяет всё безо всяких проблем. а с вэями ему будет ещё проще: не надо проверять, есть ли где бетонные или водные препятствия, стоит ли "туда" ехать (ну, например, сейчас бот едет за бустером, а тут бустера спёрли. а с вэями у него путь однозначен.) уже когда он просчитывает путь - а в данном случае ему, опять же, будет ещё проще, нежели сейчас - каждое место, где он едет, будет просчитано на предмет препятствий. тьфу, да какое там "просчитано"... просто или единичка, или нулик - или кирпич есть, или его нету. всё. никаких нагрузок это не вызовет однозначно, потому что сейчас бот ещё и успевает пермоментно определять, если ли в округе враги, не спёрли ли бустер/аптечку/оружие, за которым он ехал, и так далее. вот считай, по своей логике, что бот каждый момент времени просматривает все точки на карте и просчитывает, есть ли на какой-нибудь из них вражеский танк (именно все: он ведь определяет не только тех, кто в зоне видимости, но и тех, кого надо замочить). сравни затраты. =)
> я имею ввиду оценку путей -- да, именно на этой оценке тактика и строится, и вот тут-то как раз проблемы нет. ну вот о чём я и. потому что искусственный интеллект в принципе не способен будет определить, где именно встанет кемпер рода людского и откуда он будет кемперить. и научить бота определять это в каждой карте тем более не получится. механизм самообучения - ещё муторней, но даже если такой и будет, то на первых порах бот будет тупить, тупить и ещё раз тупить. потом поймёт, что тупит. и станет поворачивать в другое место. туда засядет кемпер, и бот снова будет раз за разом тупить. пока не переберёт всевозможные варианты. бота всё равно будут мочить люди. во всяком случае, если они не ламеры. иначе бот может вообще рандомно ездить. а так - бот не определит, где у него было больше шансов. а вэи позволят учить бота напрямую. чтобы бот сразу был обучен вэйпоинтером и знал, где его будут мочить в сортире, а где мочить будет он сам. в любом случае лучше этим будет заниматься сам человек. ну, на самый крайний случай - можно оставить старый ИИ, который будет инициализироваться каждый раз, когда вэев на карте не будет. =)
> эти задачи по идее стоят не перед вэями, а перед функцией которая и поле и вэи обрабатывает. ну, это разумеется. а о классификации вэев я уже говорил...
> с этим отдельно разбиратсья надо. что делать пока не знаю, можно так -- при смерти бота искать ближайший к точке смерти вейпойнт (или пару-тройку вп) и немного увеличивать его (их) непроходимость. если убивают часто - со временем путь выбирается другой. если путь единственный, то тут уж ничего сделать нельзя; разве что в CTF/доминации еще проверку на выгодность атаки/защиты проводить, -- типа что выгодней идти до базы или держать оборону. вообще вопрос интересный, честно говоря еще не думал. ну вот, подумай... мож, чего-нибудь придумаешь. ) я вижу лишь один доминирующий вариант - ручное обучение, т.е. эти самые вэи. иначе - это и писать гораздо труднее будет, и эффективность всё равно особо не повысится. ну, выберет бот другой путь. на второй раз, когда он туда поедет, его уже будет ждать всё тот же кемпер. =) и всё повторится лишь с той разницей, что старый путь был всё-таки получше. а пути, где бота никто не будет поджидать, он не найдёт. кемпер - он хоть прямо на флаг усядется, а бота будет отстреливать.
> ..... все широкие обобщения ошибочны, включая и данное утверждение (с) :) во-во.
> не очень понял..... цель битвы (соответственно цель пути) и есть флаг (точка). есть цель битвы - флаг какой-нибудь, штаб, контрольная точка или ещё какая-нибудь бурда. есть цель пути - это может быть как цель битвы, так и что-нибудь ещё: бустер, аптечка, оружие, или враг, которого ну очень хочется застрелить. и есть вэйпоинт: и такой, по которому бот будет ходить, и такой, который бы мог служить целью пути (important-точка, кемперская точка, и т.д.). в нём, в вэйпоинте, я смысла не вижу, так как зональное распределение лучше.
> да, можно работать с маской только когда контуры пересекаются, то есть не всегда, -- но зачем? с набором линий гораздо проще, даже если их не 4 а больше будет. для точности. ) нет, разумеется, проще. но здешний поворотный движок замечательно поддерживает возможность перереализации маски в линии... ну, квадрат, ну прямоугольник, ну, митра... о чём я и говорю - в виде линий также можно обрабатывать... можно даже не возиться с преобразованиями: просто считать попиксельную маску и разобрать её по полосочкам. а можно вообще с попиксельной маской не возиться. например: делаем монохромный рисунок, в котором один цвет фоновый, а другим - отмечены лишь несколько точек. которые будут являться углами. между ними - линии. всё. =) в такой ситуации можно и цельный рисунок вернуть, если очень сложная фигура, и уголки оставить, если система перегрузится от их количества. если. в чём я лично сильно сомневаюсь. )
не по порядку. сейчас бот не просматривает все точки на карте определяя своих врагов.
я сильно недопонимаю как у тебя объекты хранится будут. объясни мне как ты будешь хранить объект "кирпич" (точнее кирпичный многоугольник -- если ты хочешь делать поле не клеточным) и как ты собираешься по точке на карте узнавать кирпич это или нет. ты что собрался попиксельную карту держать?
и вообще, честно говоря, как-то у тебя все расплывчато, похоже я ход твоей мысли не улавливаю вовсе. 1. с самого начала -- ты хочешь вместо клеточного поля использовать сплошное; -- 2. как собираешься хранить объекты? (кирпичи, бетон и тп) 3. как твой бот будет смотреть куда едет (на сплошном поле)? как он будет оценивать путь, по какому принципу путь (набор узловых точек) будет сформирован?
хотя знаешь что, почему бы тебе автору не написать? какой смысл мне что-то доказывать? тем более что я буду занят некоторое время, писать не смогу.
Нет, без клеточной системы не обойтись. НО! Для экономии ресурсов бот должен просматривать, нпример, на расстоянии 30 клеток (20х20=400, что вполне под силу среднему процессору). В Это сделает его умнее, позволит экономить ресурсы и поставит его по дальности обзора наравне с человеком. Места хранения аптечек, бустера и неуязвимости должен знать на росстоянии 60 клеток- т.к. их координаты не меняются, то и обновлять данные о них часто не нужно. Потом должен быть "управляемый рандом". Это значит, что (пример): Бот находится на расстоянии до желаемой цели на растоянии X по прямой. По прямой мешает проехать бетон/вода/много кирпича. Есть 2 альтернативных пути: 1-ый составляет Х+20, но на пути стоит тюрель. Вроятность погибнуть равна 50% (всегда должен ставить именно_50_процентов). Второй путь по формуле: пусть второй путь равен (X+20)+Y. Если Y>2(x+20)=не выбираем этот путь. Y>(X+20)<2(X+20) тогда вероятность, что выбирем его, равна 50%. Если Y<=X (игрик меньше или равно иксу), то 100% выбираем ему.
При различном колличестве тюрелей на обоих путях формулы похожы: Z1=X*T и Z2=X*T, где Т равно количеству тюрелей. Z1и Z2 - два путя. Выбирается тот, где результат вычисления окажется меньше.
Если один на путях встречаются кирпичи, то прибавляем к результату колличество слоёв кирпичей, которые нужно преодолеть, к сумме прежних вычислений. Колличество мин подобным образом.
Эта система будет работать в любых условиях. Хотя здесь предусмотрены не все параметры (такие как повреждения), она создаёт впечатление довольно умного АИ. Это при выборе маршрута. Для дуэли модель АИ рассписывать не буду, устал =)))
> сейчас бот не просматривает все точки на карте определяя своих врагов. да неужели? )))) а как же это так он, в таком случае, их определяет? раз уж ему даже для определения статичных препятствий на статичном пути обязан все точки просчитывать? ))
> я сильно недопонимаю как у тебя объекты хранится будут. объясни мне как ты будешь хранить объект "кирпич" (точнее кирпичный многоугольник -- если ты хочешь делать поле не клеточным) и как ты собираешься по точке на карте узнавать кирпич это или нет. ну, во-первых, храниться будет не кирпич, а его местоположение на карте. самая суть объекта "кирпич" к этому не относится. а местоположение его можно двумя способами хранить. или можно просто взять редактор, кисть, и расставить кучу пикселей этого самого кирпича. и сохранить в виде кучи пикселей. второй вариант, раз уж тебе так требуется делать отрезки, края и многоугольники. это сеть из нескольких точечков. то есть, опять же, запускаем редактор и говорим ему, что щас будет рисовать кирпич. допустим, что редактор нас поймёт. допустим, что его всё же запрограммируют на понимание этой схемы до 2020 года. так вот, после этого наша задача - поставить, допустим, десять точков. последовательно. и сказать редактору, что дорисовали кирпич. редактор увидит, что ему поставили десять последовательных точек, и последовательно же их соединит: первая со второй, вторая с третьей, и так далее, в конце - последнюю с первой соединяем. получится замкнутая ломаная линия, она же - многоугольник. те линии, которые редактор составил, имея точки - это и есть те самые границы кирпича, по которым его очень просто будет определять. то, что внутри многоугольника, заштриховывается сплошным кирпичом. затем, при экспорте, редактор всё это сохраняет. если мы просто кистью рисовали - то он сохраняет местоположения всех пикселей. если линиями рисовали, то он ставит два тега для определения границ кода одного цельного куска кирпича, и внутри тегов пишет местоположения наших десяти точков. при загрузке карты он получает эти самые десять точков и ставит между ними отрезки, а внутри ломаной - сплошной кусок кирпича. и все дела. можно ещё прилепить к редактору графическую фишку в виде того, что он будет сразу показывать прямую между последней точкой и курсором. и между уже поставленными точками - тоже. чтобы маппер потом не хватался за голову, увидев косяк в уже построенном объекте. насчёт тегов и росписи последовательных точков - это для старых версий формата карт. сейчас - хз, там система другая, но затруднений всё равно не возникнет, однозначно.
> ты что собрался попиксельную карту держать? а без проблем. =) сам знаю, что без сжатия карты будут весить охренительно много. особенно большие. но, во-первых, есть такая штука, как сжатие - а в данном случае она позволит много чего сократить... но даже если и нет - системку с гранями, линиями и минимумом точков я только что предложил.
> и вообще, честно говоря, как-то у тебя все расплывчато, похоже я ход твоей мысли не улавливаю вовсе. хе, думаешь, я ход своих мыслев лучше улавливаю?
> 1. с самого начала -- ты хочешь вместо клеточного поля использовать сплошное; -- не сплошное. попиксельное. а можно и сплошное. но всё равно разметка будет попиксельной.
> 2. как собираешься хранить объекты? (кирпичи, бетон и тп) а как раньше... только немножко код можно будет изменить. для текстового формата такая фенька выйдет: сначала - слово, означающее, что это за объект. вода, кирпич, бетон, лес... в файле так и будет прописано, как раньше: CONCRETE, WATER, WOOD... а дальше... а дальше - перечисление пикселев. всех подряд. которые к этому объекту относятся. разумеется, можно прицепить к этому делу сжатие: построчно распределить, или просто код изменить... щас формат карт другой, поэтому, повторяю, с этим делом хз. но суть всё та же. для пограничной системы - уже писал. два тега, перечень точков. два тега, следующий перечень. в редакторе можно будет сразу редактировать всё, что между тегами: то есть, удалять цельный объект, или там перетаскивать-крутить-вертеть его. параллельно - режим обработки точков, для обработки внутри одного объекта. вот так оно и должно быть.
> 3. как твой бот будет смотреть куда едет (на сплошном поле)? как он будет оценивать путь, по какому принципу путь (набор узловых точек) будет сформирован? бот - он вообще не знает, что поле изменили. он знает, что есть вэи, есть размешённые на вэях кирпичи и есть вражеские танки. ну, ещё он знает, что есть цель битвы, есть аптечки-оружия-бустеры-электрошоки. и стационарки. остальное, что он знает, вообще к полю отношения не имеет. путь оценивать будет не он, а вэйпоинтер. именно этому несчастному человеку придётся нарисовать на карте все зоны. зоны будут отличаться - мол, сюда ходи, сюда почаще ходи, сюда ныкайся, отсюда кемпери, здесь тусуйся, если надо свой флаг охранять, а сюда едь, чтоб вражеский спереть/расстрелять. плюс различие приоритетности зоны для каждой команды. пределом мечтаний для этой фичи будет вручную настраиваемые ползунки с процентами. =) бот, заспавнившись, условно, на проходимой зоне (если нет - значит, вэйпоинтер дурак, а боту надо ехать по кратчайшему пути к ближайшему проходимому месту, или просто рандомно, пока не найдёт это место), в первую очередь определится с целью. это может быть important-зона, это может быть most_important-зона, это может быть пушка. к первым двум путь однозначно пролегает через проходимые зоны. или, опять же, вэйпоинтер дурак. =) итак, бот видит цель и все пути к ней. теперь он включает генератор случайных чисел, учитывая приоритетность каждого пути для его команды. в том смысле, что чем приоритетней путь, тем чаще он должен его "угадывать". вот генератор случайных чисел выключился: за это время бот успел простоять полчаса, и его флаг таскали туда-сюда уже сотню раз. зато теперь бот знает, какая у него цель, и точно знает, покудова ему надо туда ехать. и едет! если ему встречаются помехи в виде стационарок, кирпича или вражеского танка - он их ликвидирует. условно. условно потому, что ликвидировать могут его самого. ещё бот может встретить, например, оставленную кем-то пушку. она необязательно должна быть на проходимой зоне, потому что пушку мог потерять человек, а эти беспринципные существа почему-то не обращают внимания на проходимость зон и прут как попало. в таком случае, если боту почему-то понравилась именно эта кинутая пушка, пытается её подобрать. самым простым путём - движением по прямой. препятствий он по идее не должен встретить, потому что уже увидел оружие. а раз увидел - значит, обзор ему не скрывали никакие стены. включая воду. бот едет к пушке, подбирает, едет обратно. возвращается на то же место, где увидел пушку. постарался вспомнить, куда шёл. если вспомнит - то пойдёт дальше по той же схеме. ему также по пути могут попасться электрошоки, аптечки, бустеры или снаряды усиленной бустером Тяжелой пушки. первые три должны быть предусмотрены вэйпоинтером и находиться на проходимой местности. иначе делаем вывод, что вэйпоинтер дурак. или не дурак, а просто решил, что боту не следует обращать внимание на этот бонус. и правильно решил. в любом случае, бот проигнорирует все эти бонусы. если же ему встретится по пути вышеуказанный снаряд... ну что ж, начинаем с начала, с того места, где бот заспавнился заново. =)) иначе бот едет дальше по той же схеме. доехал. если это просто important-зона, то бот молодец только потому, что доехал: это и есть цель нахождения данной зоны. теперь бот должен немножко тут покататься. или не должен. смотря какая именно зона ему попалась. далее, если бот уже покатался и его ещё не убили, он снова ищет, куда ж ему прокатиться. но теперь его цель однозначна - это не иначе как most_important-зона, где должен храниться флаг, штаб, заложники или побухать. если бот досюдова доехал, значит, перед ним имеется цель битвы, и он должен этим воспользоваться. и воспользуется. есть и другой вариант, что вэйпоинтер был шутником, и в этой зоне нет ничего. или ещё хуже - там есть много стационарок и много мин. тогда начинаем действовать сначала - с того места, где бот заспавнился заново. =) иначе - бот, например, разрушает штаб. или хватает флаг. в первом случае битвы выиграна. во втором - бот приобретает дополнительный параметр, который означает, что у него имеется флаг. в этом случае у него однозначная же цель - доехать до специальной зоны, типа resque. она может находиться под "своим" флагом. а может находиться рядом. но бот, доехав до неё, уже должен заметить, что перед ним свой флаг, и поехать к нему. задача выполнена, начинаем алгоритм сначала. вот и всё. определить, где именно находится та или иная зона, труда особого не составит. =)
наметка зон может происходить также, как и наметка кирпича. хоть попиксельно, хоть по линиям. неважно.
> хотя знаешь что, почему бы тебе автору не написать? какой смысл мне что-то доказывать? первый вопрос риторический. =) по поводу второго. ты начал спорить, я тебе и доказываю. =) вот и всё.
2[vs]: управляемый рандом? фтопку. потому что он уже есть, в данном случае ты предлагаешь лишь его оптимизацию. =) вэи принципиально лучше. а рандом надо оставить на тот случай, если вэев к карте вдруг не окажется. и всё.
почему без клеточной системы "не обойтись" - аргументируй.
почему без клеточной системы "не обойтись" - аргументируй.
При попиксельной координации клеткой будет являться пиксель- т.е. для просчитывания пути придётмя проверять каждый пиксель. Представь, если карта будет размером 100000х100000 пикселов? Это 10 гигапикселов площадь! Обсчитывать все пиксели- это займёт очень много времени. Игра будет страшно тормозить.Это первое.
Второе- если совсем отказаться от клеток, то как ты себе представляешь вычисление местаположение? Это можно делать только по координатом- например, кирпичь у нас находится 10 клеток по X и 23 клетки по Y. А как без клеток?
гена глюкогенов пишет:
цитата:
управляемый рандом? фтопку. потому что он уже есть, в данном случае ты предлагаешь лишь его оптимизацию. =) вэи принципиально лучше. а рандом надо оставить на тот случай, если вэев к карте вдруг не окажется. и всё.
Во-первых. Его нужно срочно в игре оптимизировать, а то уже раздражает, когда бот из раза в раз наступает на одни и теже грабли, когда может объехать. Оптимизированый рандом решит эту проблему.
Сейчас все ИИ во всех играх строятся именно на нём. Только во многих играх там параметров куда больше чем я тут расписал =))) Увы, но без рандома никак- настоящий Искуственный Интелект ещё не изобрели, а без рандома он вообще всегда будет наступать на одни и теже грабли. Типа как в анекдоте: распенить шампунь по голове, смыть, повторить.
> сейчас бот не просматривает все точки на карте определяя своих врагов. да неужели? )))) а как же это так он, в таком случае, их определяет? раз уж ему даже для определения статичных препятствий на статичном пути обязан все точки просчитывать? ))
Очень просто! Он не все просматривает, а только в небольшом радиусе вокруг себя.
> Очень просто! Он не все просматривает, а только в небольшом радиусе вокруг себя. млин, не мешай стебаться над человеком. )
> При попиксельной координации клеткой будет являться пиксель- т.е. для просчитывания пути придётмя проверять каждый пиксель. Представь, если карта будет размером 100000х100000 пикселов? Это 10 гигапикселов площадь! Обсчитывать все пиксели- это займёт очень много времени. Игра будет страшно тормозить.Это первое. во-первых. 100000х100000 пикселей - это 3125х3125 клеток. =)))))) так вот, даже если увеличить размеры клеток аж до 100х100, то это вообще вне пределов нынешнего движка. если увеличить хоть до 200х200 - я бы такую карту не стал рисовать даже в клетках. =) во-вторых. для просчитывания пути? издеваешься, что ли? вот ты, когда видишь на экране свой танк и бустер в пределах одного экрана (40х32 или 32х24) - считаешь ВСЮ карту, например, 100х100? вот. а боту это нафиг надо? если ему нужен рандом, то он просчитывает только ближайший путь и только до ближайшего бонуса. ему не нужно искать бустер на другом конце карты. ему не нужно искать путь длиной в двести клеток. ему, раз ты хочешь ограничить радиус обзора, достаточно будет иметь как максимум 20 клеток радиуса для просчёта. иначе он имеет выгоду перед человеком, у которого 20 клеток радиуса - это экран 1280х1024 в полную ширину. а бот в первую очередь должен быть уподоблен человеку. далее. бот плевать хотел на бустер, который лежит от него в двадцати клетках за тройным бетонным слоем. он видит бустер, который находится на одной прямой. или бустер, до которого ехать максимум 40 клеток. это я предлагаю максимум, которого хватит для уподобления человеческому обзору. в-третьих. боту нафиг не надо просчитывать пиксели. он будет просчитывать объекты. цельные. я уже писал, как это организовать. таким образом можно заполнить сплошными кирпичными пикселями хоть 10000х10000 попиксельную местность, и бот её будет обрабатывать одним битом. и в-четвёртых. боту вообще не нужно ничего считать. у него есть вэйпоинтный путь, и всё, что ему нужно сделать с объектом - это определить один-единственный бит. или пересекается с зоной, или нет.
> Второе- если совсем отказаться от клеток, то как ты себе представляешь вычисление местаположение? Это можно делать только по координатом- например, кирпичь у нас находится 10 клеток по X и 23 клетки по Y. А как без клеток? ну это уж совсем глупый вопрос. а что, теперь у нас пиксель за координатную единицу не считается? просто теперь в записи будет фигурировать не 10*23, а, например, 320*736. таким образом, координат станет в 1024 раза больше, но только и только для записи.
> Во-первых. Его нужно срочно в игре оптимизировать, а то уже раздражает, когда бот из раза в раз наступает на одни и теже грабли, когда может объехать. Оптимизированый рандом решит эту проблему. почитать аргументы не судьба была? =) пусть оптимизируется сколько угодно, но самый минимальный аргумент против этого прост: бот три раза наступит на одни грабли, потом поедет и станет наступать на другие. потому что граблями будет человек, который бота будет убивать раз за разом в любой ситуации. с стационарками и кирпичом вообще проблем нет: даже люди нередко попросту раз за разом едут на один и тот же гаусс, чтоб два раза пальнуть по нему из тяжёлой пушки. а бот чем хуже? ) в любом случае рандом в принципе не решит никаких проблем. по определению. он станет чуть умнее, но алгоритм принципиально такой же.
> Сейчас все ИИ во всех играх строятся именно на нём. а тебе надо как во всех играх или как проще и лучше? если первое, то нам с тобой не по пути. ) а если второе - то надо принципиально изменять алгоритмику интеллекта. без ручного контроля этого нельзя сделать вообще никак, о чём я уже не раз повторял...
так вот, даже если увеличить размеры клеток аж до 100х100, то это вообще вне пределов нынешнего движка. если увеличить хоть до 200х200 - я бы такую карту не стал рисовать даже в клетках
Есть карты больше 200х200, и, кстати, движок поддерживает 512х512. И нужна такая система, которая, пусть и на практике этого никто делать не будте, в теории должна быть полностью работоспособной.
гена глюкогенов пишет:
цитата:
таким образом, координат станет в 1024 раза больше
И время обработки информации о них, соответственно, тоже =)))
гена глюкогенов пишет:
цитата:
ВСЮ карту, например, 100х100? вот. а боту это нафиг надо
А затем, чтобы он не стоял на месте, когда находится в конце диннююющего тоннеля. Это, кстати, тоже решается рандомом.
2[vs]: > Есть карты больше 200х200, и, кстати, движок поддерживает 512х512. И нужна такая система, которая, пусть и на практике этого никто делать не будте, в теории должна быть полностью работоспособной. никогда бы не подумал. мне просто показалось, что "размеры клеток" и "размер карты" - это несколько разные вещи. неужели я ошибся? )
> И время обработки информации о них, соответственно, тоже =))) я бы хотел взглянуть на процессор, который бы обрабатывал эту информацию в 1024 раза медленнее... щас даже схожу подсчитаю, какая у него должна быть частота в микрогерцах. или у тебя на транзисторах комп? =)
> А затем, чтобы он не стоял на месте, когда находится в конце диннююющего тоннеля. а зачем ему стоять? если нифига нету поблизости, бот постоит миллисекунду и разглядит бустер в конце этого тоннеля. или даже не разглядит. и решит просто покататься.
> Это, кстати, тоже решается рандомом. а есть вариант ещё проще. спереть скрипт езды из Супаплекса. и упростить его. сделать так: бот заспавнился и поехал вперёд. если он ни в кого не ткнулся, то продолжает ехать. и так далее. потом он ткнётся. и повернёт на 90 градусов влево. или вправо. и поедет дальше. пока не ткнётся ещё во что-нибудь. и снова повернёт. можно даже в ту же сторону. и так далее. реализовать - легко. и бот вообще нигде не будет стоять на месте без дела: постоянно в движении. можно приделать и генератор случайных чисел. он будет определять, направо или налево поворачивать. круто? вот. я о том, что если ты видишь хоть какое-то преимущество своего рандома перед вышеописанной системой, то я вижу абсолютно такое же преимущество этого алгоритма перед этим рандомом.
никогда бы не подумал. мне просто показалось, что "размеры клеток" и "размер карты" - это несколько разные вещи. неужели я ошибся? )
Я вообще то говорил что в принципе движок поддержывает карты размером 512х512 клеток. Одна клетка длинной.... эээ... не помню вообщем, но можно прикинуть, скоько пикселей занимает такая карта. Подумай теперь о времени её загрузки, если 1 клетка будет равнятся 1 пекселу. И, на самом деле любой, процесср будет делать это в 1024 раза медленнее. Даже на очень мощьном можно задержки нельзя будет незаметить. Для того и берут клетки в несколько пикселей в ширину чтобы экономить ресурсы. И чтобы быстрее работала. Зделсть так, чтобы вместо клеток всё вычислялось по пикселам- несложно.
P.S. Регистрация очень простая- тебе даже не высылают письмон на e-mail.
> Это уже рандом. "или" означает, что сторона принципиально не важна. а поворачивать будет в одну или ту же сторону.
> Я вообще то говорил что в принципе движок поддержывает карты размером 512х512 клеток. ну вот я о том же - никогда бы сам до этого не догадался...
> Одна клетка длинной.... эээ... не помню вообщем, но можно прикинуть, скоько пикселей занимает такая карта. а я помню. 32 пикселя высотой и шириной. итого на 512х512 (кстати, просто для примера создай карту такого размера только с бетонных ограждением, точкой спавна и риппером. и ещё бустер можно. и постреляй риппером. у меня тормоза проявлялись довольно серьёзные, хотя счётчик частиц астрономических чисел не выдавал) карте в пикселях в каждую сторону будет 16384 размера. площадь в клетках - 262144. площадь в пикселях - 268435456 квадратных (они же обычные) пикселей. если я не ошибаюсь. проверь на калькуляторе, если хочешь. но, в любом случае, это не так уж и много. =))))) а теперь включаем мозги. и мозгом медленно понимаем, что обрабатывать придётся лишь те точки, которые нарисуем. затем понимаем, что рисовать мы будем не все эти двести с половиной миллиона. я даже сомневаюсь, что кто-то из присутствующих утрудит себя заполнением сотни тысяч клеток для клеточного режима. а ещё мы понимаем, что для организации одной черырёхугольной стенки - будь она хоть 1х1, хоть 32х32, хоть 256х256 = уйдёт всего четыре пикселя. даже для лабиринтообразной карты количество точек будет даже меньше, нежели количество клеток. и это с учётом того, что мы больше не утруждаемся издержками клетчатой матрицы и можем творить любые картинки. а ещё - с учётом того, что для карты нормального (а не 512х512) размера задержек будет ещё меньше.
> И, на самом деле любой, процесср будет делать это в 1024 раза медленнее. прекрасно. на всякий случай, я сосчитал уравнением. щас на бумажке перевёл те циферки в двоичную систему и сравнил. процессор должен делать одну операцию в 4096 секунд. это чуть больше часа... минут на восемь. с копейками. операцией считаю операцию с одним битом - нуликом или единичкой. иначе этот процессор вообще не будет действовать. ну, не так уж и мало... две десятых от одного миллигерца. вот такой процессор будет делать эту операцию медленнее в 1024 раза. ах да, уточню: это я ещё приуменьшил результат. число 320 в двоичной системе счёта выражается девятью битами. я же в расчётах счёл, что это всего лишь восемь бит - для круглого счёта. если бы использовались не биты, а байты, то это уже было бы два байта, а не один - то есть всё равно что 16 бит для процессора. но, как я уже говорил, такие процессоры нам нафиг не нужны. впрочем, никому не нужны были и те, с 0.2 миллигерца. ламповые системы и те шустрее были. а до этого - счёты. они превосходили этот процессор, если двигать пальцем одну костяшку в течении аж целой минуты, в шестдесят восемь раз. даже чуть больше, но остальное - там совсем уж мелочь, меньше двадцати секунд. и ещё - сравнивалось такое кругленькое число, как 32. =) будь оно немного больше, результаты были бы ещё повеселее. ну, не знаю, как у тебя, а у меня процессор считает пошустрее. ему разницы между числом 23 и 736 не хватит на то, чтобы замедлиться в тысячу раз. та задержка, что у него наблюдается... её вообще не наблюдается. кстати, на практике можешь сравнить. создай две пустых карты с параметрами 512х512. в первой поставь точку рождения танка в левом верхнем углу. во второй - в нижнем правом. обработка карт произойдёт с разницей ровно в сто раз. это если там стоит обработка с "половинами" клеток (ведь в редакторе можно использовать и другие узлы). а обработка без них. значит, разница будет в четыреста раз. а теперь учитываем, что обработка происходит ещё и с учётом совсем дробных мест - там, где можно предметы типа аптечков ставить. круглым счётом, если приуменьшить результат, разница составит эту самую тысячу. если заметил изменения - поздравляю. если нет - поставь не одну, а по, например, четыре клетки бетона. теперь обработка будет иметь разницу в шестнадцать тысяч раз. замечаешь? вот на твоём процессоре разница между пикселем и клеткой будет в шестнадцать раз меньше той, что ты только что заметил.
> Для того и берут клетки в несколько пикселей в ширину чтобы экономить ресурсы. ф перлодром.
P.S. ты думаешь, я ни разу на этом дураццком фастбб не был? =) я ж говорю - лень делать два лишних клика мышой.
постреляй риппером. у меня тормоза проявлялись довольно серьёзные,
У меня такого не возникало, зато если долго стрелять из ракетницы с бустером (чтобы ракет непрерывано летели), то тормоза действительно появляются. Это связано с тем, что компьютер просчитывает траекторию полёта на все 16384 пиксела. Теперь о том же, представь, что оно так тормозит из-за просчёта ПРЯМОЙ траектории частиц! А как оно по твоему будет работать, если ВСЁ будет вычислятся в системе координат, где делению соответствует пиксел?
И всё-таки, на любом процессоре процесс обсчитывания координат будет проходить в 1024 раза медленнее, т.к. работы в 1024 раза больше. Другое дело, что эти велечины на столько малы, что с мощьным процессором ты можешь почти не почуствовать разницу. Хотя нет. Разница всё равно будет. И очень ощутимая, особенно для ботов. Если бот будет думать, куда ему уезжать от стационарки хотя-бы 3 секунды, то это будет смертельно. И повторю: загрузка такой карты даже стандартного размера займёт кучу времени!
гена глюкогенов пишет:
цитата:
> Для того и берут клетки в несколько пикселей в ширину чтобы экономить ресурсы. ф перлодром
Это одна из причин. В ту же тему: почему по твоему в играх, особенно 3D, вместо прорисовки объектов попиксельно беруться достаточно крупные полигоны?
гена глюкогенов пишет:
цитата:
учётом совсем дробных мест - там, где можно предметы типа аптечков ставить. круглым счётом, если приуменьшить результат, разница составит эту самую тысячу. если заметил изменения - поздравляю. если нет - поставь не одну, а по, например, четыре клетки бетона. теперь обработка будет иметь разницу в шестнадцать тысяч раз. замечаешь? вот на твоём процессоре разница между пикселем
Боюсь с процессором в 2.66Ггц это заметить сложно =)
гена глюкогенов пишет:
цитата:
не утруждаемся издержками клетчатой матрицы и можем творить любые картинки.
Т.е. ты предлагаешь блоки кирпича, бетона, воды и кустов тоже сделать размером в один пиксел? Браво! Извеняюсь, но это самая бредовая идея, которую я на этом форуме видел! Посмотрел бы я, как ты бы заполнял кирпичём площадку 300х300 пикселей хотябы. И как ты делал бы симметричные карты без сетки с клетками?
> У меня такого не возникало, зато если долго стрелять из ракетницы с бустером (чтобы ракет непрерывано летели), то тормоза действительно появляются. странно.
> И всё-таки, на любом процессоре процесс обсчитывания координат будет проходить в 1024 раза медленнее, т.к. работы в 1024 раза больше. я тебе уже привёл расчёт, каким должен быть "любой" процессор. =) а о том, что между теми же числами "10" и "320" есть разница в 1024 раза для процессора - первый раз слышу.
> Другое дело, что эти велечины на столько малы, что с мощьным процессором ты можешь почти не почуствовать разницу. Хотя нет. Разница всё равно будет. будет. для того процессора - как раз в 1024 раза. для других - в 2,25 раз. вернее, чего это я... для других разницы вообще не будет. потому что байт - это байт, и от количества битов по модулю восьми ничего не изменится.
> И повторю: загрузка такой карты даже стандартного размера займёт кучу времени! и повторяю ещё раз, что в пользу этого бредового вывода не было представлено ровно ни одного аргумента. я же по этому поводу уже говорил - карта будет загружаться чуточку шустрее, чем раньше. а обрабатываться - шустрее в несколько раз.
> Это одна из причин. В ту же тему: почему по твоему в играх, особенно 3D, вместо прорисовки объектов попиксельно беруться достаточно крупные полигоны? потому что меньше нагрузки. только вот я что-то не наблюдаю никакой связи между предложенной системой и разницей между попиксельной прорисовкой и полигонами (хоть двумерными, хоть одномерными). =)
> Боюсь с процессором в 2.66Ггц это заметить сложно =) вот и я о том же. а теперь учти то, что разница между попиксельной системой и поклетчатой в шестнадцать раз меньше того, что с данным процессором вообще незаметно. ну, если очень надо, поставь не четыре, а ажно десять клеток бетона! и сравни. это в сто раз больше тех задержек, которые ты считаешь такими смертельными. в конце концов, тридцать две клетки. разница будет ровно в 1024 раза больше, нежели прошлая разница в эти же 1024 раза. больше миллиона тех смертельных задержек - из тридцати двух клеток. если не заметишь особых изменений, сделай выводы. =)
> Т.е. ты предлагаешь блоки кирпича, бетона, воды и кустов тоже сделать размером в один пиксел? забавная идея, действительно. хорошо, что я её не предлагал. =)
> Посмотрел бы я, как ты бы заполнял кирпичём площадку 300х300 пикселей хотябы. слово "кисть" никому так ничего и не сказало?
> И как ты делал бы симметричные карты без сетки с клетками? на глазок. =) а зачем, интересно знать, убирать сетку?
на глазок. =) а зачем, интересно знать, убирать сетку?
А затем, что если размер ячейки будет 1 пиксел, то где ты собираешься чертить линии? Между пикселами чтоли? =)))
гена глюкогенов пишет:
цитата:
слово "кисть" никому так ничего и не сказало?
Минуточку, это граффичиский редактор или игра? Замучаешься ты этими кисточками работать =)))
гена глюкогенов пишет:
цитата:
забавная идея, действительно. хорошо, что я её не предлагал. =)
Тогда зачем кисти, если блоки бетона и кирпича и т.п. будут достаточно крупные?
гена глюкогенов пишет:
цитата:
потому что меньше нагрузки. только вот я что-то не наблюдаю никакой связи между предложенной системой и разницей между попиксельной прорисовкой и полигонами
А связь такая, что ты, фактически, предлагаешь сделать размер полигона с пиксел. Да система замучается их обсчитывать! Сам сказал, для уменьшения нагрузки.
гена глюкогенов пишет:
цитата:
карта будет загружаться чуточку шустрее, чем раньше. а обрабатываться - шустрее в несколько раз
Это вообще бред. Если раньше система обрабатывала только целые клетки и их четвертины, то теперь придётся каждый пиксел.
гена глюкогенов пишет:
цитата:
непрерывано летели), то тормоза действительно появляются. странно.
2[vs]: > А затем, что если размер ячейки будет 1 пиксел, то где ты собираешься чертить линии? Между пикселами чтоли? =))) какие топорные методы. фу. нет, можно просто оставить сетку с линиями по 16, 32, 64 пикселев. а щас вроде бы есть масштабирование редактора, и вообще проблемов таких нету.
> Минуточку, это граффичиский редактор или игра? Замучаешься ты этими кисточками работать =))) а художественного оформления поля боя никто не отменял. =) та же расстановка, что и раньше. для закрасок больших зон - разного размера "курсоры" - что в один пиксель, что в 4х4, что в 32х32, как раньше, что 128х128 для извращенцев. хотя я, кажется, уже говорил, что попиксельная прорисовка нафиг не нужна.
> Тогда зачем кисти, если блоки бетона и кирпича и т.п. будут достаточно крупные? ну если тебе очень хотелось сделать попиксельную (в смысле, каждый пиксель отдельно) прорисовку, то без них никак. мне её делать не очень хотелось. =)
> А связь такая, что ты, фактически, предлагаешь сделать размер полигона с пиксел. Да система замучается их обсчитывать! Сам сказал, для уменьшения нагрузки. клевета. я такого не предлагал. я предлагал сделать абсолютно как угодно изменяемые полигоны. хоть в пиксель, хоть в две тыщи пикселей. в любом случае за каждый полигон будут отвечать лишь две точки, две координаты в коде карты. то есть, например, поставил четыре точки в виде вершин квадрата со стороной, допустим, тех же 1024. то есть 32 клетки. получаем четыре грани-полигона по 1024 пикселя длиной каждая. и огромная бетонная площать в миллион с копейками пикселей (1024 клетки, между прочим), которая обрабатывается как один объект! в карте - четыре точки, четыре координаты. в обработке - один объект, ограниченный всего лишь четырьмя точками. в старом режиме - 1024 клетки и 1024 координаты. разница заметна?
> Это вообще бред. Если раньше система обрабатывала только целые клетки и их четвертины, то теперь придётся каждый пиксел. "каждых" пикселей будет примерно штук пятьдесят на карту 32х24 клетков. на среднюю карту. ну, максимум, для художников-извращенцев - сотня. да хоть сто пятьдесят. потому что клетков было семьсот шестьдесят восемь. не думаю, что на их обработку процессор потратит больше времени. кстати, если тебе очень хочется, я могу до завтра взять карту, например, 64х64 дм Инсерта. сосчитать там все объекты - в текстовой карте это очень просто. а затем сосчитать количество пикселей, сколько бы их затратилось в предлагаемой мной системе. для абсолютно такой же карты - даже без учёта того, что её можно оптимизировать как минимум в полтора-два раза, причём ещё и с выгодой для играбельности. надеюсь, конкретные числа подействуют лучше.
> Я же объяснил, почему это. ну, это-то понятно. для меня наиболее странным кажется тот факт, что лично у меня при тех же условиях наблюдаются совсем другие результаты...
Обойдусь без цитат. Когда появится возможность сделать размер полигона в 1 пиксел все сразу бросятся делать различные надписи на картах- ведь таким образм можно много чего написать- в результате чисто по человеческому фактору, колличество объектов возрастёт в десятки раз.
2[vs]: ну, знаете ли. =) за идиотизм мапперов это дело отвечать не будет. это целиком и полностью их проблемы. принципиально же - такая система по всем факторам гораздо лучше и даже поэкономней будет. вон, например, мапы от "веерной стрельбы" как делались... ведь можно точно таким же образом размножать и бетон/воду/лес... придурок вроде меня вот возьмёт какую-нибудь карту и начнёт размножать... и объектов станет в сотни раз больше... а значит, моя система лучше, там всего лишь в десятки раз. ))) не, ну правда. пусть бросаются сколько хотят, если им очень хочется того самого дыма их системного блока. а, кстати, рисование так уж много ничего не займёт. тоже можно будет сэкономить. потому что сравни, что сейчас кто-нибудь напишет "TANK FOREVER" или "MAPPED BY [и своё имя на десять буков]" - клетками, что можно будет потом. если ни у кого не возникнет желания поточнее нарисовать буквы "О" или "С" - то всё в норме. вот, для примера, TANK, написанный в гостевухе разберу: на букву Т самого малого размера приходится 7 клеток. в попиксельной системе максимум, сколько можно затратить - 8. причём для буквы любого размера и шрифта. на букву А - 12 клеток. в попиксельной системе - 11. причём А будет более реалистичная. можно ещё меньше - 8, и А будет даже настоящей. =) на реализацию старой А, как сейчас, можно затратить как максимум 12 точков, причём она станет немного красивей. на букву N ушло 12 клеток. в попиксельной системе - 4 (!!) точки. и это с учётом того, что буква станет идеально выполненной, не то, что сейчас получается. на букву К ушло 10 клеток. в попиксельной системе это - максимум. максимум, нужный для реализации точно такой же буквы, только гооораздо более ровной и красивой. можно и меньше, и красивше. разумеется, буквы могут быть любого размера. можно растянуть это слово хоть на 32х24, хоть на 40х32, хоть на 512х384. в клетках это работа как минимум в несколько десятков раз больше. в пикселях - всё то же. итого - в клетках фраза составляет 41 строки кода. в попикселировке - от 30 до 33. с такой же красивостью и любым масштабированием. можно сделать буквы уже. или полоску, соединяющую пикселя, расширять. тогда получим 4+5+4+5=18 точков. это уж не говоря о том, что на буквы типа V или L уйдёт вообще минимальнейшее количество точков. вот тебе очередная выгода попиксельной системы.
гена глюкогенов 1.Предполжим, что нам нужны буквы в 100 пикселей в высоту и только 2 пиксела в толщину линии? Тогда, на вскидку, буква А займёт 550pix. Это 550 объектов. 2.Как ты предлагаешь использовать текстуры на блоках кирпича/бетона/воды/кустов размером 1-2 пиксела?
2[vs]: > Предполжим, что нам нужны буквы в 100 пикселей в высоту и только 2 пиксела в толщину линии? Тогда, на вскидку, буква А займёт ... 7 точек. =) по две точки на основания буквы. одна точка - верхняя. три точки - треугольник внутри буквы. итого семь.
> 2.Как ты предлагаешь использовать текстуры на блоках кирпича/бетона/воды/кустов размером 1-2 пиксела? белая/красная точечка. если кому-то так очень уж надо сделать блок размером в один пиксель - получат одну цветную точку.
nenorma ЮЖЯС! Какой южяс! Есму нужно срочно ноутбук покупть! И телефон с GPRS (хотя судя по аватору, у него уже есть неплохой смартфон)! И чтобы через мобильник выйти в инте и почитать!
Все даты в формате GMT
3 час. Хитов сегодня: 5
Права: смайлы да, картинки да, шрифты да, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет
Передай ему пожелания здоровья!
- участник сейчас на форуме
- участник вне форума