Tryskell

Delete "nextActionAttack" line on all skills XMLs, or set it to false (49 results)

Care about your own shit, maybe ? It seems you got some brown left in your pants. It's not because I don't do public release that it means I don't develop.I'm almost 100 commits ahead current public latest release - which is, in my world, almost 1.5 revision.

To name few, after some look : * eventTimer(int time) should be handled with a Future<?> task and ThreadPool. * _originalCoordinates is (probably) redundant with _savedLocation, and the use of it is wrong (see _savedLocation usage to see correct) * CopyOnWriteArrayList container should be avoid for performance reason, use ConcurrentHashMap.newKeySet instead. * + if (reward == null) + continue; can never be null, since you manipulate it from A TO Z. * TVT_DOOR_LIST doesn't seem to be used and can use getProperty(final String name, final int[] defaultValue, final String delimiter) instead of self coded array manipulation.

Initial code simply adds a listener on doDie, updatecounter verify if killer is a Player, which basically means summons aren't checked (so summoners will never got any window, since their pet do the kills) and only affects Monster mother and childrens classes. There is no check anywhere about melee/range, so even if there are some flaws, shortcuts, and optimizations to do, your problem is external to that.

1. From the moment you got non critical issues occuring, I guess it's fully ok if at least one ppl got power to restart the server. 2. According to Sahar, aCis latest version (since Java11 move and use of enhanced default G1GC) is enough stable to run one month without any restart (and probably, with no restart at all, since the restart always came with some core modifications). 3. 2Go RAM dedicated to the JVM is the "minimum" requirement (could be even 512Mo without geodata and 256Mo without scripts loading/geodata). For a live server, values between 4G min and 6/8Go RAM max. I think higher values is a complete waste of ressources, while lesser you will maybe struggle with big amount of live players. 4. Sahar moved from OVH because their DDOS protection sucked and help was inexistent to fix it, but he kept it for years. I think he moved to Hyperfilter. 5. It's generally adviced to use a test server, and, once tested, move content on live. For a test server, simply deactivate geodata and run it with 512Mo, it can be done on any nowaday computer. 6. Not sure what you mean by merging data. If it's about SQL, well, SQL querying is strong. About aCis specifically, SQL columns can appear, dissapear or be modified, rarely entire tables. XML can (and will, in the future : case of spawnlist and items) be modified aswell. I don't hold myself to make changes when a change needs to be done, otherwise I stuck. Changesets always suggest such changes on "PS:". It's up to you to make your customs easy to move from one revision to another (case of SQL : make your own tables, case of XML : add it to the end of a file / new file, case of core side : make your own custom package, and edit as low as possible existing classes - and if so, put everything in bottom). I invite you to contact Sahar, an aCis user for something like 7 seasons of its L2OvC server.

If both getRunSpeed() and _activeChar.getTemplate().baseRunSpd are int, then you lose the division accuracy. Introducing 1f add back the float behavior. But normally those values aren't supposed to be both int. Not sure what is your getRunSpeed(), but it should return float normally.

Technically painful, you have to retrieve all data for given chronicles (monsters stats/drops/spawns), the features are different (no elements stones, agathions, kamaels, multiple zones... on IL) so you have to code everything 3 times (with a version check). Packets opcodes are also different so you have to filter and reorganize 300+ packets 3 times to use given revision with given set of opcodes. I don't even count packet format changes, like int becoming long, or added features. And if you don't code 1 pack to handle 3 clients (which is technically possible but a burden in the ass), you have to code 3 packs to handle 3 clients, which means you have to fix/test/commit the same fix 3 times. Fixing one chronicle with a community is already time-consuming, so 3... I think 2 people so far tried to export aCis to higher chronicles (Hellbound few years ago and GF lately), I personally got enough work withIL to care about others chronicles, and if I do, it's probably far easier to downgrade to C4 (simply have to cut things out and use shared L2OFF, which, unlike handmade IL, I know it is CORRECT).

So, "run to walk" toggle also triggers that 0 behavior ? And if you disconnect while being 0, you get 0 at player store ? Buffing you enough (ww2 + run speed totem + bers + ...) + parry stance debuff, for a run speed total higher than 115, don't trigger the behavior ? ---- You should check about custom config related to speed. If you're sure "115" value triggers it, search for this value on core and properties.

