Project L2J Mobius Highfive

[Tryskell]

I love StatsSet I find it genious

 

It's awesome to initialize objects properties fast, notably templates, yup.

[xxdem]

One thing I hate with L2J is the integer based objectId, anyone with me?

[Mobius]

One thing I hate with L2J is the integer based objectId, anyone with me?

 

It can be unlinked from objects, like retail is.

Edited June 2, 2016 by Mobius

[xxdem]

It can be unlinked from objects, like retail is.

 

The point is, to have a server side hidden objectId and generate new for the clients side runtime. An even better idea is to wrap the hidden server side objectId into a Passport object that is unique and static for every player so you can do more stuff with it.

[Tryskell]

Erm, the point of objectId is to stay unique for the object, and released when object is really destroyed (and I speak of server destroy, like delete an item or delete a spawn entirely).

 

I find it useful personally, and it's transparent if you move the initialization into L2Object directly (another cleanup to do).

 

In what specific case you find it wrong ? With what could you replace such unique id with ?

Edited June 2, 2016 by Tryskell

[SweeTs]

So people can sell your work just because they add some shared shits? :D

I didnt said that, my point is, if it's easily accessible, it's pointless to buy another "pro/bugless" (shit) pack :D

[Sdw]

One thing I hate with L2J is the integer based objectId, anyone with me?

Why is that, you still need something for packet

[xxdem]

Why is that, you still need something for packet

 

I already explained before the flaws. I will do it again:

 

The current objectId is always static on the object and I can post these few flaws on the fly (obviously much more exist)

• Very easy to create client hacks / scripts / edits / flood
• Dumb primitive int data type that can only perform mathematical operations (I will explain later why I call it dumb)
• L2Official objectIds are not final on the objects (even players)

 

So instead of having a single int as objectId we could make passport objects that ARE ALWAYS STATIC on the players at least (further optimization for any object?)

 

This Passport object can now

• Have a hidden static server-sided UNIQUE objectId
• Dynamically change / update the client transmitted objectId on demand (clientObjectId int type generated on the fly (bucket hashing so nothing strict here))
• We can attach routines on it (event engines, quests will authenticate easier and more efficient)
• Be Compare to other Passport objects as fast as comparing the two old objectIds

Im already experimenting this on my live server with minimal issues

 

L2J really needs something static between _objectId and L2PcInstance reference let me give a basic example why:

 

Check this scenario:

• Player1 registers on the event / quest / whatever and the developer who created it stores him temporarly in ANY of the java Collection (may be List, Set or whatever)
• Player 1 unregisters, he is removed
• Player1 registers again
• Player1 restarts, a new L2PcInstance reference is assigned to him
• Player1 registers on the event again but the developer didn't handled his disconnection before so our Collection has 2 references for the same actual player
• The event ends and the player is rewarded twice

The above is a very basic example scenario that proves that the current design of player authentication is non-existant. Now imagine a very complex scenario, the authentication part gets out of hand very easily and objectId alone can't help you with efficient and good OOP code.

Edited June 2, 2016 by xxdem

[`NeverMore]

L2J Sunrise manage to sell a 2 years outdated L2J server without shame. So ...

One of my customer's is Mobius itself :D 

cool isn't it?

[AccessDenied]

One of my customer's is Mobius itself :D

cool isn't it?

Proofs or never happened.

[Sdw]

One of my customer's is Mobius itself :D

cool isn't it?

Yes it is, might the beginning of his pack

[`NeverMore]

He can confirm this.

If not, i can post images from skype, SVN etc.

But is not necessary

[Sdw]

I already explained before the flaws. I will do it again:

 

The current objectId is always static on the object and I can post these few flaws on the fly (obviously much more exist)

• Very easy to create client hacks / scripts / edits / flood
• Dumb primitive int data type that can only perform mathematical operations (I will explain later why I call it dumb)
• L2Official objectIds are not final on the objects (even players)

So instead of having a single int as objectId we could make passport objects that ARE ALWAYS STATIC on the players at least (further optimization for any object?)

 

This Passport object can now

• Have a hidden static server-sided UNIQUE objectId
• Dynamically change / update the client transmitted objectId on demand (clientObjectId int type generated on the fly (bucket hashing so nothing strict here))
• We can attach routines on it (event engines, quests will authenticate easier and more efficient)
• Be Compare to other Passport objects as fast as comparing the two old objectIds

Im already experimenting this on my live server with minimal issues

 

L2J really needs something static between _objectId and L2PcInstance reference let me give a basic example why:

 

Check this scenario:

• Player1 registers on the event / quest / whatever and the developer who created it stores him temporarly in ANY of the java Collection (may be List, Set or whatever)
• Player 1 unregisters, he is removed
• Player1 registers again
• Player1 restarts, a new L2PcInstance reference is assigned to him
• Player1 registers on the event again but the developer didn't handled his disconnection before so our Collection has 2 references for the same actual player
• The event ends and the player is rewarded twice

The above is a very basic example scenario that proves that the current design of player authentication is non-existant. Now imagine a very complex scenario, the authentication part gets out of hand very easily and objectId alone can't help you with efficient and good OOP code.

Well I see the point, but for your scenario the dev is to blame :D he could have used weakref

 

Anyway, I fail to see how much damage it would cause to replace the current object ID, since you did it, any insight? I'm busy enough to avoid some dumb crusade:D

[xxdem]

Well I see the point, but for your scenario the dev is to blame :D he could have used weakref

 

Anyway, I fail to see how much damage it would cause to replace the current object ID, since you did it, any insight? I'm busy enough to avoid some dumb crusade:D

 

The weakref is not an optimal solution, and I blame the project for this reason, we are supposed to create weakrefs all the time that complicate things even more and usually are innefficient or slow and eventually the projects end up with thousand of different weakrefs or other ways to counter-measure this. All these originate from the weak objectId ofcourse.

Edited June 2, 2016 by xxdem

[Sdw]

Well weak ref is not a solution for sure, we use another I'm lazy to describe but not optimal either for sure.