А зачем её отключать?
Наша всякие звуки издаёт, светится, крутилки всякие — что ещё детям надо? А запустить он её всё равно не мог — потому что дверцу не мог закрыть.
Для Андроида рекомендую (бесплатные версии): картинки с животными (можно добавлять своих, например, маму и папу, все кнопки отключаются, качественная русская озвучка) коробка со звуками (трясёшь телефон, он разные звуки издаёт)
Могу сказать, что для такого медленного языка, как PHP, слежение за муравьями и накопление информации от хода к ходу — необходимое условие, т.к. время на вычисления очень мало.
Так, найдя вражеский муравейник, я делал BFS (волновой поиск) для него для всей открытой карты (чтобы можно было потом быстро послать к муравейнику любое количество муравьёв). Этот поиск растягивался у меня на 2-5, а то и больше ходов — смотря чем ещё был занят бот. В то время как ребята С++ писали, что делают сотню BFS за ход ).
Для всех уже отправленных на маршрут муравьёв этот самый маршрут приходилось кэшировать. Поэтому нельзя было «терять» муравья ни в каком случае — даже если прямо перед ним появлялась еда, мешая ходить.
Могу сказать, что достаточно невысокое место — это моя проблема, а не самого PHP. У последней версии бота оставалось всё ещё много времени для реализации кучи вещей, которые я задумал — но у меня самого его не было. Кроме того, закоммитил бота с глупой и смешной ошибкой: при определённых обстоятельствах муравьи-патрульные бросали патрулирование и убегали на другой конец карты помогать разведчику. Муравейник, ясное дело, тут же захватывали )
Поэтому думал о том, чтобы написать оптимистическую статью о этих и других нюансах написания бота на медленном языке )
Я думаю, что все значения, получаемые со стороны браузера, должны валидироваться на стороне сервера перед обращением к базе.
База данных — это не инструмент для валидации, фильтрации или приведения типов.
Если вместо числа от пользователя придёт строка, то «простой и железный» фильтр в виде экранирования, может, и спасёт от инъекции, но получим исключение/ошибку от драйвера базы при выполнении запроса.
фильтр перед вставкой в строку запроса. ты же предлагаешь усложнить его добавив проверку «если это число, то не экранируем его и не закавычиваем»
Когда пишешь запрос, как правило явно видно, какое поле используется, и соответственно используются или не используются кавычки. Какие дополнительные проверки?
Ну, значения в кавычках — это строки, а поля явно имеют тип integer. Т.е. сервер вначале всё равно приведёт строки к числам. Думаю, что приведение к числу и проверку, что параметр таки число, должен делать не sql-сервер.
Конечно, есть шанс, что закавычивание целых чисел тут — это такой способ борьбы с инъекцией типа "?id=1 AND 1=1--", но (моё мнение) это не лучший способ бороться с такими инъекциями.
А что даст закавычивание имён таблиц, кроме того, что они перестанут восприниматься, как имена таблиц? :)
Buyincoins у меня жутко тормозил. В итоге я получил ошибку:
2013 Lost connection to MySQL server during query
in:
[select * from products_discount_quantity where products_id='3982' and discount_qty <='1' order by discount_qty desc]
И сам тот факт, что я её увидел, и вид запроса (целые числа в кавычках), и, в общем-то, его смысл — всё говорит об одном.
Хотел бы подкорректировать пару вещей, которые подробно обсуждались на родном для игры форуме.
>>цифра Skill является относительной величиной, и после каждой загрузки версии на сервер сбрасывается в ноль (т.к. не известно, будет ли новая версия лучше предыдущей).
Причина не в этом, так как, во-первых, разумно предположить, что новая версия всё-таки лучше старой, а, во-вторых, если версия и хуже, она просто скатится вниз.
Необнуление же skill повзволило бы новой версии сразу соревноваться с равными по уровню ботами, а не ждать этого 3-5 дней.
Так вот, организаторы называют такую причину. Если skill не сбрасывать, то новая версия бота автоматически «проскочит» средненьких ботов. Но может оказаться, что ваш бот хорошо играет против классных ботов, и хреново — против средненьких. У вас же нет шанса встретиться со средними ботами, если не обнулять skill.
И вот, наступает время сосбственно соревнования — 18 декабря, когда skill обнулится у всех. Тут-то и окажется, что ваш бот не может пройти средних ботов, чтобы соревноваться с сильными. Облом.
Организаторы говорят, что в предыдущем соревнованиии были именно такие ситуации.
>>Однако крайне желательно завершить выполнение алгоритма быстрее этого порога хотя бы на 50 мс, иначе велика вероятность получить timeout из-за буферизации ввода-вывода (вся передача игровых данных ведется через pipes), а то иногда получаются забавные штуки
Не совсем понимаю, что вы подразумеваете под проблемами из-за буферизации ввода-вывода, поэтому расскажу о причинах забавных штук, которые выяснили на оф. форуме. Их две:
1) В стартовом пакете java для чтения входных данных использовался Scanner. Его замена на StringTokenizer практически полностью устраняла проблему, буквально на порядок увеличивая скорость чтения.
2) Ошибка в начале отсчёта времени хода. Время следует отсчитывать не от команды «go» от сервера, а от первой переданной в начале хода строки.
3) Похоже, изредка сами сервера испытывают проблемы с производительностью.
Совокупность первых двух проблем часто приводила к таймауту java-ботов на первом же ходу на картах с несколькими муравейниками у каждого, т.к. на первом ходу передавалось слишком много строк с водой.
Вот наглядный пример: ants.fluxid.pl/replay.8935
Пусть мы знаем о муравейнике 143,2 и 113,32. Вашим способом мы узнаем только о муравейниках на этой линии.
Кроме того, в картах допускается зеркальная симметрия.
Хм, неплохая идея. Идею построить всю карту зная, что она зеркальная, я сразу отбросил — нудно и неинтересно реализовавть. А вот муравейники попробовать поискать — вполне можно.
Ну, занть, какая часть карты ещё не открыта — важно, т.к. надо открыть всё, чтобы найти все вражеские муравейники.
Другое дело, что хранить UNSEEN именно в основной карте — непринципиально, и я этим пока не пользуюсь.
Возможно, буду этим пользоваться, чтобы UNSEEN точки были более приоритетные при поиске пути, чтобы поскорее их открыть.
>> Иначе бот будет пытаться прокладывать маршрут только по открытым областям
Ничто не мешает сделать UNSEEN клетку по умолчанию проходимой. Я сделал именно так )
Наша всякие звуки издаёт, светится, крутилки всякие — что ещё детям надо? А запустить он её всё равно не мог — потому что дверцу не мог закрыть.
картинки с животными (можно добавлять своих, например, маму и папу, все кнопки отключаются, качественная русская озвучка)
коробка со звуками (трясёшь телефон, он разные звуки издаёт)
Могу сказать, что для такого медленного языка, как PHP, слежение за муравьями и накопление информации от хода к ходу — необходимое условие, т.к. время на вычисления очень мало.
Так, найдя вражеский муравейник, я делал BFS (волновой поиск) для него для всей открытой карты (чтобы можно было потом быстро послать к муравейнику любое количество муравьёв). Этот поиск растягивался у меня на 2-5, а то и больше ходов — смотря чем ещё был занят бот. В то время как ребята С++ писали, что делают сотню BFS за ход ).
Для всех уже отправленных на маршрут муравьёв этот самый маршрут приходилось кэшировать. Поэтому нельзя было «терять» муравья ни в каком случае — даже если прямо перед ним появлялась еда, мешая ходить.
Могу сказать, что достаточно невысокое место — это моя проблема, а не самого PHP. У последней версии бота оставалось всё ещё много времени для реализации кучи вещей, которые я задумал — но у меня самого его не было. Кроме того, закоммитил бота с глупой и смешной ошибкой: при определённых обстоятельствах муравьи-патрульные бросали патрулирование и убегали на другой конец карты помогать разведчику. Муравейник, ясное дело, тут же захватывали )
Поэтому думал о том, чтобы написать оптимистическую статью о этих и других нюансах написания бота на медленном языке )
База данных — это не инструмент для валидации, фильтрации или приведения типов.
Если вместо числа от пользователя придёт строка, то «простой и железный» фильтр в виде экранирования, может, и спасёт от инъекции, но получим исключение/ошибку от драйвера базы при выполнении запроса.
Когда пишешь запрос, как правило явно видно, какое поле используется, и соответственно используются или не используются кавычки. Какие дополнительные проверки?
Конечно, есть шанс, что закавычивание целых чисел тут — это такой способ борьбы с инъекцией типа "?id=1 AND 1=1--", но (моё мнение) это не лучший способ бороться с такими инъекциями.
А что даст закавычивание имён таблиц, кроме того, что они перестанут восприниматься, как имена таблиц? :)
2013 Lost connection to MySQL server during queryin:
[select * from products_discount_quantity where products_id='3982' and discount_qty <='1' order by discount_qty desc]
И сам тот факт, что я её увидел, и вид запроса (целые числа в кавычках), и, в общем-то, его смысл — всё говорит об одном.
ants.fluxid.pl/howto
Причина не в этом, так как, во-первых, разумно предположить, что новая версия всё-таки лучше старой, а, во-вторых, если версия и хуже, она просто скатится вниз.
Необнуление же skill повзволило бы новой версии сразу соревноваться с равными по уровню ботами, а не ждать этого 3-5 дней.
Так вот, организаторы называют такую причину. Если skill не сбрасывать, то новая версия бота автоматически «проскочит» средненьких ботов. Но может оказаться, что ваш бот хорошо играет против классных ботов, и хреново — против средненьких. У вас же нет шанса встретиться со средними ботами, если не обнулять skill.
И вот, наступает время сосбственно соревнования — 18 декабря, когда skill обнулится у всех. Тут-то и окажется, что ваш бот не может пройти средних ботов, чтобы соревноваться с сильными. Облом.
Организаторы говорят, что в предыдущем соревнованиии были именно такие ситуации.
Не совсем понимаю, что вы подразумеваете под проблемами из-за буферизации ввода-вывода, поэтому расскажу о причинах забавных штук, которые выяснили на оф. форуме. Их две:
1) В стартовом пакете java для чтения входных данных использовался Scanner. Его замена на StringTokenizer практически полностью устраняла проблему, буквально на порядок увеличивая скорость чтения.
2) Ошибка в начале отсчёта времени хода. Время следует отсчитывать не от команды «go» от сервера, а от первой переданной в начале хода строки.
3) Похоже, изредка сами сервера испытывают проблемы с производительностью.
Совокупность первых двух проблем часто приводила к таймауту java-ботов на первом же ходу на картах с несколькими муравейниками у каждого, т.к. на первом ходу передавалось слишком много строк с водой.
Если что, спрашивайте :)
Обращаю внимание читающих на то, что недочёты всё ещё на месте, в частности, утверждение, что прямой платёж требует регистрации покупателя в PayPal.
Так же обращаю внимание, что имеется ошибка в запросе на подтверждение транзакции.
Кроме перечисленных параметров:
// Завершаем транзакцию$requestParams = array(
'PAYMENTREQUEST_0_PAYMENTACTION' => 'Sale',
'PAYERID' => $_GET['PayerID']
);
необходимы параметры PAYMENTREQUEST_0_AMT и TOKEN.
Кроме того, если вы работаете с песочницей, для перенаправления на сайт PayPal следует использовать песочный адрес:
header( 'Location: www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=' . urlencode($token) );(спасибо, клёво!).
Если мы будем знать, например, 81,9 и 58,141 — то тогда вообще ничего больше узнать не получится.
Вот наглядный пример:
ants.fluxid.pl/replay.8935
Пусть мы знаем о муравейнике 143,2 и 113,32. Вашим способом мы узнаем только о муравейниках на этой линии.
Кроме того, в картах допускается зеркальная симметрия.
Другое дело, что хранить UNSEEN именно в основной карте — непринципиально, и я этим пока не пользуюсь.
Возможно, буду этим пользоваться, чтобы UNSEEN точки были более приоритетные при поиске пути, чтобы поскорее их открыть.
Ничто не мешает сделать UNSEEN клетку по умолчанию проходимой. Я сделал именно так )