Маленькое задание: описать несколько территорий и точек.

Теги:
 
+
-
edit
 

Balancer

администратор
★★★★★
1. Нужны территории входных комнат замков C5. А то C4 есть с офа, этих - нет. Что у нас там, Rune, Goddard, Shutgart?

Наборы точек { xxx yyy xx }

2. Нужно несколько точек внутри тронных залов каждого замка (или куда должен выкидывать Mass gatekeeper?). Всех, так как даже в оф. данных C4 я их не нашёл.

Формат { { x1 y1 z1 h1 } { x2 y2 z2 h2 } ... } для каждого замка.

Результат можно закинуть прямо сюда,
 
+
-
edit
 

phoptik

разработчик L2J Fortress

3. Стырить зоны Олимпиад у сф :)
 
+
-
edit
 

Balancer

администратор
★★★★★
3 - это в другой топик :) Олимпиады я ещё не смотрел.

А что, в SF, наконец, появились непрямоугольные зоны? :)
 
+
-
edit
 

phoptik

разработчик L2J Fortress

Я не смотрел какие они там, просто заметил недавно что они там есть :)
 
UA SoulKeeper #22.05.2007 01:33  @Balancer#18.05.2007 15:59
+
-
edit
 

SoulKeeper

разработчик L2J Fortress

Balancer> А что, в SF, наконец, появились непрямоугольные зоны? :)

Размечтался :D
Разыскивается десятка с два датапакеров :) http://la2.wrk.ru/forum/viewtopic.php?id=50882  
+
-
edit
 

Empire

новичок
phoptik> 3. Стырить зоны Олимпиад у сф :)

Ну да, хех, как обычно обмен програмным кодом между версиями :D

Balancer> А что, в SF, наконец, появились непрямоугольные зоны? :)

А что, вообще как можно реализоваться не прямоуголные зоны? относительно БД записи...ну это очень коряво будет если вообще получится. Ну а в коде можно будет сделать многоугольник. Пока сам не представляю как, но если получится у меня будет первый сервер использующий новую систему :D
 
UA MorbidAngel #22.05.2007 13:06
+
-
edit
 

MorbidAngel

разработчик L2J Fortress

Далеко не первый....

А не прямоугольные жоны не так уж и сложно хранить в базе, главное правильно записать последовательность точек, чтоб не получились самопересеченные многоугольники
 
UA SoulKeeper #22.05.2007 13:35  @Empire#22.05.2007 07:56
+
-
edit
 

SoulKeeper

разработчик L2J Fortress

Empire> А что, вообще как можно реализоваться не прямоуголные зоны?

Копать в сторону jawa.awt.Polygon
Разыскивается десятка с два датапакеров :) http://la2.wrk.ru/forum/viewtopic.php?id=50882  
+
-
edit
 

Balancer

администратор
★★★★★
Empire> А что, вообще как можно реализоваться не прямоуголные зоны?

Я их реализовал в SF (!) года полтора назад :D Когда я уходил, на них были только реализованные мною территории спавна. Дальше их уже не развивали...

А тут подумал, вдруг, таки, у них и зоны сделали.

У нас же зоны (с параметрами) непрямоугольные ещё с прошлого года. Только многих данных нормальных ещё не хватает. Потому - и сабжевое задание, например.
 
RU Balancer #22.05.2007 13:56  @MorbidAngel#22.05.2007 13:06
+
-
edit
 

Balancer

администратор
★★★★★
MorbidAngel> главное правильно записать последовательность точек, чтоб не получились самопересеченные многоугольники

Не только несамопересечённые, но и вообще, чтобы неверные не вышли. В общем, порядок точек - исключительно в порядке их обхода. Как выяснилсь, задача построения полигона из случайного набора точек в общем случае единичного решения не имеет и обладает чрезвычайно высокой сложностью (вплоть до O!).
 
+
-
edit
 

Empire

