Tryskell

There are different IL clients, so there are probably different issues on each. A 220Mo patch isn't nothing for a 6Go client. Be sure to get latest. While it doesn't provide any sort of security regarding THAT issue, at least I can answer/test based on the same thing. Maybe you even already got it. Just to be sure it's not a server side issue (or some sort of anti exploit), you can put logs on the given npc bypass to see where it stuck. "Make Items" is a simple Link towards another htm. "See the list." calls directly multisell bypass : npc_%objectId%_multisell 1004 You can then go on Npc#onBypassFeedback and find multisell else if (command.startsWith("multisell")) { MultisellData.getInstance().separateAndSend(command.substring(9).trim(), player, this, false); } Then on MultisellData public void separateAndSend(String listName, Player player, Npc npc, boolean inventoryOnly) { final ListContainer template = _entries.get(listName.hashCode()); if (template == null) return; if ((npc != null && !template.isNpcAllowed(npc.getNpcId())) || (npc == null && template.isNpcOnly())) return; final PreparedListContainer list = new PreparedListContainer(template, inventoryOnly, player, npc); The only thing which can stop you to get your multisell is the isNpcAllowed check or if npc is somehow null at this point. What's the NPC you try to test ? Maybe he is missing from the list. Other than that, there is nothing except the client.

Quest list progress : https://acis.i-live.eu/index.php?topic=970.0 Regarding your other issue, I strongly invite you to put latest IL client update to get at least the same issues than others : https://acis.i-live.eu/index.php?topic=8479.0 No problem for me. https://ibb.co/6Fch5DP

He trolled you. You didn't provide enough information, and we can't read your mind. Regarding your issues, search on logs. If you got nothing on logs, well...

If you didn't change anything related to core, simply rollback your items folder. But I got strictly no clue how you would end with such result.

Mate you only have to ctrl+f on your Eclipse with the good value. Forget data side, it's probably not here, until you edited all items. Put your project on a SVN/git/whatever, that will avoid you that exact sort of problem. While it's kinda late, you still can do it putting the initial sources you used as rev 1, and as rev 2 your current stuff. You could see all differences between files. There is no config related to items - at least not more than L2J. That's not really the house rule to add configs, I generally delete :D.

If the multiplier value is always the same, simply seek for it over sources / config. You will probably find very fast.

I suggest you to check SellList packet, it can also be getPrice() / getReferencePrice(). All in one, I can't experience your issue (and as far my memories go, I don't think it has ever been an aCis issue) so it is probably linked to whatever custom (you added or from a custom aCis source). I guess you are bound to search until you find.

Which item are you talking about ? Some items actually cost higher at sell, because they are supposed to be quest items rewards, for exemple.

Still missing the break; Should be + for (SpreeKills kills : SpreeKillsData.getInstance().getSpreeKills()) + { + if (kills.getKills() == _spreeKills) + { + World.announceToOnlinePlayers(getName() + " marked " + kills.getMsg(), true); + + if (!kills.getSound().isEmpty()) + sendPacket(new PlaySound(2, kills.getSound())); + + if (kills.getItemId() > 0) + addItem("Reward", kills.getItemId(), kills.getItemCount(), null, true); + + break; + } + } ------- You could add an empty check for getMsg() use as you did before if (!kills.getMsg().isEmpty()) World.announceToOnlinePlayers(getName() + " marked " + kills.getMsg(), true);

I only understood "malaka", and it's not really nice ! :(

I guess you want to unhardcode that if (kills.getKills() == 15) and instead use the highest available number from your enum. -------- public void setIncreaseKills() should be renamed public void increaseSpreeKills() ------- While not impacting performance with such low amount of options, it is recommended and, you still should break; once a valid number has been found on your for (SpreeKills kills : SpreeKills.values()) To avoid to iterate the whole thing. ------- You probably want to check if kills.getSound() is empty before sending a pointless empty packet. if (!kills.getSound().isEmpty()) sendPacket(new PlaySound(kills.getSound())); ------ Your configs are different than the default version. As a share, you should unify them. + ENABLE_SPREEKILLS = players.getProperty("EnableSpreeKills", false); + SPREEKILLS_REWARD = players.parseIntIntList("RewardSpreeKills", "9209-1"); != +EnableSpreeKills = True +RewardSpreeKills = 9217-5 ------ The sound String on your enum is currently empty, and there is no config to edit it. I suppose people have to set their own sounds in the enum, but still you should at least give some default sounds, or at least // quote them somewhere for easier use.

