melron

It would be better if you put some details for the thing you need... Your question is a bit unclear. Do you need to 'hide' the casting animation or the effect like stun (the stars)? Or both? If you dont mind, share with us your thought in order to understand what you need..

As @BruT mentioned, augmentations data are applying to an objectid. So if at any case, the item with this object will be deleted (probably manually) without deleting the correpsonding augmentation data, then the next item which will get this object id, will automatically restore the augment. As you already saw, you may see the item name as Augmented, but the stats / skill is not appearing at the tooltip. This is happening because augments are not implemented on C6 on armor type items. So, the problem is located at a bad move by you. I doubt frozen have that issue (even though is so bad)

You are looking at the wrong place. You should add 1 check on the specific target handler. I'm not into mobius things, but in acis you could add your check in the corresponding target handler which in your case, the type is AURA.

There's nothing that can't be done. You can use xml to parse your values just like you did with the other model.

Why not an abstract class? public abstract class VipStatus { private final long _endTime; public VipStatus(long endTime) { _endTime = endTime; } public long getEndTime() { return _endTime; } public abstract double getExpBonusRate(); public abstract double getSpoilBonusRate(); public abstract double getAdenaBonusRate(); } Then your classes public class VipBronze extends VipStatus { public VipBronze(long endTime) { super(endTime); } @Override public double getExpBonusRate() { return 1.2; } @Override public double getSpoilBonusRate() { return 1.7; } @Override public double getAdenaBonusRate() { return 2.5; } } So in conclusion, your player instance will have only VipStatus variable and you wont mess with enums and checks for what vip status the player have

I'm not into hi5 but, i guess your coded can be written like this: if (player.getInventory().getInventoryItemCount(17423, -1, false) > 0 ) abnormalTime += TimeUnit.HOURS.toMillis(2); No null check No return (its probably the issue you faced if the code stopped) Also, i'm not sure where you coded that. But. I didn't get the message part. If a player request a full buff, it will send (buffs count) messages if the item is not in player's inventory?

We are just out of stock these days. Come again tomorrow

Have you ever thought that you didn't receive any negative feedback for your server just because you don't have as much as clients that your server needs to get a right feedback? By saying that people dont like custom 10x interlude, you are actually saying "players dont like my server". So they dont even sit down and write a feedback. They just move on.... Also, you are disagree with developers with the excuse that the code does not matters while you are actually posting in a section that called Lineage II Java Server Development in a sub category -> Server Development Discussion [L2J] . They/I can actually answer to you, prove that your sources are better than the X sources in a programmatically way, or STFU. How the hell they supposed not to criticize your words? Post your thoughts at your own forum which concerns admins and players... Get real.. A dev walked on admin's paths while an admin some day was a player. Good morning!

Not having the needed files but my mind could actually answer to you, that it should not ever return a different byte value than the players actual level. player.getlevel should be players get level. Im accepting the fact that getStat().getLevel() could return something different, but here, in our case, there isn't any other calculation in order to think that the correct value is going to be returned. As you said, its probably a temp fix

It is... https://prnt.sc/112merp

