WC3
Добавлен Cancel
Что лучше, надёжнее и быстрее?
Работать с группами юнитов: при их добавлениии, проверки наличия, удалении и т. д.
Может, в каких-то ситуациях лучше работать с группами, а в каких-то - с таблицами?
Или создавать структуры, и работать с ними?
Или создавать структуры, и работать с ними?
Если кто-то проводил тестирование в разных ситуациях и/или находил подводные камни двух подходов - поделитесь, пожалуйста.
Интересно знать про рабготы с огромными данными, если в проекте огромное количество групп(или таблиц), в каждой может быть много юнитов, проверки на наличие юнитов в списках происходят постоянно, постоянно происходит добавление и удаление юнитов из списков.
А-ля:
units = {}
table.insert( units, unit )
function isUnitInTable(table, unit)
for k, v in pairs(table) do
if v == unit then return true end
end
return false
end
if isUnitInTable( units, unit ) then
--это выполнится
else
--а это не выполнится
end
Принятый ответ
Hate:
сортированный список
Сортированный не есть упорядоченный. Перед тем как токсичить без причины стоит хотя бы с терминологией ознакомится.
те более если использовать пейрсы как в вашем примере, это путь к десинкам
pairs - это просто функция, которая возвращает функцию next, переданную таблицу и nil. Если у таблицы есть метаметод __pairs, то вызывается он. Таким образом, добавляется метаметод и никаких десинков нет.
отссылая в гугл
Он отослал не в гугл, а на страницу вики от юзеров луа. Но это всё же такой себе источник. И как я уже сказал, pairs вообще не при делах. Всё дело в функции next. Цитата из официальной документации Lua 5.3:
Allows a program to traverse all fields of a table. Its first argument is a table and its second argument is an index in this table. next returns the next index of the table and its associated value. When called with nil as its second argument, next returns an initial index and its associated value. When called with the last index, or with nil in an empty table, next returns nil. If the second argument is absent, then it is interpreted as nil. In particular, you can use next(t) to check whether a table is empty.The order in which the indices are enumerated is not specified, even for numeric indices. (To traverse a table in numerical order, use a numerical for.)The behavior of next is undefined if, during the traversal, you assign any value to a non-existent field in the table. You may however modify existing fields. In particular, you may clear existing fields.
Таким образом, порядок может быть идентичен на разных машинах, а может быть и не идентичен. Поэтому изначальное утверждение Hate правдиво:
что на одном компьютере будет A, B, C а на втором C, B, A
Что касается самого вопроса. Удобство таблиц в том, что их не надо удалять функцией, но нужно реализовать уникальность юнитов. На HIVE есть готовая библиотека, которая включает в себя переписывание нативок для групп юнитов, точек, ректов и групп игроков на таблицы. Краткое описание библиотеки от автора, Bribe:
Most recently, I've revamped the old GUI Fixer Collection to a much more powerful tool: Lua-Infused GUI. Since GUI variables don't actually require strict type assignment when compiled into Lua, I was able to change Locations, Rects, Unit Groups and Player Groups into Lua tables, allowing them to consume an order of magnitude less RAM and be automatically cleaned up by Lua's garbage collector.
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
Отредактирован Cancel
Inside a pairs loop, it's safe to reassign existing keys or remove them (by assigning nil to them), but not to add new keys (that had a nil value previously).
Знаешь почему?
Потому что это для тебя ключи беспорядочны, а для системы они упорядочены в байтовом представлении, это нужно для того, чтобы быстрее осуществлялся поиск ключей системой.
Отредактирован Cancel
Не стрнёмно чего-то не знать.
Знаешь что стрёмно? Стрёмно выдавать неподтверждённую инфу как кладезь знаний, а потом ещё и не признавать огда обсираешься. Вот это уже признак идиотизма.
Я не поленился, вытащил людей, чтобы устроить стресс-тест в варике, и знаешь что? Последовательность значений всегда была одинаковой.
Я использовал в качестве ключей и индексы, и юнитов, и даже другие таблицы, с разной степень вложенности - и летает на ура.
Может, конечно, я не проверял какие-то особые ситуации. Как я подчёркивал выше, я не обладаю всей экспертизой, и потому запросил кейсы (если человек что-то утверждает и обвиняет других в глупости, то явно же он не настолько глуп, чтобы не иметь при этом пруфов, верно?)
Но нет, человек продолжил обсираться, хотя если он прав - доказать это достаточно просто - привести хотя бы один кейс, пример, по которому паирсы вызывают десинку. Но он этого не сделал. А знаешь почему? Потому что балабол, который считает, что раз он на этом сайте находится долго и его тут многие уважают, то может нести вскую пургу и агриться, если его мнение подвергается сомнению.
И знаешь что? Тексты действительно вызывают десинки если установить первого юнита взяв за основу имя второго юнита если ты играешь с пользователями, использующими разную локализацию.
Ты это знал? Я вот не знал. Столкнулся, искал, нашёл. И смысл раскапывать старые темы? Что он этим пытался доказать?
Мне, как пещерному человеку, хватает дефолтного редактора.
Если в каких-то определённых кейсах паирсы вызывают проблему, хотелось бы отловить эти кейсы.
Если я с таковыми встречусь - обязательно дам знать.
Также буду благодарен, если кто-то поделится конкретными кейсами использования, после которого начинают происходить проблемы.
Пока что могу сказать, что у меня все данные в карте хранятся через вложенные таблицы, часть из которых используют в качестве ключей самые разные данные - от строк до юнитов и таблиц.
Пересчёты происходят регулярно и в больших объёмах.
если ты решаешь что делать с юнитами например, кого то похилить, или подвинуть. это все меняет логику игры
Отредактирован Cancel
Но - буду тестировать ещё.