C5 path notes matches with what you found on l2wiki.com, so the behavior is correct. https://l2industry.com/Home/C5#rainbow I suggest you to read AI.obj from L2OFF GF, since L2OFF IL version is probably half broken.

Ctrl + F over your favorite IDE, you don't need to be a Java expert to use Search tool.

First line of my comment is the location where to set it.

Simply put your check on Creature#checkDoCastConditions(L2Skill) - other name for Creature : L2Character. Something like if (isInsideZone(ZoneId.FLAGZONE) && ArrayUtils.contains(Config.ALLOWED_SKILLS_ON_FLAGZONE, skill.getId())) { sendPacket(ActionFailed.STATIC_PACKET); return false; } Just after this first block if (skill == null || isSkillDisabled(skill)) { // Send ActionFailed to the Player sendPacket(ActionFailed.STATIC_PACKET); return false; } You have to build the Config, it's a simple int[]. The provided exemple is enough if all skills are blocked the same way on all flagzones. ----- If you need specific skills being blocked on specific FlagZone (one FlagZone stops all heals, another stop aggro skills,...), you can also hold that Config on the zone itself, and then interrogate which zone you currently are to retrieve the correct int array, but it needs more work.

Search for something called MapRegionManager, you should have normally methods to retrieve zone name. It depends about the pack.

I hope I will do it short (!), but basically, if you find issues, and if you are paid to fix issues, you got 2 paths : Keep the fix for you, and try to sell it, over and over. Keep quiet about it. Share with the pack, if you think it is worthy and can help people to avoid to pay for such fixes. aCis goal is to unite everything (my work and community shares) in a single piece of project, which is less and less buggy, and whom revisions aren't fixes of each other (which is often what happen to projects - L2JFrozen for instance). About "why so much issues in 2019, after 10y of development", some ways to answer : L2J IL is extremely bugged, and we start from very, very far. It's really a basic answer, but extremely right. As a basic user, you probably got no clue about what I had to fix. Some huge parts had to be taken from postL2J versions (TradeList, Multisell, skills system, etc). L2J organization is clunky, and some time was spent to make it more organized. It's stupid to say, but it takes some time to write a Javadoc. I care about every single aspect of the gameplay, while most project owners don't. Scripts folder, while fully bugged and in need of fixes, took me a huge amount of time. Most of projects never care about them, or they simply copy-paste my work (L2JHellas, for instance, and maybe Mobius IL - ? I don't remember well so spare me on this one ?) which obviously speed up things for their projects. I deny bug fixes until a L2OFF test is done and valid the behavior. If I got no bug report, I got no bug. So I can't fix it. It's also extremely simple to understand, and that's why your behavior is problematic. If I got a bigger plan for a bug report, than it's delayed, cause I know I will lose my time. So some issues are simply kept alive, the time a bigger rework is done (case of SpawnManager and all spawns related things). About the slow development, some ways to answer : I'm mostly alone to develop. That's a simple fact. I'm perfectly aware I'm the biggest bottleneck, and unfortunately there is nothing to fix that issue, except cloning myself or recruiting some enough talented guys I don't need to backup and can code the same way I do. I'm a human, and sometimes as a human being I need a break. It can be ass-long, but it is needed. Otherwise, you simply burn yourself. Doing something you don't like is the best way to give up. I'm still here after 10y. I can't say the same about 95% of projects out there. Community shares need to be reviewed, tested and checked by L2OFF. Most of them are bugged/malfunctioning/not retail. L2OFF IL itself is buggy. Some reports are wrong at a time, and valid at other times. It's really frustrating sometimes to get one report saying one thing and few months later getting another tone, while both tests were done on L2OFF platform. Some infos are simply lost. I must dig to official patch notes to find informations. It's very time consuming. My own politic about heavily testing things is also time consuming. But it saves time in the long run, avoiding to fix one thing over and over. All in one, simply share the bugfix, and there is no bug anymore. No need to complain. You are rewarded with Customer rank, or Inner Circle after a time. You help multiple dozens of people (actually 90+) in same time. You help free users - even if it's delayed for them, it becomes one day or another usable by all. Finally, if you really don't like aCis (or me, cause it's generally what people don't like but they prefer to attack my project even if they use it) : Provide a better alternative than aCis to people. According to your first topic, it looks like you are perfectly able to do it, and we will see if you can do it better with the same material (L2J base). Use another project, since nothing stop you to use another pack. In case you're a paid developer : don't provide services for aCis. Simple ! But I already can tell you this : each pack got its own issues and so you will end with different types of issues. No matter if it's free, or you paid 1200$ (and if I say that, it's because I asked someone to test 2 behaviors on L2Scripts IL, and both were as wrong as L2JIL). I hope you all appreciated that analytic point of view ! Regarding aCis itself, it's : 550+ bug reports archived (only reported issues, not including my own fixes) 50+ public shares committed 400+ "customers" since 2011 90+ customers at the date of 16/09/19. A community of 4k+ topics, almost 4k members and 34k+ posts. Unique self coded things and "courageous" reworks (because I could simply go full "fuck themselves" and deliver you the same 2007-2010 crap that is still existing here and there ; but I believe I got some balls to bother about some game-breaking things like knownlist or movement, and I could be kudos for that). If that was that bad, it wouldn't be used. I hope ! :)

