• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

Black Tek Server Pre-Release

Status
Not open for further replies.
Hi,

is there a specific reason why slot attributes are duplicated in items.xml?
XML:
    <item id="2472" article="a" name="magic plate armor">
        <attribute key="weight" value="8500" />
        <attribute key="armor" value="17" />
        <attribute key="slotType" value="body" />
        <attribute key="imbuementslots" value="2" />
        <attribute key="imbuementslots" value="2" />
    </item>

And would it be possible to generate slots lets say with tiers? Example: magic plate armor can have 2-4 slots when looting.
Lua:
    [2472] = {    -- magic plate armor
        min = 2,
        max = 4,
        slots_in_percent_chance = {
            { slots = 2, chance = 50 },
            { slots = 3, chance = 40 },
            { slots = 4, chance = 10 },
        }
    }[
[QUOTE="llouche, post: 2753968, member: 259013"]
Hi,

is there a specific reason why slot attributes are duplicated in items.xml?
[CODE=xml]    <item id="2472" article="a" name="magic plate armor">
        <attribute key="weight" value="8500" />
        <attribute key="armor" value="17" />
        <attribute key="slotType" value="body" />
        <attribute key="imbuementslots" value="2" />
        <attribute key="imbuementslots" value="2" />
    </item>

And would it be possible to generate slots lets say with tiers? Example: magic plate armor can have 2-4 slots when looting.
Lua:
    [2472] = {    -- magic plate armor
        min = 2,
        max = 4,
        slots_in_percent_chance = {
            { slots = 2, chance = 50 },
            { slots = 3, chance = 40 },
            { slots = 4, chance = 10 },
        }
    }
The dublicated attributes in items.xml is my fault. I’ll fix this soon 😊
 
Last edited:
Hi,

is there a specific reason why slot attributes are duplicated in items.xml?
XML:
    <item id="2472" article="a" name="magic plate armor">
        <attribute key="weight" value="8500" />
        <attribute key="armor" value="17" />
        <attribute key="slotType" value="body" />
        <attribute key="imbuementslots" value="2" />
        <attribute key="imbuementslots" value="2" />
    </item>

And would it be possible to generate slots lets say with tiers? Example: magic plate armor can have 2-4 slots when looting.
Lua:
    [2472] = {    -- magic plate armor
        min = 2,
        max = 4,
        slots_in_percent_chance = {
            { slots = 2, chance = 50 },
            { slots = 3, chance = 40 },
            { slots = 4, chance = 10 },
        }
    }

That key being there twice was an accident I assure you. There was a python script ran to add the same amount of slots to items as real tibia has, and that one was probably overlooked as being one that has it already because they were testing it.


As far as making the amount of slots depend on the classification or tier, that is absolutely possible.
Imbuements has a whole lua api available at your disposal that would allow you to make such things.

To add an imbuement slot to an item via lua, you just call "item:addImbuementSlot(#numberOfSlots)" and voila. You can decide what logic determines how many and if it gets imbuement slots. The xml part is a bonus, everything is completely controllable in lua
 
would it be possible to have the option of having the server use runes with charges or using runes that are stackable? in config.lua
 
would it be possible to have the option of having the server use runes with charges or using runes that are stackable? in config.lua
Could you possible elaborate more on your question? Be clear on what it is you want, and how it currently works, and I am sure we can make it possible :D


Btw: I changed the package manager to vcpkg for a few reasons, but mostly to simplify package management on multiple platforms more efficiently! That being said, that garbage known as Cmake is still booted. Black Tek remains using premake for its simplified and powerful features.

Basically, I got rid of the setup_build.py, and any need in python at all. No more needing to install, and configure conan, or conan profiles...

Its as easy as installing and integrating vcpkg (this step can be skipped if you have already done that for another project),
installing and running premake,
enable manifest mode,
compile.

vcpkg and the manifest file will take care of the dependencies as it has done for OTC and TFS.... only we don't need 16 cmake.list files, just one premake5.lua

I will eventually attempt to add a dockerfile and some github actions to handle the building for me.

On another note, recently added Item Events as a new event interface, and am currently working on item.onAttack, item.onHit, item.onBlocked, and their counter parts item.onBlockAttack, item.onDefendAttack, right now! I plan on implementing onDodge, and onMiss eventually as well :D
 
have a question a bit dump you know guys what'sare changes made from 8.6 to 9,x? i upgraded my serv from 7,7 to 8.6 but i kenw what was changed so it were not that ahrd i dont have the same scenario from 8.6 to 9.x can somebody enlighten mee?
 
have a question a bit dump you know guys what'sare changes made from 8.6 to 9,x? i upgraded my serv from 7,7 to 8.6 but i kenw what was changed so it were not that ahrd i dont have the same scenario from 8.6 to 9.x can somebody enlighten mee?
I have never dabbled with protocol changes, sorry
 
how can i set reflection with script using storage or configure it on items?

View attachment 85188
Reflection is there, it appears it just got overlooked when the item descriptions got reworked. My apologies, I will fix the error with the description soon
Post automatically merged:

how can i set reflection with script using storage or configure it on items?

View attachment 85188
I fixed the description, thanks for bringing it to my attention.
1717447426692.png
Post automatically merged:

1717447510147.png
 
Last edited:
Reflection is there, it appears it just got overlooked when the item descriptions got reworked. My apologies, I will fix the error with the description soon
Post automatically merged:


I fixed the description, thanks for bringing it to my attention.
View attachment 85196
Post automatically merged:

View attachment 85197
i updated, but it didn't work
1717469477559.png
 
i updated, but it didn't work
View attachment 85201

It says "reflect all +100%" right there in the picture... are you saying it didn't reflect the damage? If that is what you are saying, did you test all the different kinds of damages, or is it just the damage from the "field" that doesn't reflect?
 
It says "reflect all +100%" right there in the picture... are you saying it didn't reflect the damage? If that is what you are saying, did you test all the different kinds of damages, or is it just the damage from the "field" that doesn't reflect?
sorry, it was not specified, yes the damage does not reflect, I will test the others
Post automatically merged:

It says "reflect all +100%" right there in the picture... are you saying it didn't reflect the damage? If that is what you are saying, did you test all the different kinds of damages, or is it just the damage from the "field" that doesn't reflect?
❗has a bug
reproduce:
Summon a demon when you have the burning condition relog and the server will crash
 
Last edited:
Could you possible elaborate more on your question? Be clear on what it is you want, and how it currently works, and I am sure we can make it possible :D


Btw: I changed the package manager to vcpkg for a few reasons, but mostly to simplify package management on multiple platforms more efficiently! That being said, that garbage known as Cmake is still booted. Black Tek remains using premake for its simplified and powerful features.

Basically, I got rid of the setup_build.py, and any need in python at all. No more needing to install, and configure conan, or conan profiles...

Its as easy as installing and integrating vcpkg (this step can be skipped if you have already done that for another project),
installing and running premake,
enable manifest mode,
compile.

vcpkg and the manifest file will take care of the dependencies as it has done for OTC and TFS.... only we don't need 16 cmake.list files, just one premake5.lua

I will eventually attempt to add a dockerfile and some github actions to handle the building for me.

On another note, recently added Item Events as a new event interface, and am currently working on item.onAttack, item.onHit, item.onBlocked, and their counter parts item.onBlockAttack, item.onDefendAttack, right now! I plan on implementing onDodge, and onMiss eventually as well :D
loving your work bro those new events are lovely
sorry i wasn't clear, i knew it wasn't very clear but was so tired i just pressed enter and fell asleep

So right now the default tfs way to use runes is the 8.6+ version where they are stackable and do not use charges and it's a bit of work to make them non stackable and using charges like they did before 8.6. This is one of those immediate barriers for when someone wants to make an oldschool server using rune charges and achieving it isn't exactly easy for a newbie. I thought it would be a cool feature for black tek to let developers easily choose which system they want to use and if possible would be a very nice config.lua option.
 
sorry, it was not specified, yes the damage does not reflect, I will test the others
Post automatically merged:


❗has a bug
reproduce:
Summon a demon when you have the burning condition relog and the server will crash
Reflect was a system made by nekiro (for TFS) not myself. I will have to take a hard look at it and do some testing to get it all sorted out. I had no idea it had problems, thanks again for reporting them to me. I will get them fixed asap.


loving your work bro those new events are lovely
Thanks. Try not to get to used to them though. After speaking with another programmer, it was brought up as a concern about how many events per combat instance would fire. To reduce the amount of events, but maintain the same functionality, I will be condensing them into two events. item.onAttack, and item.onDefend. It will look like this:


Lua:
item.onAttack(self, player, targetCreature, combatType, block_type)
item.onDefend(self, player, attacker, combatType, block_type, -- possibly 'origin' param as well---)

Most likely. Then, if someone wants to know if it hit or was blocked, ect, they can just compare the block_type to determine that themselves.

This will help to make sure those events don't become a hard bottleneck to easily. Smart programming practice is still expected by the end user (early returns and such).

I'm pleased you like it though!


So right now the default tfs way to use runes is the 8.6+ version where they are stackable and do not use charges
I didn't think that is how it worked, but I guess I haven't actually played on OT in a very long time. I could have sworn there was already a config option for using charges or not. I don't know why this would be something very difficult to achieve. I can definitely add it to my list of things to look into.
 
Reflect was a system made by nekiro (for TFS) not myself. I will have to take a hard look at it and do some testing to get it all sorted out. I had no idea it had problems, thanks again for reporting them to me. I will get them fixed asap.



Thanks. Try not to get to used to them though. After speaking with another programmer, it was brought up as a concern about how many events per combat instance would fire. To reduce the amount of events, but maintain the same functionality, I will be condensing them into two events. item.onAttack, and item.onDefend. It will look like this:


Lua:
item.onAttack(self, player, targetCreature, combatType, block_type)
item.onDefend(self, player, attacker, combatType, block_type, -- possibly 'origin' param as well---)

Most likely. Then, if someone wants to know if it hit or was blocked, ect, they can just compare the block_type to determine that themselves.

This will help to make sure those events don't become a hard bottleneck to easily. Smart programming practice is still expected by the end user (early returns and such).

I'm pleased you like it though!



I didn't think that is how it worked, but I guess I haven't actually played on OT in a very long time. I could have sworn there was already a config option for using charges or not. I don't know why this would be something very difficult to achieve. I can definitely add it to my list of things to look into.
1717477164152.png

1717477211458.png
i changed this and it seems to work
C++:
if (attacker != nullptr) {
    Player* attackerPlayer = attacker->getPlayer();
    if (attackerPlayer != nullptr) {
        for (int32_t slot = CONST_SLOT_FIRST; slot <= CONST_SLOT_LAST; ++slot) {
            Item* item = attackerPlayer->getInventoryItem(static_cast<slots_t>(slot));
            if (item != nullptr && item->getAttack() > 0) {
                g_events->eventItemOnAttack(item, attackerPlayer, this, combatType);
                if (blockType == BLOCK_NONE) {
                    g_events->eventItemOnHit(item, attackerPlayer, this, combatType);
                } else if (blockType == BLOCK_DEFENSE || blockType == BLOCK_ARMOR) {
                    g_events->eventItemOnBlocked(item, attackerPlayer, this, combatType);
                }
            }
        }
    }
}
 
Last edited:
View attachment 85202

View attachment 85203
i changed this and it seems to work
C++:
if (attacker != nullptr) {
    Player* attackerPlayer = attacker->getPlayer();
    if (attackerPlayer != nullptr) {
        for (int32_t slot = CONST_SLOT_FIRST; slot <= CONST_SLOT_LAST; ++slot) {
            Item* item = attackerPlayer->getInventoryItem(static_cast<slots_t>(slot));
            if (item != nullptr && item->getAttack() > 0) {
                g_events->eventItemOnAttack(item, attackerPlayer, this, combatType);
                if (blockType == BLOCK_NONE) {
                    g_events->eventItemOnHit(item, attackerPlayer, this, combatType);
                } else if (blockType == BLOCK_DEFENSE || blockType == BLOCK_ARMOR) {
                    g_events->eventItemOnBlocked(item, attackerPlayer, this, combatType);
                }
            }
        }
    }
}
Very nice that you found it! Adding the check for an attacker first was my fault. I overlooked it.

Btw

C++:
if (attacker) {

is the same as

C++:
if (attacker != nullptr) {

So yeah, the additional check should fix the problem, thank you very much! I will update the main branch with the fix.
Post automatically merged:

Was the reflect working now though, or is that still a problem too?
 
Status
Not open for further replies.
Back
Top