Tryskell

L2J for a workable version. Correct implementation, none did it.

It's not implemented.

A custom where classes stack, generally set to 2, to benefit skills of two different classes. Generally set to same race class, but can be exotic too (notably because dwarves can only be Warsmith/spoiler otherwise). Most notable classes are SH/SK, Sps/EE for mages, HE/DA HE/Pal HE/Warlord for archer, TH/Pal for dagger, and destro/tyr. You should avoid to cumulate passive skills (notably masteries), because it scales really wrong, and you probably need to tweak buffs by a lot.

You're still and will probably forever be a showoff, so... Whatever. I don't get the purpose of the topic if you don't want to speak about what you did, actual numbers of your solution, or if there is nothing to test. I'm almost sure there are other solutions, way easier to manage and less disturbing for the player (enforcing players to switch proxies - the lagger simply have to switch of proxy too, enforcing other players to switch, or even, simply attack most if not all your proxies in same time, making all your players permanetly moving from one proxy to another). Anyway, you're probably happy to show your e-penis. I'm off the topic.

I don't see the point if things are already filtered before reaching the GS. iptables/whatever ddos mitigation already filters the bad traffic, therefore the load balancing isn't needed. For the regular packets send, even on big players amount, an asynchronous mmocore is probably the only answer, and probably far enough. Finally, can't you use existing solution rather than trying to implement solutions working only for L2 ? As I said, it remembers me "self coded firewalls" for Lineage 2 than RU forks add. NGINX doesn't make the deal, for exemple ? Good job nonetheless, you should test it on real, live, attacked server with before/after results.

It's extremely rare Java drops content from one version to another (it generally deprecates it, but that doesn't block you to use it). Stuff is normally compatible if you evolve Java, and ofc you can have issues if you use older Java since methods and content wasn't existing on previous Java version. Not sure if your pack relies on the external compiler L2J was using for a long time (libraries called ecj, python-engine and java-engine), but you should dump it in any case - first because it delays your server startup of 45sec-3min in worst case scenario, second because you got no control over the library content so your current problem can occur and you wouldn't get a fuck about it on error logs, third because it's barely useful (personal pov). Normally, the name of libraries give you an hint about which Java version you should run (cf. aCis was using java-engine-1.7 in 2011).

If your proxies are stressed, it means you failed blocking stuff before that. Generally speaking, it's a bad behavior to think L2J server should handle such actions. L2J shouldn't be a "firewall", a "webserver" or whatever else service. Most of internal flood protectors are pointless, for instance, and there are a lot of them. I believe it's not the role of L2J to become something else than... A game server. Stress should be stopped way before reaching gameserver application (iptables is normally enough, if not hardware/3rd party material). That's my opinion. The leftover solution, ping relocation, seems to be already handled on L2J, as stated Nik. About aCis, well, you already know you can provide the "5 lines" on a diff patch on a public state ("Public Workbench" board, for instance), ppl review, and if things are good enough, it's commited. aCis is initially based on L2J IL, a 2007 source, for your information, and the work is all about what I can/want code and what people can/want share. My focus is probably not yours, or other sharers - which shouldn't stop people to contribute.

Then it's isInParty() check on CharInfo on the line related to aura, and a broadcast on addPartyMember / removePartyMember if it's not enough / already called.

You simply have to add one line on addPartyMember, or whatever method is used during the addition of a Party member (probably on L2Party if no rename). And no it will be a terrible mess if multiple parties melt, notably during pvp, since everyone will have the same color. And at best you can have 2 different colors, based on isAutoAttackable state, which force you to broadcast CharInfo to get refresh.

What's your line 485 on L2World ?

I won't waste my time with you. Continue to be a player. Good luck. And for your information, knownlist range has been cutted down at rev 371.

Regular L2J / retail way is to delay the item equip. Simply add it, it's already implemented on L2J. Search for "ThreadPool", you would eventually found it on UseItem. Instead of return when if (activeChar.isAttackingNow()) , you simply have to generate task to do the initial operation. Basically you queue the task of equipping the item.

