Jump to content

Recommended Posts

Posted (edited)

Hey everyone.

 

This is the basic structure of an event engine i have made, that uses Thread.sleep() method for delays(to avoid multiple threads). It supports scheduling of events FIXED or TIMES(check description in EventSchedule class).

 

There is also a TvT event installed in the engine.

 

HOWEVER, it is experimental, as the title says, which means it needs to be extended in order to be fully functional. I just shared it cause it might help someone.

 

Coded for interlude.

 

(Check Event.java for the currently available methods.)

 

Here: http://pastebin.com/ipmH8VhV

Edited by An4rchy
Posted

Hey everyone.

 

This is the basic structure of an event engine i have made, that uses Thread.sleep() method for delays(to avoid multiple threads). It supports scheduling of events FIXED or TIMES(check description in EventSchedule class).

 

There is also a TvT event installed in the engine.

 

HOWEVER, it is experimental, as the title says, which means it needs to be extended in order to be fully functional. I just shared it cause it might help someone.

 

Coded for interlude.

 

(Check Event.java for the currently available methods.)

 

Here: http://pastebin.com/ipmH8VhV

thanks for the share 

Posted

btw for anarchy:

 

Remove these abstract classes, they are not needed, just make all the booleans return false and all voids empty

 

Imo the class should be abstract and implement Runnable meaning that the only abstract method is run(), run will be the main part of the event

+       public abstract void runEvent();
+       public abstract boolean proceed();
+       public abstract EventSchedule getScheduleMethod();
+       public abstract String getScheduleTimes();
+       public abstract String getName();
+       public abstract boolean allowFight();
+       public abstract boolean allowTargetting();
+       public abstract boolean allowFriendlyFire();
+       public abstract boolean allowEscape();
+       public abstract boolean allowToVillage();
+       public abstract void onPlayerRegister(L2PcInstance p);
+       public abstract void onDie(L2PcInstance p, L2PcInstance killer);
Posted

Well all those abstract methods are necessary for an event, since they define players' actions in it. I actually wanted to simplify the creation of an event  without leaving possibilities for mistakes that's why i made them abstract.

Posted

Well all those abstract methods are necessary for an event, since they define players' actions in it. I actually wanted to simplify the creation of an event  without leaving possibilities for mistakes that's why i made them abstract.

 

you define something abstract when theres really no way to implement it on the abstract class.

 

for example you have onDie abstract, thats wrong since you can handle player death from the abstract class

 

like:

 

TvT:

 

@Override

public void onDie(...)

{

     Announce(killer has killed victim);

     super.onDie(...);

}

 

parent:

public void onDie()

{

     //handle the death code

     //that is common for all other events

}

 

 

 

//////////////////////////////////////////

 

example 2

 

abstract public boolean areSameTeam(player1, player2);

 

thats wrong, cause you CAN

 

public boolean areSameTeam(player1, player2)

{

     return false;

}

 

TvT:

 

@Override

public boolean areSameTeam(player1, player2)

{

       return getTeam(player1) == getTeam(player);

}

 

Deathmatch

 

//no need to override anything, areSameTeam returns from its parent

 

 

 

 

 

I really hope you get my point

Posted

About the voids you're right, i get your point.

 

The booleans it's not wrong the way i have it, it's just necessary even when it shouldn't be.

Posted

well, the idea isn't bad.

first of all you should convert few methods to static

than few other methods (as I said in the other topic) should be wrapper to avoid code duping

than... why do you hardcode events to the core? TvT could be outside in DP as a script

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Posts

    • IAM one of customers of this project. Have anti cheat, have user panel everything is working. Blocking adrenaline trashy plans without any problems.  So just GL for all lin2 project. I get support every time I need it. 
    • Convert package formats from Old to New in one click Create new packages of any format Lineage2Ver121 encryption (included in the package) Safe editing: work in a copy, full undo history (Ctrl+Z / Ctrl+Shift+Z), single "Save" button System integration Open .utx / .ugx files with a single click in Explorer (associations are registered during installation) One example: open a file and add its tab to an existing window Multilingual interface (EN, RU, UK, ES, PT, EL, KO, VI, ZH) — the language is picked up from the system Supported formats Packages: UTX, UGX Textures: RGBA8, DXT1, DXT3, DXT5, G16, P8 Resources: GFX (Scaleform) Requirements Windows. Java is not required—it's included in the build. Installation Run La2Tools-3.0.2.exe—the installer will create shortcuts and register related files. Alternatively, use the portable version. https://la2.tools/files/La2Tools_3.0.3_setup.exe   https://la2.tools/files/La2Tools_3.0.3_portable.zip  - Portable version  
    • WHEN SAYING “YES” IS A MISTAKE Not every project is worth taking on, even if the client is ready to pay. Sometimes refusing isn’t about losing money — it’s about protecting your reputation and time. Over the years, we’ve learned to quickly spot the cases that are almost guaranteed to turn into problems. Here are the most common situations where we turn down work: ▪ The client wants it “like everyone else’s,” but with lots of custom changes and on a minimal budget ▪ There are no proper source materials, yet the deadlines are already burning and everything is needed “yesterday” ▪ Constant changes to requirements after the work has already started ▪ A task with a very low chance of success, but very high expectations ▪ The client isn’t willing to discuss the process and sees us as just an executor - A good result almost always starts when both sides have an honest understanding of the risks and real possibilities of the project. If you’re currently discussing a project and unsure whether to move forward — write to us. We’ll honestly and directly tell you whether it’s worth taking on or if it’s better to look for another solution. › TG: @mustang_service_ms ( https:// t.me/ mustang_service_ms ) › Channel: Mustang Service ( https:// t.me/ +JPpJCETg-xM1NjNl ) #documents #drawing #photoshop #refuse #cases
    • The price reflects the value of the project, not just the source files. This is a complete, production-ready server that has already proven itself over the course of a full year, with a loyal player base and no major issues requiring ongoing development. To put it into perspective, the asking price is approximately what the server generated in one year. You're not buying an unfinished pack that still needs months of work, you're buying a polished, fully tested, revenue-proven project that's ready to go online. Considering that, I believe €35000 is a fair price.
    • How we can explain the amount? Is something special there in?
  • Topics

×
×
  • Create New...

Important Information

This community uses essential cookies to function properly. Non-essential cookies and third-party services are used only with your consent. Read our Privacy Policy and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..