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

    • @Silvin Thanks    This will be very useful.
    • Hello, everyone. I am an American, looking to start my own server.... I am looking for a dev, to help me build & edit a pride-style server.  Basically, at this point: (being Lineage 2 is a dying game - with botters overtaking) I'm not looking to spend hundreds-thousands of dollars.... Even if it's a cheap not "pride-style" server, I'll be content with that, too. I have everything else as far as Name, Discord, website, and staff - I just need a dev, to help with the files.  Thanks! 🙂 
    • ## SuperPoint Editor   SuperPoint Editor is a practical visual editor for Lineage II PTS 'SuperPoint.bin' files. It is built for people who need to inspect, fix, rebuild, and draw server routes without digging through binary data by hand.   ### What You Can Do   - Open and edit 'SuperPoint.bin' files. - Export BIN data into a readable TXT format. - Save edited data back into a valid BIN file. - Validate routes before saving. - Work with SuperPoint routes, points, directed connections, and path records in tables. - Add, duplicate, delete, and reorder points. - Create direct and reverse connections between route points. - Automatically generate connections between neighboring points. - Edit raw point coordinates: 'X', 'Y', 'Z', 'Index', and 'Delay'. - Keep route names and internal route data organized. - Use either English or Ukrainian interface language.   ### C4 Server Support   Some C4 servers have 'SuperPoint.bin', but do not have 'superpointinfo.txt' in scripts. The editor supports this case directly. When 'superpointinfo.txt' is not found near the BIN file, the editor can open the BIN in C4 mode. In this mode, 'Fstring ID' is disabled because that value belongs to 'superpointinfo.txt', not to the BIN itself. The editor will not generate or modify 'superpointinfo.txt' while working in this mode. This keeps C4 data clean and avoids creating script files that the server does not actually use.   ### superpointinfo.txt Support   For chronicles that do use 'superpointinfo.txt', the editor can load and synchronize it together with the BIN data. When saving, the editor updates route nodes and coordinates while preserving existing metadata such as: - 'npc_name' - 'move_type' - 'fstring_index' - 'social_number' - 'delay' New nodes are generated with safe default values, so existing script metadata is not accidentally wiped.   ### Geodata Tools   The editor can also open converted geodata '.dat' files and display them as a map. This makes route editing much more visual. You can: - Load geodata and inspect the terrain by layer. - Zoom and pan around the map. - Create a new SuperPoint directly from a map cell. - Draw a route by clicking on the geodata. - Drag existing points to new positions. - Automatically snap 'X/Y' to the selected geo cell. - Use the selected geodata layer to fill the point 'Z'. - See all routes on the map or focus only on the selected one. This is especially useful when building new NPC movement paths or correcting bad route coordinates.   ### Connections and Paths   SuperPoint connections are directional. A connection from point '3' to point '2' is not the same as a connection from point '2' to point '3'. The editor makes this explicit by separating: - route points, - directed connections, - and the actual path records used by each connection. For simple cases, it can create direct path records automatically. For more complex movement, you can edit the path points manually. ### Built for Safe Editing The editor includes validation before saving, so common structural problems can be caught before a broken BIN is produced. It also verifies rebuilt BIN files through the converter engine. The goal is simple: edit quickly, but do not silently damage server data.   ### Unknown Field   This small 'Unknown' field is part of the original BIN structure. Most official-looking files keep it as '0', and for regular route editing there is usually no reason to change it. The editor exposes it so nothing from the BIN is hidden or lost. If you do not know exactly what your server uses it for, keep it at '0'. Download
    • NpcGrp não salva no interlúdio e da crítico quando coloca ele no cliente, já testei ele antes.
  • 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..