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

[unknown22 1]

16 минут назад, Rogue сказал:

Да и готов поспорить они все как под копирку и тоже хз как работают)

ну базовые то основы должны быть уже давно  нормальные и проработанные.
что бы мобы не лагали как в кс, дроплист/спавн лист был адекватный. я так понимаю там наверное еще и есть мобики с который спойлится по надцать штук какого нибудь КБП вместо нескольких штук. а то и просто дропаются с шансом спойла.

[Rogue 248]

6 минут назад, unknown22 сказал:

ну базовые то основы должны быть уже давно  нормальные и проработанные.
что бы мобы не лагали как в кс, дроплист/спавн лист был адекватный. я так понимаю там наверное еще и есть мобики с который спойлится по надцать штук какого нибудь КБП вместо нескольких штук. а то и просто дропаются с шансом спойла.

Ну я бы не был так уверен. Самый банальный пример - форс атака по персонажу. Да хрен где ты найдешь сурсы, где она сделана нормально. Везде автоатакой перс дубасит форсом)

[Hotaka 769]

Как же ты жид достал! Хочешь и рыбку съесть и руки не испачкать. Нужны нормальные исходы? Покупай их! Нет денег? Бери шаровые сурсы и хотя бы 1 день попили их, чтобы потом говорить какие они все плохие и дырявые, а ты такой вот тру кодер исправляешь недоработки бывшего разраба и устаешь от количества работы

[Rogue 248]

51 минуту назад, Hotaka сказал:

Как же ты жид достал! Хочешь и рыбку съесть и руки не испачкать. Нужны нормальные исходы? Покупай их! Нет денег? Бери шаровые сурсы и хотя бы 1 день попили их, чтобы потом говорить какие они все плохие и дырявые, а ты такой вот тру кодер исправляешь недоработки бывшего разраба и устаешь от количества работы

У кого ты купишь исходы нормальные интересно знать? Сейчас модно только "на дойку" клиентов подключать)

Ну либо толкать старую шару.

Изменено 24 марта, 2020 пользователем Rogue

[Gaikotsu 620]

5 часов назад, Rogue сказал:

В SQL удобно только спавнлист оставлять.

ИМХО из бд вобще все хранение статики есть смысл выпиливать и переводить на хранение в XML ибо это банально удобней в плане той же расширяемости и т.д.

Расширяемости в плане добавления к примеру новых свойств тех же спавнов например.

В случае с бд к примеру это потребует добавления еще столбцов в таблицу, даже если новые свойства нужны будут не очень большому количеству нпс/мобов.

Можно конечно извратиться и вместо добавления новых столбцов в таблицы спавнов писать отдельные аи для нужных нпс/мобов и там задавать нужные свойства, но как быть в случаях когда для части спавнов свойства должны быть одни, а для части - другие? Можно конечно городить условия в аи, определяя по координатам конкретные спавны, но это же изврат...

Тогда как в XML при желании можно тонко настраивать отдельные спавны одного и того же нпс, и он в зависимости от этого будет вести себя по разному.

Чисто для примера - 4 спавна одного и того же нпс (невидимого нпс 18919 вобще любят корейцы использовать в куче мест, как контроллеры различных событий в локациях), действующего по разному в зависимости от конкретного спавна:

	<spawn count="1">
		<npc id="18919">
			<set name="ai" value="superion.EnhancedBossController" />
			<set name="index" value="1" />
			<set name="normal_boss_id" value="26137" />
		</npc>
		<point x="191960" y="56420" z="-7630" />
	</spawn>
	<spawn count="1">
		<npc id="18919">
			<set name="ai" value="superion.EnhancedBossController" />
			<set name="index" value="2" />
			<set name="normal_boss_id" value="29006" />
		</npc>
		<point x="17740" y="109670" z="-6480" />
	</spawn>
	<spawn count="1">
		<npc id="18919">
			<set name="ai" value="superion.EnhancedBossController" />
			<set name="index" value="3" />
			<set name="normal_boss_id" value="25772" />
		</npc>
		<point x="-114712" y="150450" z="-13870" />
	</spawn>
	<spawn count="1">
		<npc id="18919">
			<set name="ai" value="OmegaGolemSpawner" />
			<set name="targetable" value="false" />
			<set name="undying" value="true" />
		</npc>
		<point x="199482" y="84497" z="-191" />
	</spawn>

А насчет "сложностей массового изменения данных" в XML я даже не парюсь - мне не сложно в том же пхп по быстрому накорябать скриптик, который мне все что необходимо в хмлке поправит, благо хмлку в пхп загрузить в память в виде объекта, с которым после этого можно делать что угодно, можно буквально одной строчкой. Обратное сохранение измененного в виде хмл тоже особой сложности не составляет - уж один раз написать функцию сохранения этого самого объекта в файл как небходимо написать несложно...

Изменено 24 марта, 2020 пользователем Gaikotsu

[unknown22 1]

В 24.03.2020 в 18:56, Rogue сказал:

У кого ты купишь исходы нормальные интересно знать? Сейчас модно только "на дойку" клиентов подключать)

Ну либо толкать старую шару.

ну вот он и пытается развести на дойку подобными сообщениями.
 

[unknown22 1]

В 24.03.2020 в 19:06, Gaikotsu сказал:

ИМХО из бд вобще все хранение статики есть смысл выпиливать и переводить на хранение в XML ибо это банально удобней в плане той же расширяемости и т.д.

Расширяемости в плане добавления к примеру новых свойств тех же спавнов например.

В случае с бд к примеру это потребует добавления еще столбцов в таблицу, даже если новые свойства нужны будут не очень большому количеству нпс/мобов.

 

вы очень ошибаетесь)). xml или бд - это лишь метод хранения данных, что можно сделать в xml, можно сделать и в бд, абсолютно так же. только бд добавляет быстродействие и широчайшие возможности по модификации и доработке.  xml же не дает ничего.

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

 

не надо извращаться и придумывать велосипеды, это все было придумано еще в начале нулевых.

и не надо более спорить. я вам все написал еще в прежнем сообщении. но вы проигнорили. я не смогу вам что либо доказать.

Изменено 26 марта, 2020 пользователем unknown22

[Hotaka 769]

1 час назад, unknown22 сказал:

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

Если на то пошло, то в xml в большинстве нормальных сборок хранится как раз то, что должно являться статическим в принципе - спавн, дроп, статы. Это статические показатели для определенных хроник для дефолтных рейтов(х1), которые прописанны не мной и не вами в офф базах по соответствующим хроникам, а изменение их, это уже не фикс самой сборки, а её перепиливание под свои нужды и хотелки. Если ваши хотелки по изменению дефолтных показателей(спавн, дроп, статы и  т.д) не настолько велики насколько велика ваша лень перед редактированием xml то берите что-нибудь типа исходов over-ов и пилите их. Если лень перед работой на своём же сервере сильнее хотелок берите исходы а-ля lucera 1.7 или frozen