I can copy-paste my thing but that wouldn't help you since you will miss things here and there. StinkyMadness post got normally everything embedded in (I basically used some of his ideas to format, and current formatting of aCis scheme buffer - which was itself based on Caparso work). Request a developer in marketplace section if you are unable to adapt it.

Not really if you concat above a certain limit. With an icon that's something like 45 characters to show.

Not sure on which aCis version Eola is built on, but you shouldn't use it, only for the sake there are already better versions of aCis. Customs are customs and can be added back, but I doubt you will be the one fixing retail gameplay. For instance I fixed 2 very old L2J (= shared towards almost all L2J forks) exploits in 380 and 381, I fixed 4sep behavior (chest exploit) at 379, 383 got sit/stand fixed related to shop system, 374 got mass ressurection exploit fix upon BossZone and retail clan transfersystem, which fix an exploit, etc... Well, if you aren't up to date, your server is, anyway, vulnerable.

If you use Player#destroyItemByItemId you are right, even the error message is included if the boolean is set to true. In case you use getInventory() version, it isn't. It's generally used for "custom" message, eg. Lotto tickets / pet item with integrated level. So that will simply be, error message included : if (playerInstance.destroyItemByIt...) { // code here }

Ask support for whoever developped "that" aCis version. You got an issue with one of the customs.

Well, an answer is a house, I gave some bricks. It's up to the community to give others bricks to make the complete house. I gave the good path to check, which is already better than saying anything wrong :). If someone else want to develop my answer, it's a public forums.

Going in that way you can say botters actually HELP economy on low rates (lower the rate, helpful they are - because the amount of mats they offer simply lower prices, making itemization affordable), and therefore they shouldn't be hunted. I personally think the dualbox system is wrong too. If you want to make a team you play "Granado Espada" or any FF-like game.

Limiting one client per HWID and enforcing a single client launch on your system already cut all the lowbies botters. For the hardcore using VM or multiple network cards, you probably want an active GM. You can also write some stats, like storing xp/player table on a Map, which would be cleaned every day. The same could be done on a hourly base. It's enough to see if someone botted /nolifed, and then you can investigate physically another day to see what currently happen. You can do the same logging system with quest success/player. If someone makes a repeatable quest more than 2 times per day, it triggers you an alert and then you can investigate yourself. The point is to mitigate the problem. I doubt than you can do better than that. Another, simple way is to make repeatable quest doable only once per day. It drastically limit quest botting.