I suppose you speak about aCis / L2JFrozen. First, L2JFrozen is basically Scoria, so better say Scoria rather than L2JFrozen, since implementations of L2JFrozen compared to Scoria is, at best, minimalistic and higher versions of Scoria probably fixed/reworked more things than L2JFrozen did. Second, which rev of aCis are you using ? Knownlist rework is probably the cause of the FPS drop (until you spam packets like a noob), and initial region size was set really high. It has been cut by 2, not specially because it was lagging, but because client itself doesn't go that far. Third, show the actual knownlist of both projects. Because, you maybe spawned 10000 valakas behind, and your screenshot doesn't prove much. Fourth, none is forced to use aCis. People use aCis because it has been continuously updated upon the last 10y. Can you say the same about L2JFrozen ? Nope. L2JFrozen 2.0 was called around October 2017. Before that, last free version which is 1118 is tagged around January 2015. Fifth, knownlist could benefit from few cleanup - notably Z layer approach, to cut few results. Sixth, spawn 2000 monsters on L2JFrozen and 2000 monsters on aCis, on a single region. Show me visualVM content with 100 players online on those zones. If your L2JFrozen server is still alive to show it.

If you got a java file : copy-paste it directly in the good package (package = folder). If you got a pastebin : generate the file, right click on the wanted package > New > Class > Give the good name > Copy paste content If you got a patch : Right click on your patch > Team > Apply patch, choose the good project and apply it if there isn't errors on line.