I aggree after all as a temp fix until finding the problem. But if the 'leak' was real and this calc could return different value than the actual instance level, as you can see if (level == -1) { L2PcInstance local_char = restore(this.getObjectId()); It starts a restore procedure which requires > 1 database connection. All that for calling .getLevel() that is being calling by task managers maybe every +- 10 seconds and for 1 instance. That's horrific

A logical return is the player's level lol. Why would you get a different value from your level value on your L2PcInstance#getLevel method ?? No excuses on that.

I can't know who coded it and for real, i don't care lol.... The fact is, the person who gave me this code (as an answer) had the latest one without touching this thing and as i saw from your last changeset... was there. It maybe does not affect something but the thought to be added there, was maden for a reason after all. Something was broken and trying to catch it.... Most of times, you cant catch something with your eye if it will affect the gameplay or the player or something until you test/debug it live with bots or players. But for real, in 2k21 you have db connections with java 6 style Connection conect = null; try { conect = L2DatabaseFactory.getInstance().getConnection(); PreparedStatement statement = conect.prepareStatement and generally, seems like you have abandoned the structure reparse ... I have more examples right now in my hands to post in order to prove to your client that there are huge mistakes inside that you can't avoid. Nothing personal with you nor your project btw, my opinion is jut my opinion. I found it bad and i said it. i'm just having fun with the other guy who claiming that his sources is the best.

L2jOrion Exercise : Answer the following questions: What was the dev's thought when wrote this code? Why is it coded like that? What's the benefit? Class: L2PcInstance @Override public final int getLevel() { int level = getStat().getLevel(); if (level == -1) { L2PcInstance local_char = restore(this.getObjectId()); if (local_char != null) { level = local_char.getLevel(); } } if (level < 0) { level = 1; } return level; }

Do you want proofs? Learn programming. I dont have sources but i worked on them for really long time. (Not the outdated files) If you cant even understand the way im talking and why im saying all these things. You are a bot.

Exactly. What you didn't understand? Do you have any mental health problem?

Carefull... I don't have the details because i don't have the sources in my hands in order to proove you the "trash". As i said, i worked on it but not working anymore. Feel free to share your sources and lets sit together and compare your l2jorion with something else. Just before that, read a book to learn some things about what code is and what coding quality is. Then come again we can start ... Also, (and this is my last post.) If i'll pick a l2jscoria without even touch the sources, set up my server with 5 custom weapons and 2 farm zones. My players will probably not have any problem...

I gave you the answer in my post. A detailed answer, requires programming knowledge that you don't have and you will not understand. What's the point of collecting the informations that at the end, you will not understand at all...

@L2RAPTOR I will not analyze the programming pov because as i can see, you are not working on that... But, your words goes me back 50 years, where people were happy with the pigeons that send messages to each other. If you could ask someone of them, they would tell you that we are happy to communicate and the way does not matter. Guess what, the way does matters ... Just as how it was done and is being done with medicine and science ... We/they move forward and building better structures every damn day even if we/they are happy with most of them, just because that's how the progress works. I can also assure you that l2jorion is trash. I'll not go deep for my words, i'll just say that i've worked a lot on this source for 4-5 customers who had it, and i'll not do it again.

You don't have to code anything inside the zone's method since the feature is about the player instance. You could make a manager to handle all these actions but this is just another case. Lets begin about the basics. The zone, should only call a method in the player instance without any check for dead/alive since this call will be executed inside of Zone#onDieInside. So, @Override protected void onDieInside(final L2Character character) { + final L2PcInstance player = character.getActingPlayer(); + if (player == null) + return; + + if (!Config.revive) + return; + + player.startAutoReviveTask(); } @Override The player instance now will handle the next actions by itself. The concept is: Before start the task scheduler, you should check if the speficic scheudler is already running. When the scheduler fires the runnable, you should just check if the player is dead or not. If the player will be revived without the auto revive task, just cancel the auto revive. So, Index: head-src/com/l2jfrozen/gameserver/model/actor/instance/L2PcInstance.java =================================================================== @@ -15415,6 +15469,7 @@ public void doRevive() { super.doRevive(); + resetAutoReviveTask(); updateEffectIcons(); sendPacket(new EtcStatusUpdate(this)); _reviveRequested = 0; @@ -19644,4 +19705,41 @@ _currentPetSkill = new SkillDat(currentSkill, ctrlPressed, shiftPressed); } + // The task + private ScheduledFuture<?> _autoReviveTask = null; + + public void startAutoReviveTask() + { + // Before initiate the auto revive task, check if another scheduler is active + resetAutoReviveTask(); + + // Start the task + _autoReviveTask = ThreadPoolManager.getInstance().scheduleGeneral(() -> doAutoRevive(), TimeUnit.SECONDS.toMillis(Config.revive_delay)); + } + + private void resetAutoReviveTask() + { + // If is not running, do nothing + if (_autoReviveTask == null) + return; + + _autoReviveTask.cancel(true); + _autoReviveTask = null; + } + + private void doAutoRevive() + { + // Check for any possible scenario if the player is alive + if (!isDead()) + return; + + doRevive(); + heal(); + teleToLocation(Rnd.get(Config.spawn_loc), false); + } + + private void heal() + { + // Heal the instance + } And the last thing, get the Rnd#get which is generic from aCis sources which is returning a random element of the given list class as parameter. Index: head-src/com/l2jfrozen/util/random/Rnd.java =================================================================== --- head-src/com/l2jfrozen/util/random/Rnd.java (revision 1118) +++ head-src/com/l2jfrozen/util/random/Rnd.java (working copy) @@ -23,7 +23,19 @@ */ public final class Rnd { + + /** + * Returns a randomly selected element taken from the given array. + * @param <T> type of array elements. + * @param array an array. + * @return a randomly selected element. + */ + public static final <T> T get(T[] array) + { + return array[get(array.length)]; + } + With this version of Rnd#get, you can do this: teleToLocation(Rnd.get(Config.spawn_loc), false); instead of int[] loc = Config.spawn_loc[Rnd.get(Config.spawn_loc.length)]; teleToLocation(loc[0]+Rnd.get(-Config.radius,Config.radius), loc[1]+Rnd.get(-Config.radius,Config.radius), loc[2]);

change 'false' with '0'

You are not probably looking at the right table. The thing that the code is using a specific table, doesn't mean you have to look only there. And again, does your sql query contains any 'join' word or does it run another instance of "select from where" as a parameter to run a query?

Do you use any "join" sql query ?? It seems like you have external data in your test database while at your main database you missing them.

My opinion, undoubtedly acis. Just because russian coding style is not my style. Both of them, have different purposes. Lucera is not trying to achieve an l2off performance while for acis, retailness is the primary target. Its clearly about what you are looking for.

Define 'better'