новичок
Хм, я ещё ламер в Java, но плохо, что в ней нету динамических массивов :(

А то можно было бы оформить новую систему админу. Типа включил полную синхранизацию сервера и клиента, идёшь в нужную точку -> набераешь какую нить команду -> твоя точка записана в память -> идёшь в другую точку и так же набераешь команду -> короче обходишь нужную зону, потом набераешь спец команду и система сама объединяет конечную точку с первой и реализует многоугольник через массив эллементов (многомерный массив) (все предыдущие точки соединяются по последовательности). Бд, бд, а нафиг БД ? я так подумал - а чем плохи сами файлы - реализовать запись типа стринг (ну о выводе и вводе подумать можно)

У меня именно тут возникает проблема жёского объявления размера массива и не возможности его изменять. Можно реализовать это через что нить другое (типа записи в строку) и чтения длины и параметров и потом уже по их колличеству объявлять размер массива - но блин муторно, долго и ресурсоёмко такое убожество.

Или есть другие идеи? я вообще в яве тока 2-3 месяца - так что много чего не знаю...
 
+
-
edit
 

Balancer

администратор
★★★★★
Empire> но плохо, что в ней нету динамических массивов :(

Их роль выполняют списки. List. И масса их наследников - ArrayList, FastList и т.п.

Empire> Типа включил полную синхранизацию сервера и клиента, идёшь в нужную точку -> набераешь какую нить команду -> твоя точка записана в память

Есть вариант лучше. Команда //point>file добавляет твои текущие кординаты в файл data/jbforth/points.f

>Бд, бд, а нафиг БД ?

За тем, что уже сейчас на сервере почти 41 тысяча точек разных территорий. Грузить их из файла - это маразм :)

А вот небольшие фиксы и вручную сделанные компоненты территорий для эвентов или квестов можно и из файлов грузить. Форт это позволяет (более того, первые зоны делались именно на нём).

Empire> У меня именно тут возникает проблема жёского объявления размера массива и не возможности его изменять.

Ну, во-первых, даже размер массива можно менять. Но это неэффективно и криво. Во-вторых, я уже сказал - см. в сторону списков.

Empire> Или есть другие идеи? я вообще в яве тока 2-3 месяца - так что много чего не знаю...

За 2-3 месяца можно язык оченб неплохо выучить :)
 
+
-
edit
 
>>Бд, бд, а нафиг БД ?
Balancer> За тем, что уже сейчас на сервере почти 41 тысяча точек разных территорий. Грузить их из файла - это маразм :)
Balancer> А вот небольшие фиксы и вручную сделанные компоненты территорий для эвентов или квестов можно и из файлов грузить. Форт это позволяет (более того, первые зоны делались именно на нём).
Надо же, а не так давно кое-кто вопил что зоны и локации надо делать на форте и только на форте, и пофиг на то сколько десятков тысяч файлов получится... Не помнишь кто это был?
Пытаясь понять рекурсию, следи за тем, чтобы она не поняла тебя первой...  
+
-
edit
 

Balancer

администратор
★★★★★
Abaddon> Надо же, а не так давно кое-кто вопил что зоны и локации надо делать на форте и только на форте

Мне раскопать те логи? :D Я во время того обсуждения, мало того, что про себя ржал на счёт вашей невнимательности, так ещё раз 5, наверное, на вашу невнимательность указывал...

В общем, маленький такой тест был...

Впрочем, не поленюсь, вот покопаться:
[2007-04-07 21:10:16] Balancer: Diamond: посмотрел
сейчас на офовские территории. В одном ты прав - соответствие типа зоны и его имени лучше хранить в БД. Они слишком
однотипные, на Форте будет масса пустого кода. Вот параметры зон, где они есть - их лучше на Форте оставить.
Ты на тестовый все свои наработки по этому вопросу положил? Потому что я пока кроме собственно твоей таблицы
БД так ничего и не увидел. Даже загрузчик таблицы - старый, ещё SF-овский.
 


Сами же точки территорий, о которых весь спор был - это вообще смешно. Вспомните кто и когда заводил таблицу locations :D И кто был её единственным пользователем (на уровне разработки) около двух лет.

В общем - не позорьтесь, ибо у меня все ходы записаны а у некоторых бывших разработчиков была мания читать то, что хочется видеть, а не то, что было написано.
 
+
-
edit
 
