Source aCis - another CRAPPY interlude server

[SweeTs]

Its fine to have experimental things in because some things depend on your mysql configuration/database size/sql traffic and they cant be optimized generally for every user.

 

In sum, if you set it bad, you're facked up.. :) And honestly, I know shit about all the settings, so I could rly do a mess.. :P

[Intrepid]

In sum, if you set it bad, you're facked up.. :) And honestly, I know shit about all the settings, so I could rly do a mess.. :P

 

Than you dont need to touch them because its fine as it is with the preconfiged setup, thats the whole point of it^^

[SweeTs]

Than you dont need to touch them because its fine as it is with the preconfiged setup, thats the whole point of it^^

 

You sure about that? That's the point of it  :happyforever:

 

 

 

Offtopic: 3rd page of troll discussion, I like it. Thumbs Up, lol :D

[Intrepid]

You sure about that? That's the point of it  :happyforever:

 

 

 

Offtopic: 3rd page of troll discussion, I like it. Thumbs Up, lol :D

 

Yes im pretty sure :D

[SweeTs]

Yes im pretty sure :D

 

Ok, so.. Thanks for configs & info. Also, catch a cookie :D

[Intrepid]

Ok, so.. Thanks for configs & info. Also, catch a cookie :D

 

better off with beer, working on packets in the last 7 hours without rest :D

[SweeTs]

better off with beer, working on packets in the last 7 hours without rest :D

 

Without rest? Fail statement, since you spammed with me last 3 pages, so you had a break :D

 

Good then, catch a beer :troll:

[Intrepid]

Without rest? Fail statement, since you spammed with me last 3 pages, so you had a break :D

 

Good then, catch a beer :troll:

 

yes because my eyes are burning...rewrite every single packet by hand(around 700 packets or so) and you'll know dat feeling :D

 

btw guys if you would implement some l2jfree stuff related to security you could drop these home made things of l2j :D

[xdem]

About memory, a nice rework for a project would be to clean all those useless int values and replace them with byte and short variables where possible, but infact who cares for memory nowadays :D

 

Ps: For example change getEnchant to byte. If you check getEnchantEffect you will see that client side enchant effect is byte

[Intrepid]

About memory, a nice rework for a project would be to clean all those useless int values and replace them with byte and short variables where possible, but infact who cares for memory nowadays :D

 

Ps: For example change getEnchant to byte. If you check getEnchantEffect you will see that client side enchant effect is byte

 

that would mean an impossible to notice improvement :DDD

[xdem]

Byte consumes 70 -75% less memory than int, I would really like to see a project implementing these stuff

[xdem]

that would mean an impossible to notice improvement :DDD

 

Yes and no, again I will use Enchant value for example, 4000 server community stores about 30 - 40k int values of enchant or more maybe, which results into 32bit x 40.000

Those values could be byte 8bit x 40000

[Intrepid]

Yes and no, again I will use Enchant value for example, 4000 server community stores about 30 - 40k int values, which results int values or 32bit x 40.000

 

Those values could be byte

 

Common strength reduction could be applied also but compared to the issues as far as performance goes in the pack atm, these are nothing

[KaL]

Any prevision on when fórum will be normalized?

[Tryskell]

Any prevision on when fórum will be normalized?

"Normalized ?"

 

Editing int to whatever more little is a loss of time, and can lead to serious issues. I didn't check further, but I think packets use almost int only, no ? You can make the test for fun, editing 30% of a pack or so, and tell us if it really works ;p.