Changeset 382 (1288) Since a lot of core has been edited/moved, sources will be exceptionally shared at rev 382 for Customers, added to the diff patch for the adventurers. If you begin to dev a project, I strongly invite you to port your customs directly on 382 shared pack. Organization, Cleanup, Bugfixes Organization A lot of organization has been made, in order to give some consistency to core side. - Creation of package gameserver.enums. All existing enum have been moved here, and renamed to either get distinct name (CtrlEvent / EventType being too generic), and to fit with new convention name for enums (has to end with "Type" or "Status"). - Creation of package gameserver.model.actor.player and gameserver.model.actor.npc, holding classes related directly to Player and Npc (+ children) classes. - Creation of package gameserver.model.spawn, holding AutoSpawn / L2Spawn / BossSpawn classes. - Drop model.base and model.actor.appearance packages. - Player is moved out of model.actor.instance, to model.actor. - Drop of Broadcast class and gameserver.util package, content is splitted between World / ZoneManager / Creature. - Drop of gameserver.templates package. StatsSet is moved to common.util. - Drop of gameserver.instancemanager, with rename : SevenSigns > SevenSignsManager, SevenSignsFestival > FestivalOfDarknessManager. Both are cleaned (CLogger, try-with-ressources,...) and moved to gameserver.data.manager. - AutoSpawnManager > AutoSpawnTable and moved to gameserver.data.table, with a split of AutoSpawnInstance > AutoSpawn moved to gameserver.model. - Drop XMLDocumentFactory and gameserver.xmlfactory package (no use anymore). - Drop gameserver.model.petition package, move Petition back to gameserver.model (we avoid to use package for single classes). Cleanup - Refresh DP .project to avoid Eclipse warnings. - Move GET_PLAYER and INSTANT_JUMP skills to their own SkillType, TELEPORT, in order they aren't used by regular AI system. In order NPCs use them, you have to write additional script. - Add Npc#doCast(SkillType), which randomly cast a skill based on its SkillType and associated to the NpcTemplate skills. - Heading is now part of getPosition(). New setXYZ/spawnMe methods have been generated to give the possibility to feed heading in same time than X/Y/Z. To set the heading independently, you have to use getPosition().setHeading(heading). - Improve Npc#toString(). - Rename Player#getPet() / setPet > getSummon() / setSummon(), since it is supposed to return Summon, which are both Pets and Servitors. - Walker doesn't override HP drop stuff (since it inherits from Folk#isMortal). - Creation of Punishment model (with Javadoc) in model.actor.player, holding all punishments informations of a Player. - Creation of HennaList model (with Javadoc) in model.actor.player, holding all Hennas informations of a Player. Ty vampir for the initial contribution. - L2Radar > RadarList + Javadoc and move it to gameserver.model.actor.player, extract RadarMarker to gameserver.model. - ValidatePosition _heading isn't processed anymore (no use). - Generate TeamType enum, based on StinkyMadness idea. - Complete rework of RaidBossManager. - Merge the different Maps holding infos into one. Create BossSpawn in model.spawn package to hold all related infos. - The saving process isn't lazy anymore, but handled on spawn/death/server start. - BossStatus isn't related to a Npc instance anymore, meaning you can interrogate it even if Npc isn't existing (DEATH case). - Rename StatusEnum > BossStatus enum, moved into enums package. - Add the possibility for server admins to tweak default items quantity and equipability. The result is more readable than previous system. It uses the newly generated ItemTemplateHolder (gameserver.model.holder). - Cleanup RandomAnimationTaskManager - Animation task cancel is now instant upon NPC death, inactive region or intention change != ACTIVE for Attackable. Before it was waiting the regular end timer. - Following instances types aren't registered anymore on RandomAnimationTaskManager : ControlTower, EffectPoint, FlameTower and SiegeFlag. - Drop of Npc#isMob(), addition of Npc#calculateRandomAnimationTimer(). - Add missing login status on admin/maintenance.htm - Generate StatusType and AttributeType enum, which are used for both LS and GS. Unload ServerStatus of multiple variables. Bugfixes - CharInfo heading / boatId is fixed, based on Vilmis remark. - Fix a bug introduced in rev 380, where bosses died during a server down couldn't respawn properly. Ty bowling4soup. - Add HEAL_STATIC as potential buff slot (fix skillId 3125). Ty Sahar. - Modify Lightning Strike power effect. Ty Sahar. - Fix the double summon spawn issue (unSummon + doDie happening in same time), as tested by Sahar. - Decaying summons tasks are dropped if a decay occurs (avoid tasks to run for nothing). - Add Porta/Perum script named SummonPlayer. - startAttackStance() / stopAttackStance() system is cleanup. Avoid to spam AutoAttackStop broadcast by NPCs. Decrease the amount of startAttackStance() / stopAttackStance() calls tremendously, notably because the call is moved from onHitTimer to doAttack. Since each attack can produce 1, 2 and up to 10 hits for polearm users, as much calls were done. - Player#store doesn't store anymore client X/Y/Z (avoid exploit upon relog). - Diagonals flags rule is edited on GeoDataConverter. They must now be validated in both direction. - Add/improve character water/fly state on SummonInfo, NpcInfo, PcMorphInfo, PetInfo. - Avoid NPE on ClanHall#setOwner, issue introduced in rev 381. Ty bowling4soup. - Fix ShortcutList#restore(), issue introduced in rev 381. Ty bowling4soup. - Fix ignoreShield() behavior for L2SkillType STRSIEGEASSAULT, PDAM && FATAL. Ty Sahar. - SiegeGuard AI is set to ACTIVE and not IDLE when reduceHate occurs. - Fix an issue on player creation ; items (armors) weren't equipped properly. - Fix default skills shortcut acquisition upon player creation. - A DOWN server now correctly repells login attempts (case of Shutdown 60sec). Negative access levels accounts see the server DOWN, and can't login aswell. Addition of GameServerInfo#canLogin(LoginClient client). PS : You should update your geodata, either using GeoDataConverter or refreshing it using aCis shared link (verify modification date). Since a lot of core has been edited/moved, sources will be exceptionally shared at rev 382 for Customers, added to the diff patch for the adventurers. If you begin to dev a project, I strongly invite you to port your customs directly on 382 shared pack.

Well, if it's true it's a shame. MxC should be used as a middle man and pick some fees from it, that would avoid such scenario.

As you say, and for now there is none. Moderators would probably do some actions if you provide real content. You should better wait the end of the month to get a real overview of what has been done, since the timelapse is still running. What I see is you can't even properly explain the agreement you did with Kara'. Before to agree to something you put limits, you define what needs to be done in a given timelapse. Personally, both your explanations and Kara' don't help me to know what was the actual, initial agreement. "Work on files for 1 month" means strictly nothing. If he is extremely generous, he can work every day. If he is greedy, he can work only one dat. You got no control over what has been produced, and can't (really, even if the beginning seems terrible) blame Kara' since you didn't put any limit yourself. A clear limit would be "code me 5 customs on a timelapse of 1 month for 200€". It's clear. It can be quantified. It can't be bragged from one side or another. You seem like a old couple on a bed, trying to steal the maximum amount of the cover of each other.

While there isn't a real scam, the offer itself is, at best, shady. You basically don't give any result count - you can or can't work, ok. But normally you work for a counted result which can be appreciated in the end of the contract - like, 5 customs spread coded over the whole month. Or 10. Or 1. With the freedom to break and revert what you did for the whole duration time. It looks like the customer wasn't aware of that information, and accepted a deal you - maybe voluntary or not, not my point to judge, moreover when we miss informations - didn't seem to express perfectly. @Pamela32 you should provide initial deal as a proof. You maybe misunderstood the initial terms of @Kara`.

Yes and no (the for loop isn't the problem btw :P), his ask is to cut "123" into icon1, icon2 and icon3. That's not possible with "581043", "10" will be cut "1" and "0", not "10". That's why I suggested to change his notation from 1 to 10 > 0 to 9. And if you say "10" is the only number with a "0" and can be actually be parsed, then what about "11", "12", "13",... :P.

public final static String retrieveIcon(int number) { return "<icon._num" + number + " width=16 height=16>"; } About your second ask, you could parse the int 123 as a string and loop over each encountered character and refer to retrieveIcon method - if you had only one digit. Since you got potentially 2 (with "10"), it's not possible, since it will be cut to 0 and 1. My example can work if you move your notation from 0 to 9 instead of 1 to 10. And don't build random Map on a getter, it's terrible.

UserCommandHandler.java line 70 ends with a NPE. If it's your new handler, verify if you initialized it correctly. Short version : UserCommandHandler instance can't load properly, because an error (NPE) has been found on line 70 during the registration of an handler.

Edit onKill section to fit your needs, the primitive behavior being at least : @Override public String onKill(L2Npc npc, L2PcInstance killer, boolean isSummon) { // This depends on the boss respawn delay being at least 5 minutes. final L2Npc spawned = addSpawn(MONSTER_NPCS.get(npc.getId()), npc, true, 0); startQuestTimer(TIMER_UNSPAWN_RAID_CORPSE, 300000, npc, null); return super.onKill(npc, killer, isSummon); } You also need to edit places where allowedPlayerMap is used, because it is supposed to retain allowed players and block people who aren't part of the quest.

Your custom NPC must correctly override onBypassFeedback, using a if (command.equalsIgnoreCase("whateverCustomCommand") { } else super.onBypassFeedBack.... The super.onBypassFeedBack sends the client to "basic" NPC commands, such as Chat. Before the super.onBypass, you can put any new custom commands you want using if / else if / else if / else if /.... Almost all, if not all, Folk (new name for old L2NpcInstance) derivated NPCs act similar, I invite you to read about them to see what they can override. If it's not working, I invite you to read about Chat command and how it's implemented on bypasses of existing HTMs (tip : there are 936 results in more than 800 files), because you probably made an error writting it.

aCis already integrates a scheme buffer, no clue why you would like to add this one (which was probably built on aCis buffer v1, btw). v1 was added in rev 324 (so you already got it), the v2 from rev 364. Also don't use rev 340, which is 4y old and filled with issues than I and my community solved. Latest free rev is 370, you got no reason to don't use it. Whatever the amount of customs you added, it can't beat the amount of fixes compiled between 30 revisions.