парсер спавна
- Автор темы adastmin
- Дата начала
И? Я что говорил что его там нет? В одном месте для этого используются ai параметры, в другом месте используется отдельный атрибут, хотя в npcpos имеется возможность передавать ai параметры npc которого спавнишь. Это они так следуют своей же логике хранения? Вы видимо намерено упустили этот момент.
Ты сам себе противоречишь, то нету то уже есть, в птс скриптах + АИ есть почти все что нужно для того ЧТОБ МОБ СТОЯЛ и у него были миньены при любых условиях сразу или со временем или при смерти или при ударе и куча вариаций. Было бы желание и это явно лучше чем парсить визуал с игры. Тут вообще пофиг на структуры мозг и руки любую структуру сделают такой какая тебе нужна. повторяюсь было бы желание.
В чем противоречие? Я же сказал что лично мне не нравится в подобном формате хранения. Потому что один и тот же параметр/структура данных, в 2 файлах записывается по разному. Гибкость не гибкость. Куда бы она исчезла, если бы в npcpos передали миньенов через ai_parameters как это сделано в npcdata? или наоборот?
Ну и объясните мне, почему в одних местах разделителями в списке является точка с запятой, в других двоеточие? Это просто больные фантазии людей, которые писали это лет 20 назад, а вы теперь сидите и рассказываете как прекрасно хранятся данные в этом формате, который с трудом парситься даже, так как тебе постоянно приходится затыкать эти не логичности. Как только ты думаешь что ты понял логику, с двух ног залетает ошибка парснига, потому что какой-то кореец решил что вот именно в этом файле, список, именно в этом атрибуте я буду разделять двоеточием, а не точкой с запятой. Хотя было бы это к примеру в xml формате, никто бы даже не задавался вопросом, а как это парсить, так как практически любой язык программирования имеет либо встроенный функционал для работы с xml, либо имеет либы для работы с ним.
И да, я всё еще жду когда вы покажете в каком месте я это говорил, а то не красиво получается, вы строите все свои доводы в споре на собственной выдумке.
Что, так всё плохо с xml?как проклятый джавист, заявляю.....птс формат хранения данных....гораздо пизже привычного xml на явах
Аксиома Эскобара. Оба варианта, в контексте среднестатистической разработки - мусор т.к. если не по факту, то по сути предполагают наличие хоть какой то граф. оболочки для взаимодействия с ними, а не работу в блокноте.как проклятый джавист, заявляю.....птс формат хранения данных....гораздо пизже привычного xml на явах
Если допустить наличие софта, который удобно сгенерирует тебе условную строчку датапака - теряется вся разница в методах хранениях.
А если речь о скорости работы - то тут можно размусоливать это всё и на язык программирования и на то, кто писал ПО - 5000 корейцев с высшим образованием или рандомные челы с ява-эмулём. Да даже если она и есть - какой то фатальной разницы во времени между загрузкой ПТСа и явы нет, так что подобные рассуждения тоже не особо оправданны.
Мне приятней xml, потому что читать его можно без танцев с бубном и написанием своих самопальных парсеров.
Прямиком из архива слитых скриптов + файлы конфигурации)
На время загрузки не влияет, согласен. Но на время работы со скриптами - влияет.
По мне так проще работать с данными в хмл, чем с форматом данных в птс. Хотя конечно у каждого свои предпочтения.
Но опять же для работы с хмл куча библиотек и т.п. есть почти в любом языке программирования - я обычно в php хмлки обрабатываю (так просто исторически так сказать сложилось ) и там к примеру считать хмлку и представить ее в виде объекта можно по сути одной единственной функцией. А потом делай с получившимся объектом что хочешь.
да и в банальном блокноте достаточно просто хмлки править, а если хочется более продвинуто например что-то в данных менять не прибегая к написанию скриптов на php или еще чем-то, то можно использовать например UV Files Corrector / SelectFromXML или аналогичные тулзы.
Но опять же для работы с хмл куча библиотек и т.п. есть почти в любом языке программирования - я обычно в php хмлки обрабатываю (так просто исторически так сказать сложилось
) и там к примеру считать хмлку и представить ее в виде объекта можно по сути одной единственной функцией. А потом делай с получившимся объектом что хочешь.да и в банальном блокноте достаточно просто хмлки править, а если хочется более продвинуто например что-то в данных менять не прибегая к написанию скриптов на php или еще чем-то, то можно использовать например UV Files Corrector / SelectFromXML или аналогичные тулзы.
Разрабатывая свою яву и постоянно копаясь в птс-скриптах в поисках инфы и\или парся их, пришел к выводу, что вообще пофиг какой формат - ява или птс. Привыкаешь, и они уже одинаково удобны. В копилку плюсов птс-формата добавлю, разве что, тот факт, что там формат одинаков для всех птс-ок, в то время как у разных ява-сборок может отличаться структура сборки и структура самих файлов, данные могут храниться совсем по-разному.
P.S. Немного рофла. Думали-думали с напарником, в каком формате хранить скиллы в своей яве, и пришли к вот такому
P.S. Немного рофла. Думали-думали с напарником, в каком формате хранить скиллы в своей яве, и пришли к вот такому
Парс дропа с клиента? Интересно как?