Значит про фортовые территории мне привиделось?
Пытаясь понять рекурсию, следи за тем, чтобы она не поняла тебя первой...  
+
-
edit
 

Balancer

администратор
★★★★★
Abaddon> Значит про фортовые территории мне привиделось?

Безусловно. Ибо мои выводы по этому вопросу я процитировал выше.

И ты их не мог не читать, ибо ты на них ответил:

[21:10:49] <abaddon> оно еще не закоммичено
[21:10:59] <abaddon> ночью будет
 
 
+
-
edit
 
Ага... теперь вспомнил контекст.

Ты предлагал химеру сотворить, у которой потом концов не сыщешь.

code forth
  1. '[20_19_worldtree]'     =>      name
  2. '{20;19}'       =>      map_no
  3. 'mother_tree'   =>      type
  4. 'elf'   =>      affect_race
  5. '114'   =>      entering_message_no
  6. '115'   =>      leaving_message_no
  7. { { 21101 50538 -3745 -3545 }
  8. { 21511 50683 -3745 -3545 }
  9. { 21642 51005 -3745 -3545 }
  10. { 21583 51349 -3745 -3545 }
  11. { 21255 51581 -3745 -3545 }
  12. { 20852 51473 -3745 -3545 }
  13. { 20627 51121 -3745 -3545 }
  14. { 20728 50743 -3745 -3545 } }   =>      range


Вот такого вида оно было на тот момент. Ты предлагал так и делать дальше - по файлу на территорию. Дайм предлагал хранить полностью в БД.

И вот что интересно, все тебя поняли вполне однозначно.
Пытаясь понять рекурсию, следи за тем, чтобы она не поняла тебя первой...  
+
-
edit
 

Balancer

администратор
★★★★★
Abaddon> Вот такого вида оно было на тот момент.

Ты бы хотя бы посмотрел, кем, когда, и на каком уровне оно было сделано :D

Changeset 3680 – L2Fortress

Changeset 3680
Timestamp:
17.08.2006 19:34:31
(5 years ago)
Author:
kuta


// Дальше —
trac.balancer.ru
 

Timestamp: 08/17/06 19:34:31 (9 months ago)
Author: kuta

Вот уж воистину...
 
+
-
edit
 

Balancer

администратор
★★★★★
Abaddon> И вот что интересно, все тебя поняли вполне однозначно.

"Все" - это ты и Diamond.

Что же, это только лишний показатель того, насколько вы вчитываетесь в то, что вам пишут.

«В одном ты прав - соответствие типа зоны и его имени лучше хранить в БД. Они слишком однотипные, на Форте будет масса пустого кода.» - это однозначно означает, что всюду будет использоваться Форт? :D

Это уже что-то в вашей консерватории править нужно :D

А я потом не раз тыкал вас носом в то, что идея о переводе всей системы локаций на Форт - это ваша фантазия.
 
+
-
edit
 
Было бы интересно прочитать весь лог.
Пытаясь понять рекурсию, следи за тем, чтобы она не поняла тебя первой...  

Drac

разработчик l2j-сервера

Даже kuta вспомнили :) ПО-моему, он первый всерьез затронул зоны и начал их описывать, жаль так и не дошли до зон в замках.
 

Diаmond

втянувшийся

Drac> Даже kuta вспомнили :) ПО-моему, он первый всерьез затронул зоны и начал их описывать, жаль так и не дошли до зон в замках.
Фортовые зоны делал kuta и я. Balancer делал основу. После нескольких месяцев их использования - поняли что ошиблись с форматом. Неудобно редактировать и добавлять новые, сложно найти нужное. А фортовый код получился слишком запутанным и трудным для понимая, даже для авторов.
Вообще - форт для программ не крупнее 500 строчек, дальше начинает рябить в глазах :)
 
+
-
edit
 

Balancer

администратор
★★★★★
Я миллион раз говорил основное Фортовое правило: размер слова не должен превышать 7±2 токена. Это основы даже не программирования, а психологии (вообще, у Форта очень много уделено вопросу психологического восприятия).

Сам, правда, правило это нередко нарушаю. Сказывается отравленность традиционными языками :D
 

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru