†DeMoN†™

Азино добралось и до л2, что-то пошло не так. @OrmJevil они тебя проплатили?

Интересно мнение других java-разработчиков (в т.ч. любительского уровня). Надеюсь найдутся люди, с которыми можно подискутировать на данную тему. На яве не программировал более года++, последний релиз, который я застал, была java 8. Это был реально прорыв в системном java-программировании. Те же монады, которые позволяли уменьшать и оптимизировать код в разы. Но, смотря на 9й релиз, ощущение чувства уныния. Более 90% проектов на яве - это системное программирование. В целом, в веб программировании, 80% занимает PHP, остальное: большую часть занимает python (django), ну и оставшиеся разделяют +- определенные %. Не понятно, зачем было тратить столько времени и ресурсов на поддержку веба, ведь и так понятно, что максимум, что там можно занять - какую-то небольшую нишу. Далеко не все хостинги предоставляют поддержку jvm, стоят такие хостинги, насколько мне известно, дороже. Java web community не такое уж и большое, в отличии от того же PHP. Есть, конечно, и улучшения в системной части, но на 9 реву ну это никак не тянет. Jshell, по моему мнению, самое большое разочарование. Тупо копипаст "php -r", который, опять же, на мой взгляд, не так уж и нужен. Для этого уже давненько существуют онлайн сервисы. Хотелось бы видеть чего-то большего... А какие у вас мысли, по данному релизу?

Всё зависит от конкретной реализации. Если тупо фарм мобов - то да, в onKill будет наилучшим вариантом. Но, опять же, зависит от % дропа. Если маленький - то не особо вариант. Смысл обрабатывать каждого моба, если далеко не факт, что с него что-то упадёт. (Если реализация через обычный дроп). Если через скрипт - то да.

Если уж просите помощи на форме - хотя бы предоставляйте полную информацию. Хроники, локализацию. Есть разные кодировки, разные параметры и т.д.

Тоже вариант, но, О - оптимизация

Да, та ещё ностальгия, где мои 20 лет) Тоже приятно видеть старых знакомых. Да ещё тех, которые тебя помнят спустя столько лет)

Самый простой вариант, учитывающий все события (обмен между игроками, поднятие дропа и и.д.) - идём в функцию выдачи игроку предмета, добавляем проверку на ид предмета (чтобы лишний раз не делать тонну обработок), если ид нужный нам, берём пспоинты из инвентаря юзера, складываем с выдаваемым значением, если больше тысячи, то удаляем из инвентаря количество = 1000-count. Выдаём адену, например, и прерываем дальнейшую выдачу ретёрном. Можно дополнить формулой и динамической обработкой, чтобы менять все количество, в случае получения их в большем количестве.

Ого. Макс, ты там не здох ещё? Блин, меня тут почти 5 лет не было, а ничего толком не меняется, всё те же знакомые личности и всё в той же старой доброй сфере л2. P.S. по теме, рекомендую данного человека, даже в неразвитые времена сферы л2 у него были отличные работы, думаю с годами он навыки ещё больше отточил

На рабочих компах стоит убунта для разработки на вебе. GUI очень удобный. Если не нужен GUI - то debian ставлю. У убунты вечные проблемы (иногда не непосредственно у неё, а у софта), например, на хроме, при установке расширений, вся система начинает виснуть. Вначале думал возможно проблема только у меня, а оказалось, что у половины нашего офиса, пришлось всё вырубать. А так - вечные их баги и косяки с дровами. Но, даже с её недостатками, не променяю её

Как вариант, можно сделать костыль. Сделайте классовые скиллы каждой рассе/классу, которые будут выравнивать характеристики

В свое время разрабатывали мод по типу ГВЕ с подобной штукой на одной приватной сборке ХФ там статы были в xml файлах. Но так же присутствовала таблица с характеристиками, неактивная. Может у вас такая же ситуация. Либо "особенность" сборки.

Ещё в далёком 2к11 году обходились без исходников. А вы всё ещё над ними трясётесь. А по теме: 1. Берем декомпилятор (в те времена был крут JD-GUI, в нынешних реалиях уже не в курсе) 2. Декомпилим 3. Убираем ненужное 4. Правим косяки декомпила (ОПЦИОНАЛЬНО, если оные появились) 5. Компилим класс с указанием патча на изначальную либу 6. PROFIT.

На некоторых сборках есть псевдо веб-сервер через протокол RPC. Хорошее решение в сочетании с кешем. Возможно и у вас такой есть. Либо подключить доп. библиотекой.

Насколько помню, в л2 используется BGR формат цвета, в HTML - RGB. У вас в скрипте он устанавливается напрямую, преобразования там не увидел. Поменяйте 1-2 и 4-6 части кода цвета местами. А вообще, у РТ помню был хороший чейнджер с кучей цветов, но он там вроде генерацией в цикле делался.

Просмотр файла aCis 371 Build, Source, Diff Changeset 371 (821) Datatype reorganization, Skill stuff, Misc Datatype reorganization - MapRegionTable > MapRegionData - Javadoc, extends XMLDocument, moved to data.xml, edit for mapRegions.xml. Drop useless methods. - PlayerNameTable > PlayerInfoTable - Javadoc, moved to data.sql, DataHolder > PlayerInfo. - DoorTable > DoorData - Javadoc, extends XMLDocument, moved to data.xml, StatsSet reuse, writting style. - RecipeTable > RecipeData - Javadoc, extends XMLDocument, moved to data.xml, StatsSet used for Recipe, RecipeList > Recipe. Extract RecipeItemMaker from RecipeData, and create model.craft package to store it. - The data is reparsed using L2OFF data. - Fix an issue with recipe name when destroying such recipe from book (was the case for Orcish Poleaxe for example). - Rework character_recipebook table, dropping one column. Datatypes are tweaked. - Fix an issue on complete recipe book destroy ; the deleted stuff wasn't saved on database. - Rework RecipeBookItemList packet. Add a missing use of it on Recipes itemhandler (refresh book or open it on recipe addition). - CharTemplateTable > PlayerData - Skill trees are now stored directly into player templates under a List, rather than SkillTreeTable. Most methods are moved into Player, since its a generic needed parameter. - We don't store anymore Item template list (for character creation items generation), but int array (since storing Item templates was pointless and not even used correctly). - All methods got a "single" and "all" versions to avoid to loop for nothing on all skills. - SkillTreeTable > SkillTreeData - Rework all skills holders, and move them on model.skillnode - All methods got a "single" and "all" versions to avoid to loop for nothing on all skills. - BufferTable > BufferManager - Use XMLDocument, move to data package, rename/cleanup. Data is edited to reflect changes. - Add an integrity check for available skills on player schemes loading to avoid NPE. Ty katara. Skill stuff - Drop getSkillLearningClassId / setSkillLearningClassId concept. - Drop _expertiseIndex. It is now directly calculated from skill 239 level, and can be found using getSkillLevel(). - Rework subclass skills addition. We only storeSkill the final List, leading to a massive drop of mid-operations. Ty vladalien for the initial workbench. - Cleanup removeSkill() / storeSkill(). - autoGet skills are handled by PlayerTemplate data (skills with getSpCost == 0), the stuff isn't hardcoded anymore. - getSkillLevel returns 0 instead of -1 if no skill is found, making checks easier to write. - hasSkill is used instead of getSkillLevel when skill existence is needed, but we don't specifically need the level. - Skill enchantable routes now handle level 79 and 80. Each route can be manually edited. - Fix a visual issue about shortcut refresh on failed enchant skill. Misc - Drop RATE_CONSUMABLE_COST && ALT_GAME_SHIELD_BLOCKS configs. Rename some players.properties configs. - Addition of StatsSet getIntIntHolder, getIntIntHolderList && getDoubleArray. - Fix an issue using a toggle when you run to a target with ATTACK intention. Ty Sahar. - getCurrentFolkNPC() -> getCurrentFolk(). The value retained is now a Folk, not a Npc. - Fix an issue on RequestAnswerJoinAlly introduced on rev 366, ty sahar. - Region size decreases from 4096 to 2048 (x4 WorldRegion amount, vision is reduced from 6k to 3k max). It now fits retail knownlist range. - Fist Weapon is moved from Player to PlayerTemplate (no calculation needed anymore on player login). - Formatting rule for lambdas && try-with-ressources. Use lambda writting style for all Runnable. - Cleanup L2Request > Request, keep a reference of the task to cancel it on onRequestResponse(). - RequestRestartPoint doesn't use anymore a Runnable for instant use. - Drop door onEvtAttacked behavior, which was adding a ridiculous amount of operations for nothing. - RequestCrystallizeItem packet is cleaned up (avoid getItemByObjectId x2, World.getInstance().removeObject is already handled). Добавил †DeMoN†™ Добавлено 05.12.2017 Категория Исходники серверов Автор Tryskell Хроники Interlude