Zura_aps, пока что это интересно конкретно вам. Даже если выскажусь я и кто-то ещё, это будет выборка из трёх человек. Маловато для выводов.
Если игра станет хитом, вы поймёте, что ошибались, и это не просто "интересно", а мега интересно всем от мала до велика.
Если игра останется незамеченной, вы поймёте, что ошибались, и этот мультик нафиг никому не нужен, а у выбранной вами аудитории другой запрос.
Вы же выбрали аудиторию? Если нет, то советую повторить основы, - какие принято выделять этапы разработки игры и т.п.
Zura_aps, в современном геймдизайне принято измерять, а не гадать.
Вот когда вы сможете измерить "крутизну" в каких-то единицах и посчитаете, насколько конкретно она выросла после введения фичи, вот тогда это будет и правда круто. Пока что это блуждание во тьме.
ThunderCat, реально 80%?
То есть из 10 студентов к концу остаются два? Как-то фантастично звучит. Может, дело в самих курсах или препод страшный или что-то подобное.
Ну или супер дешевые, к примеру, части народа просто впарили по скидке, хотя им это и не надо было вовсе, вот и бросают.
Вам нужно "несколько дней" потратить на изучение Lua.
Зная математику и информатику на школьном уровне, Lua можно выучить вообще примерно за час, максимум два.
С другого языка программирования на Lua можно полностью пересесть примерно за 15 минут.
После этого уже приступайте к изучения API роблокс и вычитыванию того, что вам нужно для решения.
Алексей Ярков, когда браузеры раньше качали без переименования, а инет был медленный, то так и делал. К примеру, фильм качается 2 часа, и смотреть его 2 часа. Вообще не было проблем. Можно даже по локальной сети файл расшарить, чтобы он был доступен на других пк.
Просто я думал, наверняка же есть какая-то опция, которая отключает переименование и возвращает к простому варианту скачивания.
Константин Цветков, попробуйте скачать большой файл. Вот я скачиваю, к примеру, файл movie.mp4, а браузер сохраняет его в movie.mp4.crdownload. Пока браузер скачивает, с файлом нельзя работать. Чуть что, браузер его просто удаляет и начинает качать заново.
Vatnik431, в луа написано:
если нажат пробел, нажать бекспейс,
если отжат пробел, отжать бекспейс.
Точно не знаю, как работает ваша система, но по сути она устроена так:
1) один коллега другому сказал, что нужно включить рубильник. Вы это подслушали, и включили свой рубильник тоже.
2) когда коллега говорит выключить, вы снова это подслушиваете и делаете у себя также.
Здесь включать или не включать рубильник у себя, и какой именно - решаете вы. Но запретить другому коллеге переключать свои вы не можете, нужен уровень власти повыше, т.е. нужно идти к начальнику и просить поменять регламент, или самому быть начальником.
То есть вам нужно решить задачу, в которой инфа о нажатии по пробелу должна попадать в луа, но не должна попадать в игру. Как это сделать - не знаю. Кое-кто уже говорил, что никак. Но, может быть, у вас получится. Придётся вмешаться в работу кода на уровне драйверов, скорее всего.
А в чём сложность? Просто объединить два объекта умеете? Перебирать массив умеете? Где проблема-то? :) Похоже на задачу.
Хотя бы попытки решить у вас есть?
SergeySerge11, ну, этой задаче соответствует и обычный массив, получается:
Доступ по ключу, то есть по индексу, - O(1)
Случайное удаление - случайный индекс, - снова O(1), потому что можно без сдвига, на место удалённого переставляем последний элемент массива. Ведь про сортировку речи не было.
Добавление, очевидно, тупо в конец - снова O(1). А если нужно запутывание для какой-то игры - добавляем в случайное место, вместо какого-то элемента, который перемещается в конец. Для "игрока" это равносильно случайному добавлению, т.к. он не будет знать, где какая карта, сколько бы чего ни добавлял.
А если этого мало, то есть нужен не числовой ключ, то, как я уже говорил в ответе, делаем дополнительную хеш-таблицу с ссылками на элементы, которая помогает за O(1) узнавать индекс по вашему ключу.
Однако если, как сказали в другом ответе, вам нужно что-то типа удаления "самого старого элемента", то есть это какой-то выбор и сравнение, то это уже намёк на сортировку и порядок, и нужен совсем другой подход. Просто в вопросе об этом не было ни слова. "Просто какой-то узел удалить" - подразумевает, что у вас уже есть функция, определяющая самый нужный для удаления узел, и её менять/придумывать не требуется.
В общем, если задачу нужно сделать честно, и нет возможности срезать углы, перемешивать карты в любой момент, когда нам вздумается, и нужно вставлять чётко "со сдвигом" и иметь определённый порядок, пусть даже известный только арбитру, то придётся чем-то жертвовать - процессором или памятью, например, или ускорением где-то по цене замедления где-то ещё. Но всё же у вас, скорее всего, специфичная задача, где нужен конкретный результат, а значит, скорее всего, возможна оптимизация, типа игнорирования порядка, удобные преставления, ещё какие-то допущения и упрощения. Это всё зависит от конкретных условий задачи, наличия/отсутствия в ней конкретных ограничений.
В любом случае, хеш-таблица - это, я бы сказал, почти универсальное решение, которым можно приправить любую сложную задачу, даже если сама хеш-таблица не годится в качестве ответа.
1. 50% потерь показывает ICMP. Хотите сказать, что среди UDP пакетов будет при этом не 50% потерь? Про TCP я знаю, что он решает проблему пересылкой, но некое подобие VPN предполагает, что тот же TCP (и любой другой протокол выше сетевого) заворачивается программно, а потом снова пересылается через тот же TCP/UDP. И на этапе этого заворачивания можно придумать всякие штуки типа избыточности. На самом деле это самое простое, что приходит в голову, поэтому это наверняка либо есть, либо есть объяснение, почему так нельзя.
2. Почему только для части протоколов? Я же в вопросе ищу решение для всего трафика в целом, со всеми включёнными в него протоколами. Моя идея была, что в общем случае канал не используется на 100% и можно увеличить количество пересылаемых данных, уменьшив тем самым величину случайных потерь. Конечно, для чего-то типа торрентов это не сработает (да и не потребуется), но почти для всего остального должно сработать. Собственный протокол - слишком круто, но мне кажется, идея избыточности слишком проста, поэтому о создании своего протокола уже думали раньше и не раз.
Почему нельзя решать проблемы TCP находясь выше уровня TCP? Звучит красиво, но это теорема или аксиома?
Повторная пересылка пакета происходит ценой времени ожидания пакета + времени повторной пересылки. И если данных в единицу времени много, то это будет означать "подвисание" TCP соединения.
Я же гипотетически предлагаю весь трафик (включая TCP) поделить на кусочки и завернуть в другой протокол с избыточностью, в котором каждый "кусочек" пересылается дважды, а то и трижды. Пакеты в таком случае идут параллельно, и пересылка как таковая не требуется. Если все дубли не пришли, то пакет просто считается потерянным. Но из-за избыточности снижается процент потерь пакетов в целом для провайдера.
Akina, а можно ли, например, установить некое ПО типа особого VPN с избыточностью в паре с таким же ПО на своём сервере, и таким образом пересылать по несколько пакетов UDP (завёрнутых в свои пакеты, чтобы различать дубли)? Хотя бы в теории?
Dimonchik, а зачем упоминать Питон, если вы не уверены, что в нём тоже есть strip html tags? Тогда уж было бы логично посоветовать воспользоваться PHP, там-то уж точно есть.
К слову, для подобных ситуативных задач даже не нужно ничего устанавливать, сейчас полно онлайн компиляторов (например, этот).
