ScorpioT1000:

на hash(key)

Ну ? ._. key != value, тем более в хт коллекция значений, к которым после можно обратится по 2-му кею. Какая тебе тут прямая адресация?

Прелоад нужно делать уже после загрузки карты. Но весь и сразу. Как бы карта загрузилась, но еще нет.

YellowStar:

Нет. У меня для удобства работы со способностями абилки имеют свои равкоды.

А ну тогда тебе нет понта юзать эту системку.

Faion добавил:
Toadcop:

ну 2 значения = хештейбл хештейблов ._.

ChildHastable(или как оно там называется), он же объект "коллекция", на которую ссылается key, после как раз в чайлде по 2-му ключу происходит обращение. Т.е. адресация последовательно происходит, от объекта к чайлду, от чайлда к значению :nate:

2 ключа просто для удобства сделали, они соединяются, возможно, просто конкатенацией, я могу тебе хоть миллион их сделать лол =)

ну допустим к1="12" к2="21" к3="999" получается "12_21_999", хешу насрать, что в него передают

ScorpioT1000:

2 ключа просто для удобства сделали, они соединяются, возможно, просто конкатенацией

Хз,я так тоже предполагал, но подтверждений этому предположению не нашел.

Faion добавил:
Toadcop:

ScorpioT1000, неа, они же чистятся по отдельносте вроде ?

native FlushChildHashtable takes hashtable table, integer parentKey returns nothing

ну да щас посмотрел там действительно 2 хештейбла видимо, но разговор не о том было, а о понятии "хештаблица"

ScorpioT1000:

ну да щас посмотрел там действительно 2 хештейбла видимо, но разговор не о том было, а о понятии "хештаблица"

Нет, на самом деле разговор был о том, оптимальнее ли разделять данные по разным хт или нет:)

так разделять или нет? вы уж решите чтоб люди знали

16GB:

так разделять или нет? вы уж решите чтоб люди знали

Разделять. Ибо варовская хт, это хт в хт, никакой прямой адресации там быть и не может.

И вообще, как я показал на 1 странице, лучше юзать UserData, а данные хранить в параллельных массивах.
Для каждой предметной области лучше юзать свою UserData, что б размерность массива была не слишком большой.

Впрочем какой то реально ощутимой разницы я думаю не будет. Т.е. это актуально именно если ты юзаешь UserData, ну или аналогичную системку.

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

ScorpioT1000:

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

Оптимальнее офк, потому что чем меньше элементов, тем меньше это "незначительное" количество.

/facepalm

А известно ли вам количество коллизий в хеш таблице допустим при 120 одновременно хранимых в ней ячейках, при 10, при 1? То главная проблема хештаблиц это коллизии это все и так знают, но близзы долго бились чтобы это устранить, вот насколько хорошо это у них получилось?
Некто не даже не обмолвился об этом Загадочном числе коллизий, и некто не доказал на примере насколько будет актуальнее использовать 10 хештаблиц или 1...
P.S пустые слова тут от чувака с кучей опыта мне как то доверия не внушают, вдобавок когда на него кричат чуваки с опытом чуть поменьше

Потому что никто не знает хешфункцию, если надо, иди учи ассемблер, дебаж.

quq_CCCP:

и некто не доказал на примере насколько будет актуальнее

говоришь так, как будто должны были :O

quq_CCCP:

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

И вообще, когда говорят пушки, ружья молчат.

Faion, ну а как реагировать на то что говорят про то что сами наверняка не знают, дак еже и других этому учат, если уж взялись всерьёз то докажите и покажите, почему так лучшее... что спорить то попусту?