Tryskell

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.

If you meant multisell, the obvious answer is Ingredient#getEnchantLevel() isn't used where it should be used, or you got some "protections" blocking you to get what you want. Check regular L2J MultiSellChoose / MultiSellList and see where it's used (you must have 9 occurences). ---- If you meant regular player shop system, then the system is probably not implemented.

Use Oracle JDK 8 if using free revision, or OpenJDK 11 if you use latest and compile it with proper JDK. ByteBuffer#clear() seems to be dropped/edited/modified on later JDKs. Nothing related to MMCore, moreover when MMOCore is integrated since ages on aCis (and so, no needs of additional compilation).

It's not "half fixed", it's fully redone. That's different of your generic copy-pasta stuff and your 5 lines broken fixes. It was pushed to public to avoid people to wait longer, and to eventually help with the end of the developement - testing it, etc. You will be the ass copying it and speaking about leeching anyway once it's fully operational. Probably the same when SpawnManager will come. Etc. The story never ends, after all ! Even in the case I copy paste something from you - which would be the first time, cause generally I never copy paste form other packs except L2J/Unity - you still owe me few hundreds hours of developement - if we speak of equality. Not sure why you taunt me, I simply say your fix is bad and you need to rework it. That's giving you a service actually - and to other people aswell.

You can't do better ;).

It's not even a temportary fix, as it fixes 1/3 possible states. The exploit is still doable when swimming or flying, and the falling needs to be tested. It is simply incomplete and not worthy to be shared. But you are right on one thing, it is similar to all those 2009 "fixes" - best exemple is battle/spell force exploit fix.

It's client coded.