Jump to content

Myext64 - My New Opensource Gracia Final/epilogue Extender


Recommended Posts

I'm writing a brand new Gracia Final/Epilogue extender, if you want to try it or have a look at sources, I'll put some development versions here: it's hosted on bitbucket.

 

https://osamelahora.cz/MyExt64/ https://bitbucket.org/l2shrine/extender-public

 

Now it does almost nothing but I'll add some new stuff over time... I'm adding new stuff over time :)

 

MyExt64

What is MyExt64
MyExt64 is new opensource extender for l2off Gracia Final server (l2_off_gracia_final) supporting Gracia Final and Gracia Epilogue chronicles. It uses some knowledge from OSIE extender, MXC extender and maybe other extenders.

 

Features

  • Supports protocols 83 (Gracia Final) and 152 (Gracia Epilogue update 1)
  • Protocol 87 (Gracia Final update 1) should be working but is not tested
  • Supports Gracia Epilogue skill enchanting + buy/sell
  • Supports Gracia Epilogue refund
  • Supports Gracia Epilogue mail system
  • Bunch of bugfixes (some ported from OSIE, some ported from MXC extender)
  • Voice commands - offline trade, experience gain on/off, server time, online player count
  • Configurable item enchant (safe/chances)
  • Custom drop/spoil rate algorithm
  • Custom event drop algorithm (flat chance based)
  • Players in the same command channel are treated as allies
  • Configurable max level for main/subclass
  • Global shout/trade
  • Vitality multiplier
  • Configurable clan restriction (penalties)
  • Configurable buff slot count + max divine inspiration bonus
  • Configurable vitality level ranges
  • Configurable autoloot system
  • Embedded Gracia Final AI (NASC) compiler
     

How to use it
If you're not familiar with l2off, it will probably require learning some stuff (MXC forum is a good start).

To just use the last build, copy following files from server folder in this repository to your server folder:

* MyExt64.dll - main extender file
* MyExt64.ini - extender configuration
* MyExt64Loader.exe - extender loader

and run the server via MyExt64Loader.exe

If you're more experienced with messing around PE files, you can add MyExt64.dll to import table of L2Server.exe and add call to DllMain.

How to compile it
You should get Visual Studio 2005. Maybe it would be possible to compile it on some newer Visual Studio, but you'll have to define your own templates for std::vector and std::map (and possibly more containers) to match memory layout of their VS2005 versions.

MyExt64 has no external dependencies and requires only standard libraries for Windows development.

Edited by eressea
  • Like 2
  • Thanks 4
Link to comment
Share on other sites

some of source files are from other extenders? like CLog and user?

 

CLog is in fact from l2server itself - now I have only 2 functions and 2 constants, not much, but I don't need more for now

 

I get some inspiration from OSIE (packet handler hooking etc), some inspiration from c4-based extenders I've found and of course some inspiration from l2server itself, but I don't copy code as is (except some tiny pieces of machine code in hex which probably can't be written better)

Edited by eressea
Link to comment
Share on other sites

I'm writing a brand new Gracia Final/Epilogue extender, if you want to try it or have a look at sources, I'll put some development versions here:

 

https://osamelahora.cz/MyExt64/

 

Now it does almost nothing but I'll add some new stuff over time...

osamelahora . cz   gg nice web ;D

Link to comment
Share on other sites

New version https://osamelahora.cz/MyExt64/2016-06-19-R1/ What's new: bugfixes and Gracia Epilogue skill enchanting

Edited by eressea
Link to comment
Share on other sites

So many opportunities for templates. 0 templates :(

 

Oh i see that opportunity for packet sending and receiving... 100% templated... Oh!

Can you make my dream come true?

Edited by Szakalaka
Link to comment
Share on other sites

So many opportunities for templates. 0 templates :(

 

Oh i see that opportunity for packet sending and receiving... 100% templated... Oh!

Can you make my dream come true?

 

ur the classic example why C++ sucks balls today

Link to comment
Share on other sites

But on a serious note, why do you use OpenProcess, VirtualProtectEx and all the HANDLE based operation when its a dll so its in the same process as the server itself?

I briefly looked throught the code :) Want to give opinion.

 

extern HANDLE server; // externs in such scenario are bad, do you even need the handle if dll is indide?

 

CUserSocket::IgnorePacket::IgnorePacket(const wchar_t *format, ...)
: std::exception() // this is redundant, default constructor

 

Disassemble(packet, "dd", &skillId, &skillLevel); // runtime format is very error prone. Imagine you write s instead of d in some rare packet. Disaster!

 

Many things should be specified as const. For example, shouldnt "wchar_t* CUser::GetName()" be actually const whar_t* ? (Not saying about raw pointer risk)

 

Singleton should definitely return a reference. With "static CSkillEnchantDB* GetInstance();" you can switch the pointed object, you can even delete it and do many other bad stuff u avoid using refernce. And btw, its possible to accidentaly copy thsi singleton xD (mark copy operator as deleted)

 

Logger should be wrapped for safe usage. Again, if you pass an int and type "s" you are dead. With usage of tempaltes you can make compiler generate typesafe code and automatically (and properly) create format for you :)

 

Generally there are too many static stuffs

 

But thats only my humble opinion, just want to help ;)

 

And to guy above, i wont even comment. Pretty sure you know jack shit about this language

Edited by Szakalaka
Link to comment
Share on other sites

So many opportunities for templates. 0 templates :(

 

Oh i see that opportunity for packet sending and receiving... 100% templated... Oh!

Can you make my dream come true?

 

I use templates when I need templates, not when I see opportunity to use templates :)

 

 

Many things should be specified as const. For example, shouldnt "wchar_t* CUser::GetName()" be actually const whar_t* ? (Not saying about raw pointer risk)

 

 

 
I'd like to use std::wstring instead but I can't - do you even know what extender is and how it works? I have to do dangerous stuff there...
Edited by eressea
Link to comment
Share on other sites

I sure do. You reverse the existing compiled binary and make runtime patches to it, get data from it etc. Do your thing wish u the best :)

 

Aha, but why u cant? :)

Edited by Szakalaka
Link to comment
Share on other sites

Aha, but why u cant? :)

 

I can't simply replace that wchar_t* in CSharedCreatureData structure to std::wstring so GetName() would have to create a copy every time you access it...

Link to comment
Share on other sites

Congratulations friend.

because start project in visual studio 2005 ?no it is best visual 2015 ?

No go bring problems future?

It HAS to be 2005, the server was compiled in VS 2005 so using any other version will mean any STL templates could be, and are, different from what it is you are extending which then prevents you from using any of the ones which exist in memory in the server, and the l2server heavily utilises stl containers.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...