Discussion Event Engine

[xxdem]

I wanted my event engine to be fully controllable by the individual XML files, all good until the complexity of the XML grew to a level that its very hard to debug the parser and add more features. So I came up with the idea of the Script tag that can do many things with a simple code.

 

New Update

 

v5.1 (Beta) new tags: Script

 

Scripts in this EventEngine can be any language the user wants (python, java, javascript, scala, etc)

 

A quick preview of the XML:

 

 

 

The hook attribute will hook your code where you want automatically, its self explanatory.

 

call by id example:

 

 

 

 

Made this topic to get the point of view of customers (users) and other developers...

 

//discuss

[Nik]

That scripts thing is just way too much now.

Any developer in this case will prefer to extend a class and make methods as he likes to. Its just way easier to read/understand.

Any non-developer will not even have the slight idea what to do in this case and how to use such scripts in xml...

 

ThugEscape::legitimateKill($any, $thug)

... I don't have the slight idea what this method is, where it is called and what are those variables... Imagine how it looks to the regular person.

 

I suggest you to make it so people extend AbstractEvent in scripts folder and they change the preferred methods as they like. Current way needs to make scripts anyway and I cannot imagine a case where im going to use the same script for 2 or more events, unless Im too lazy and I make copy-paste redundant events. Basically just point out what "script AI" (sub-classes of AbstractEvent) the event is going to use, and forget about 123123 hooked scripts to methods to wtf... I think people are used to changing at least constants in scripts, so you can make a set of pre-done scripts with given constants. Maybe you can add an exception to change constants of chosen script from XML, but that's as far as I suggest you to go.

[xxdem]

That scripts thing is just way too much now.

Any developer in this case will prefer to extend a class and make methods as he likes to. Its just way easier to read/understand.

Any non-developer will not even have the slight idea what to do in this case and how to use such scripts in xml...

 

ThugEscape::legitimateKill($any, $thug)

... I don't have the slight idea what this method is, where it is called and what are those variables... Imagine how it looks to the regular person.

 

I suggest you to make it so people extend AbstractEvent in scripts folder and they change the preferred methods as they like. Current way needs to make scripts anyway and I cannot imagine a case where im going to use the same script for 2 or more events, unless Im too lazy and I make copy-paste redundant events. Basically just point out what "script AI" (sub-classes of AbstractEvent) the event is going to use, and forget about 123123 hooked scripts to methods to wtf... I think people are used to changing at least constants in scripts, so you can make a set of pre-done scripts with given constants. Maybe you can add an exception to change constants of chosen script from XML, but that's as far as I suggest you to go.

 

Yeah, I totally agree with you its again complicated, but I've created this Script support to counter big and complex events. For example a survival map with dozens of timers, doors, new npc spawns etc.

 

By attaching a script on the event's template and reloading it with a simple //reload events command made my life easier for very complex and huge event scenarios, but again it counter attacks itself with complexity...

 

ThugEscape::legitimateKill($any, $thug) calls the legimitateKill method from ThugEscape class if and only if the second parameter is the thug instance (L2PcInstance object in this case)

 

public void legitimateKill(final L2PcInstance killer, final L2PcInstance victim)

 

 

Complicated but still a good tool.

 

But the most important reason I've added script support to the event template is that as you can attach multiple templates on a single AbstractEvent child, for example Escape.java

 

you can create two different events that use Escape.java class for example; both events are handled from the same java class BUT they are different because the template and each template's scripts are different.

[Tryskell]

At this point of configuration, better open and edit directly the file with Eclipse, no ? It's a bit overkill.

 

Those ThugDied and ThugPicker (which I suppose could be based on regular quest listener onDeath / onKill) are that fat they need their own file ?

Edited February 22, 2016 by Tryskell

[Nik]

Well, do as you like, but I suggest you to keep things simpler. Even if you are good developer and this complexity is ok for you, its still abnormally complex in my option. At some point this complexity will go against you, and cause you to get confused more often than it should. Even if you comprehend it now, it doesn't mean you will always comprehend it without mistake. Chinese people created their traditional language very complex but very robust, now many Chinese are unable to learn that language and learn simplified instead :D

[xxdem]

I totally agree with your points, but as I said before the main purpose was not to counter complexity, but to extend the templates of the events.

 

 

 

Each template can be individually unique regardless of the class it extends... Look at this example, RuneCastleSurvival and GoddardMassacre are both handled by the java class Survival, but they are much different due to configuration in their XML (The template)

[Nik]

Well I don't have general idea of the structure of this event engine, so I can't say anything.

What is the point of "all in XML" thing if only you can understand it?

[xxdem]

Well I don't have general idea of the structure of this event engine, so I can't say anything.

What is the point of "all in XML" thing if only you can understand it?

 

Imagine a server with a shitload of different and unique event templates. Would it ever get boring?

[Nik]

Yes, so far with my experience, players don't tend to like shitload of events thrown in their face. Most of them just get confused when there are more than a handful of events. Unless you are able to present that many events nicely, players won't pay much attention to the different kinds of events. You either make a handful of strongly different events, or make basic event templates like TVT and give different objective each time to the event. In this case your XML thing will be the most useful, but again, if I have to make 5 different XML templates for the same TVT event with 5 different mini-objectives, it just sucks.

[Tryskell]

Imagine a server with a shitload of different and unique event templates. Would it ever get boring?

 

Generally events follow some "trends", the point is to abstract it to a maximum (team distribution, spawn system, attackable status, reward, etc), and then gather all "shared" methods over a sort of commons package.

 

Basically, even with the simple Quest.java, you can already do a lot, so I tbh don't get what you need to add more. All retail events from L2 can be handled by its children, LongTimeEvent. If your event needs a complex scripting, it's maybe it's simply too complex (sounds stupid to say that, but well...). You can handle a lot of "on the fly" behaviors using memos (npc/server/player) and isScriptValue() / setScriptValue() for NPC.

 

Well without an specific exemple of what you try to achieve you couldn't do it without your system, it's hard to believe it's that useful. Until you're the only one to XML config it but then the whole thread shouldn't be a problem :P.

[Sdw]

I have to disagree Tryskell, Quest.java, at least L2J version have a shitload of nonsense and limitation (onKill/onAttacked triggered for Attackable only for instance) while LongTimeEvent is just a piece of useless shit

[xxdem]

By using Quest.java Im commiting on being compatible only with the Project fork I've coded it, thus it requires lots of adaption to work on another chronicle. What if I want to adapt it on a project where Quest.java doesn't exist or if its totally different? Things get messed up.

 

My architecture now is:

 

Events Core Library (compiled) -> Events classes and xml templates (source) -> Driver Interface (compiled or not) -> Any Project (compiled or not)

 

And really solves my hands in terms of addapting cause I only need to create Driver Interfaces for different project which is an easy and fast task

Edited February 22, 2016 by xxdem

[Tryskell]

onKill/onAttacked triggered for Attackable only for instance

 

It's only a matter to cut/paste 2x6 lines of codes, from one class to another (or simply rework the system of listener and put everything on L2Character level). About LongEventTimer, I use my personal SheduledQuest (which is probably as shitty as, but well), so i can't say.

 

@xxdem, the idea wasn't to reuse Quest.java, at all, but just tell you than most of needed methods already exist. Which doesn't explain your need of code complexity, as most if not all can already be handled by shitty stuff as Quest.java.

Edited February 22, 2016 by Tryskell