Jump to content

Recommended Posts

Posted

You could, indeed, get this done simply by giving characters a passive skill and applying the bonuses depending on the character class, as Kelrzher said. But you're not really going to balance anything that way.

 

Lineage II always have had its very own meaning of balance.

well... at least it's something.. :P

Posted

Create a table, array or whatever container to hold the values you want to edit, and then simply call it.

 

Example Map<Integer, int[]> : first int would be clas id, and then the array holds the value. Eventually imbricated Maps if you want to put weapon types : Map<Integer, Map<WeaponType, int[]>>.

 

Your code is barely readable, and hard to maintain.

Posted

Create a table, array or whatever container to hold the values you want to edit, and then simply call it.

 

Example Map<Integer, int[]> : first int would be clas id, and then the array holds the value. Eventually imbricated Maps if you want to put weapon types : Map<Integer, Map<WeaponType, int[]>>.

 

Your code is barely readable, and hard to maintain.

Finally a real feedback.

Thank you for your answer but i think you are kinda wrong...

I can't hold 2 Map values with the same key, can I?

I mean... to do that i must put

Map.put("Class 96", Map2.get("SWORD",
{
     1.2,
     1.1,
     1.3
};)

and then

Map.put("Class 96", Map2.get("DUAL_SWORD",
{
     1.0,
     1.2,
     1.3
};)

Can i actually do that?

Posted (edited)

I did a similar approach for aCis schemes buffer : schemes are ordered by player and by scheme name. So you have first to retrieve player id, then scheme name and only at this moment you refer to scheme (which itself holds a list of buffs)

 

You, you want to retrieve player classid, then retrieve weapon type, then only you refer to array of values.

 

From what I understand, it fits.

 

https://xp-dev.com/svn/aCis_community/aCis_gameserver/java/net/sf/l2j/gameserver/datatables/BufferTable.java

 

See _schemesTable implementation.

 

PS : you are right, you can't put twice the same key, otherwise it replaces. So you have to feed entirely map2, then only when map2 is fed you place on correct classid. Then you clear() map2, refeed it with correct info, and put it on another classid. Do the same for all classes.

 

Your Map would probably be Map<Integer, HashMap<L2WeaponType, List<Integer>>>. If you dont like List, use regular int array (maybe easier to refer to it : index[0] for heavy, index[1] for light and index[2] for robe).

 

AVOID STRINGS. It's fat to stock and you will have extra operations to retrieve infos.

 

You can also decide to hold info on xml or properties file, and feed the Map that way. A //reload config and the whole crap could be reloaded.

Edited by Tryskell
Posted (edited)

I did a similar approach for aCis schemes buffer : schemes are ordered by player and by scheme name. So you have first to retrieve player id, then scheme name and only at this moment you refer to scheme (which itself holds a list of buffs)

 

You, you want to retrieve player classid, then retrieve weapon type, then only you refer to array of values.

 

From what I understand, it fits.

 

https://xp-dev.com/svn/aCis_community/aCis_gameserver/java/net/sf/l2j/gameserver/datatables/BufferTable.java

 

See _schemesTable implementation.

 

PS : you are right, you can't put twice the same key, otherwise it replaces. So you have to feed entirely map2, then only when map2 is fed you place on correct classid. Then you clear() map2, refeed it with correct info, and put it on another classid. Do the same for all classes.

 

Your Map would probably be Map<Integer, HashMap<L2WeaponType, List<Integer>>>. If you dont like List, use regular int array (maybe easier to refer to it : index[0] for heavy, index[1] for light and index[2] for robe).

 

AVOID STRINGS. It's fat to stock and you will have extra operations to retrieve infos.

 

You can also decide to hold info on xml or properties file, and feed the Map that way. A //reload config and the whole crap could be reloaded.

hmmm bad idea... to much Map calculations...

The code gets the final outcome from Formula.java and it gets calculated with the code (%) and gives the final damage...

I think your thought could cause performance issues.. Imagine all these Map calculations in each hit or skill.. On a server with more than 20 people pvp'ing, the server would lag really badly i guess, wouldn't it?

 

Edit: I'm not using string.. It doesn't need too actually... I think xml would be better than properties... too much values...

Edited by xXObanXx
Posted
Your code is barely readable, and hard to maintain.

If you read and understand the first class, then you know the rest of the code... It's not hardcoded at all but i wanted to keep the performance part, that's why i didn't use any Map.

And I steel don't know what this code's performance would be in a live server, that's why i asked for a feedback, to tell me your thoughts :)

Posted (edited)

The cost of 2 maps .get() is neglictable compared to the gain of readability.

 

I don't even speak of my last point, which is the possibility to load from a config file, and so you can edit your crap externally, without the needs to recompile and replace your .jar. In any case, if you want to edit using an external way, you will have to use my method or a derivated (container).

 

If you state about performance issue, that means you got no clue what is REALLY happening during a server session. If we speak about spawns, that's 60k concurrent map, updated every second, according L2WorldRegion which are 88*128 = 10k. That's right you got 10k region, each holding 2 maps = 20k maps and a task to activate/desactivate it = 10k tasks.

 

As you can see, babbling about 2 .get() and a static map holding infos is kinda nonsense, while knownlist system is basically said 80k Maps and 10k tasks.

 

Finally if you want to edit, one day, the main formula used xxx times you have to edit it xxx times. I will have only a single line to edit.

Edited by Tryskell
Posted

I did a similar approach for aCis schemes buffer : schemes are ordered by player and by scheme name. So you have first to retrieve player id, then scheme name and only at this moment you refer to scheme (which itself holds a list of buffs)

 

HashhMap<L2WeaponType, List<Integer>>>. If you dont like List, use regular int array (maybe easier to refer to it : index[0] for heavy, index[1] for light and index[2] for robe).

 

AVOID STRINGS. It's fat to stock and you will have extra operations to retrieve infos.

 

You can also decide to hold info on xml or properties file, and feed the Map that way. A //reload config and the whole crap could be reloaded.

 

And the benchmarks:

 

LOAD:

 

gsDhXDI.png

 

SAVE IN DB:

 

YguonDy.png

 

 

Ofc all ingame operation are done in the RAM and there's no DB connections. The schemes are loaded once in db, then truncated and saved in DB using myISAM ofc.a

Posted

Finally a real feedback.

Thank you for your answer but i think you are kinda wrong...

I can't hold 2 Map values with the same key, can I?

I mean... to do that i must put

Map.put("Class 96", Map2.get("SWORD",
{
     1.2,
     1.1,
     1.3
};)

and then

Map.put("Class 96", Map2.get("DUAL_SWORD",
{
     1.0,
     1.2,
     1.3
};)

Can i actually do that?

Well why don't you create support class?

Example

 

public class classBalance
{
    int values[];
    string name;

    public classBalance(String nm,int vl)
    {
        name = nm;
        values = vl;
    }

    //create your own get and set methods
}


So you could use something like that:

Map<Integer,classBalance>;

 

Dunno if this is gonna be "heavy" for your system or generally if it is heavy but for sure it will be more readable and easy to work on it. ( I guess)

Posted (edited)

private HashMap<Integer, HashMap<String, ArrayList<Integer>>> schemeCache = new HashMap<>();

 

L2AEPvP scheme buffer !

 

I have written it from zero, based on DrHouse scheme buffer (shared on L2J).

 

I don't have a clue what is L2AEPvP. If you or another guy made a similar implementation, that only means it was the most obvious implementation. The saving process is also made on server shutdown.

Edited by Tryskell
Posted (edited)

I have written it from zero, based on DrHouse scheme buffer (shared on L2J).

 

I don't have a clue what is L2AEPvP. If you or another guy made a similar implementation, that only means it was the most obvious implementation. The saving process is also made on server shutdown.

 

 

L2AEPvP its aCis 260 rev still online today, I've coded it's scheme buffers based on that HashMap

Edited by xxdem
Posted (edited)

I'm sorry boys but I don't get it..

It doesn't need to store all these informations into Maps.

Each player has a different class and weapon.. but I don't get it why I should do all this...

It's like a duplicate of the whole class/weapon system because all these weapons and classes are stored in enums and i call them directly from their classes...

My current code is probably barely readable but it's simple and easy to understand..

 

Edit: Btw I'm currently opening the server from eclipse debugging so I don't need to recompile and change .jar files to change the value... i just change it from eclipse/save it and boum... the value has change and gets immediate effect... I will think about placing in properties or an xml later..

Edited by xXObanXx
Posted (edited)

I'm sorry boys but I don't get it..

It doesn't need to store all these informations into Maps.

Each player has a different class and weapon.. but I don't get it why I should do all this...

 

Readability, easy code maintenance, easy to edit values (no need to recompile) externalizing configs. Basically said, whatever a developer seek coding.

 

Your code works that's not the problem, but if L2J was coded like your custom... Well it would give L2JFrozen.

 

:happyforever:

Edited by Tryskell

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

    • Update M54: Global HP/MP/CP consumable handling expanded beyond combat-only usage. Offensive mage idle recovery with learned skill Battle Heal. Spellhowler/Storm Screamer prioritizes Hurricane, using Vampiric Claw mostly below 90% HP. Major structural refactor initialized: Added category/class organization such as Archer, Dagger, Tank, Mage, Healer, Support and Specialized class files. Further structural cleanup. Extracted combat memory/state and more class-policy logic from the main controller. Added global stuck/inactivity watchdog for bots blocked by terrain/geodata. Added unreachable dropped ground-item timeout/temporary blacklist. Reworked Necromancer/Soultaker PvP: Dominator level 78+ maintains learned Arcane Power toggle on. Overlord/Dominator level 44+ maintains learned Soul Guard toggle automatically. Stability/scalability update: Bot controller ticks staggered instead of all starting in the same phase: Same 350 ms update rate retained Reduces simultaneous AI workload bursts. Removed the old manual aggressive-monster EVT_AGGRESSION bridge. Phantoms now use native Lucera setActive() behavior so monsters aggro them naturally. Reduced unnecessary NPC scans and native AI event pressure. Added saved-bot equipment overrides using a separate database table:         lucera_autobots_items Existing lucera_autobots remains the main saved-bot identity/state table. Equipment rows are linked to saved bots through bot_id. Added optional convenience view to show bot name together with equipment overrides:         lucera_autobots_items_view Added editable equipment slots in columns: Weapon Shield Helmet Chest Legs Gloves Boots Necklace Left/Right Earrings Left/Right Rings Equipment override values: 0 = use normal class/level profile item -1 = force slot empty >0 = equip that Item ID Custom equipment works only for saved database bots. Default class/level equipment profiles remain unchanged. Supports custom equipment from No Grade to S Grade, regardless of the bot's current level. Added validation for invalid item IDs and incompatible equipment slots. Added handling for: Two-handed weapons vs shields Full-body armor vs separate leggings Added all-grade Soulshots and Spiritshots to bot inventory/replenishment so custom lower-grade weapons still use the correct shots. Mage profiles that already use Blessed Spiritshots keep that behavior with all relevant grades available. First save the bot normally so it exists in table:         lucera_autobots Then open:         lucera_autobots_items Find the row with the same bot_id and edit only the equipment slots you want. Example: weapon_id = 6608 shield_id = -1 helmet_id = 0 chest_id = 0 legs_id = 0 gloves_id = 0 boots_id = 0 This means: weapon_id 6608 → custom weapon shield_id -1 → no shield all 0 values → keep normal default profile equipment After editing the DB, despawn and respawn the saved bot so M54 reloads its equipment overrides. Do not edit bot_id. Use it only to identify which saved bot the equipment row belongs to.   DOWNLOAD
    • It will be multi client so it will detect the client from the files and adapt the packets and asset loading. I am aiming for C4 and H5 after IL
    • this is just to simplify your life, time, and can be done for free by yourself just watch some tutorials, in case you don't wanna waste time check it out!   https://l2getwork.art   https://l2getwork.art/showcase.html  
    • Good job! Any chance for it to be downgradeable or at least compatible with older chronicles?
    • Fermata now runs in a web browser too. Try it here: https://web.fermata.gg/    
  • 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..