There's few errors and optimizations to do. 1 - static variables shouldn't be static, otherwise only one zone property will be loaded for all. public static boolean pvp_enabled, restart_zone, store_zone, logout_zone, revive_noblesse, revive_heal, revive, remove_buffs, remove_pets, give_noblesse; static int radius, enchant, revive_delay; static int[][] spawn_loc; L2Skill noblesse = SkillTable.getInstance().getInfo(1323, 1); private static List<String> items = new ArrayList<>(), classes = new ArrayList<>(), grades = new ArrayList<>(); public static List<int[]> rewards = new ArrayList<>(); 2 - You loop the player inventory for nothing if "enchant", "grades", "items" "gradeNames" are empty. for (ItemInstance o : activeChar.getInventory()._items) { if (o.isEquipable() && o.isEquipped() && !checkItem(o)) { int slot = activeChar.getInventory().getSlotFromItem(o); activeChar.getInventory().unEquipItemInBodySlotAndRecord(slot); activeChar.sendMessage(o.getItemName() + " unequiped because is not allowed inside this zone."); } } 3 - following code is redundant and could be cut by 2 (no needs to stopAllEffects on a unSummon case, IL got no buff saves). if (remove_buffs) { player.stopAllEffects(); if (remove_pets) { Summon pet = player.getPet(); if (pet != null) { pet.stopAllEffects(); pet.unSummon(player); } } } else { if (remove_pets) { Summon pet = player.getPet(); if (pet != null) pet.unSummon(player); } } > if (remove_buffs) player.stopAllEffects(); if (remove_pets) { Summon pet = player.getPet(); if (pet != null) pet.unSummon(player); } 4 - Few places where it can benefit from aCis organization, like lambda uses for ThreadPool usage or ExProperties instead of Properties.

AttackableAI#thinkAttack if (attackTarget == null || _attackTimeout < System.currentTimeMillis() || MathUtil.calculateDistance(npc, attackTarget, true) > 2000) Simply add here such check : ... || (npc.getSpawn() != null && !npc.isInsideRadius(npc.getSpawn(),...)

https://acis.i-live.eu/index.php?topic=7811.0

I also like the minimalistic approach. What I found questionable : The scrollbar, a 25 slots pagination is far less painful at usage for players. The "live" behavior, probably a ressource grinder for almost no benefits (it's not a LoL competition). Your position should be more visible Some improvement room upon what is displayed (title : pointless, icon for class hard to understand, too much color / gradiant). It's heavily subject to personal tastes - probably what I find ok, someone else will hate it.

Do positive speed boost also ends in strange speed ? What's your actual speed if you base runspeed + 30 ?

Restrict it to 10 items checked max. You already got a counter, so it's easy to implement. If you don't want to impose a limit to the user, you have to paginate as SweeTs says. //bk admincommand on aCis would give you some hints about how to do it and keep it readable. https://github.com/Tryskell/acis_public/blob/master/aCis_gameserver/java/net/sf/l2j/gameserver/handler/admincommandhandlers/AdminBookmark.java Your own code got a pagination system, already, normally. int _itemsOnPage = ITEMS_PER_PAGE; int _pages = _items.size() / _itemsOnPage; if (_items.size() > (_pages * _itemsOnPage)) { _pages++; } if (_pageId > _pages) { _pageId = _pages; } int _itemStart = _pageId * _itemsOnPage; int _itemEnd = _items.size(); if ((_itemEnd - _itemStart) > _itemsOnPage) { _itemEnd = _itemStart + _itemsOnPage; }

PlayerAuthRequest packet tries to read an int, but the packet is too short.

Current latest, 382.

Not sure why you involve myself in the discussion, moreover when you speak about something you actually never experienced by yourself. Keep your side, ty.

Could be : https://github.com/brettwooldridge/HikariCP/issues/1132 You probably got a connection leak somewhere.

I edited my answer :), and the idea is to only have one point of entry, which would be PlayerInfo linked to a Player, like they are actually linked to an AccessLevel, a Appearance, etc. SO drop inner variables of Player, and use only PlayerInfo to refresh those values. Np.

PlayerInfoTable retains some informations (cause player names are needed for stuff like friendlist), you probably can add missing ones, but it means you have to update it in same time otherwise you will refer to wrong values. That whole class probably can be enhanced or used differently (PlayerInfo being maybe part of Player, once player is loaded ? Like loading an id card, which avoid duplicates variables or even caring about refreshing 2 places). If such stuff is edited, that would simplify the developement of a lot of customs.

Not sure why you keep speaking spanish everywhere Reynaldo (even on your tutorials, there is no subtitles in english), you cut yourself from a lot of people. I personally don't care, since I can read / hear it decently, but for other communities like RU or GR (and probably BR ?), I think you shoot yourself an arrow in the knee. Not sure also you got the "right" to use L2JFrozen name, or than Shyla/Nefer allowed it. I know it's marketing, but it's generally bad seen (even for live server name). Good luck nonetheless, I hope you're motivated ! :)

The packet is either not recognized because client simply can't handle it, or because it is considered an unknown packet and dropped by GamePacketHandler core protection - which assures you the sanity of packet send for a given client state, to avoid unexpected L2PHX craft. So add that packet into the given client state, and if it's not that, you are basically screwed if you don't know how to client edit.

Don't use a GM character, but a regular character to test such thing. GM got no restriction. If you already tested with a default player, what can I say... Your pack probably didn't implement them properly. You can check on which zone you are currently set using //zone_check and //zone_visual admincommands.

Edit the zone type for BossZone, don't forget to use allowPlayerEntry. Check GrandBossTeleporters for example. If BossZone properties don't fit you or you already got a custom zone type, you have to copy-paste BossZone content into your whatever custom zone and remove both setInsideZone(ZoneId.BOSS calls, and ofc to edit the zone type for your custom zone type.

Nope, can be done passively using onEnter zone, since when you connect, you are registered to zone. You only have to check if the dude is supposed to be there or not, like grand boss zones, which is basically a map where players are registered with their timestamp.