Why not talk also about this. We have our nice smith can detect magic/cursed stuff.

Perhaps new players use this, before they know what this means? With identify can do this inclusive, what is the sense of these logics? 

I know another game, where i had no identify spell, but my mages had a detect magic spell. So i could at least filter out, what item is worthy to bring back to town. But with id level against spell level, we can mostly id all item.level capped gear with level 1 id. Also later we have for sure high level id's. So where is the sense of having smith in town, who can detect magic and detect cursed stuff?

Can we make detect magic and detect cursed somehow workable or is this mostly garbage logic we have? 

I we make curse no money gain, than we have next problem. Why we need this in loot? It's mostly garbage then. 

I found this in relation to other games.

A cursed item does not show as magical, unless there is a secondary magical effect (+1 cursed sword). Therefore, neither Detect Magic nor Identify will show that an item is cursed, let alone what that curse is.

The DMG (p. 139) says about cursed items: Most methods of identifying items, including the identify spell, fail to reveal such a curse, although lore might hint at it. A curse should be a surprise to the item's user when the curse's effects are revealed.

Why not make curse something more like this. 

For sure we need lesser cursed drops then. Then identify fails on that items, so identify didn't reveal cursed items. Curse didn't reduce price, because it wants surprise the users?

Sadly we have no curse level, we have only curse flag, so its not possible to have a kind of curse level. So detect/remove curse targeting against spell/item level?

Next is, what is the different of cursed/dammed stuff? Perhaps where curse is a combination of hidden negative traits and non removeable gear, damned could be simple a negation of potion effects?

We can easy go in examine logics and don't reveal negative stats when items are cursed/damned?

But all this ideas become again worthless, if we have to easy reveal mechanics? 

And then we have still perma cursed and perma damned. Also funny that priest in town can remove this too. 

Hm ok so permacurse is "invisible" till you equip this next time. Better would be that remove curse didn't remove the cursed flag and priest/scrolls only helps to remove the item.

Atm we have 1 logic removing curse/damned on perma curse and everywhere in apply spreaded strange logics to put this flag back on? We don't need all this spreaded logics, with one clean logic on remove curse we only need to keep one check in fixplayers. Normally we also don't have to do this in fixplayer. It would be enough to have it one time in loader. Then all our perma cursed stuff would have their red flags back. "That's all".

Yeah sure, if we use damned like a kind of negate potion we can only negate the positive stats. And i don't want to negate a RoA.

If we come to enchantments of items, we could also try curses in this way. Like its a hidden force in the item. We can also go for delayed curses, like you get poisoned randomly or you loose hp, mana, grace.

But you are right, remove curse for some silver and detect curse devices would kill any good idea.

First i would go, that all perma c/d items gets their flags back and that remove curse don't remove c/d flags from perma cursed items, but helps to unapply this gear.

Currently our remove curse is also a mass remove spell. This should be normaly a high tier late game spell for high mages? And early remove curse spells should be limited to one item.

We need also reduce the chances our cursed stuff drops i think.

One problem on our current logic is, that the curse flag(s) and the curse stats are different. The whole item is manipulated in stats. So if we remove the curse flag from items, the items are still "garbage".

This could be more interesting, if the curse is separated from the item, like a force in an item. I must look in, how curse of mass is build in, for sure it overwrites the weight with 65.

Allowed !crystal_mail,!mithril_armour,!mithril_ring,!mithril_coat
chance 80
artifact armour_mass
def_arch chain_mail
editor 2:items/armour/mail
Object
title of mass
type 16
is_magical 1
value 5
cursed_perm 1
cursed 1
weight 65000
end
So it's overwrite the armor with this stats when in generation process.

Back to remove the curse. This means after you cast remove curse you still wear the item and can wear it till you removed it once? That's dirty then. I would go in remove curse logic and would unapply the applyed gear when cursed and then i would leave the curse flag untouched, when it is perma.

I have also seen, that remove curse is remove curse only.
Where remove damnation is removing both (curse and damnation)
and detect curse is also detecting both (curse and damnation)

That's reason remove curse scrolls fail on damnation potion.

So this is all wild and the code behind is like the curse of mass. 65 kg of logics with only one goal, to weight up the server code and processing time. 

If you see what server is doing, when we set or clear a flag, complex math and bit operations each time to store the flag as one bit in a byte chain. This is for sure good to compress data before we want to send it to client. But when we change "one" bit and then each time we send the full flag byte chain to client, this is for sure a troll. And client need to undo this and extract the bit out of the bytechain. We have 135 different flags. That's 17 bytes each time we send to client when we set/clear the curse flag i think.

For sure this logic is great when we want to send all 135 flags at once, but it negates when we only want to send "remove curse flag from item to client". And we do this a lot, changing only one bit and then update the client.

That's reason i am atm a little frustated. Each time i read deeper in code, i have tears in the eyes. Everywhere you read "todo", "need a fix", "this should be rewritten".

So with this big chains of nonsense, it's not easy to optimize code. Good example is also the loader. Normaly you would say. "let's simple say in loader, if perma curse is set, we set also normal curse flag". And the we go in remove curse and remove non perma curse flags and unapply weared gear. That' all. But when you look in loader you see the reasons, why no one want to touch it. So instead they do strange logics in apply and remove all curses(also perma) in remove logics. If you see the logics to remove a curse, you get more tears in the eyes. Instead of iterate the items and remove the curse and unapply the items, they target a "low end" logic, very specialized in handling flags. Very cool logic, but fails when you want to unapply the stuff. So this is also reason for all the mess. They often target existing code, with a massiv functionality in one aspect but a missing functionality in other aspect.

Using such a chain means, priest in town prepare the spell player wants to have. Spell prepare the flags we want to remove, then we interate the objects and then for each object we change the flags.

If we come from lua site i cant count the functions involted in this process anymore. So code is a pain, everywhere. I could do the whole priest remove curse logic in lua with one loop, but because we have also remove spell logics in game, its better to go in there.

But instead building small clean functions for the situations we need, they build everywhere "all in one" logics. Totally overloaded coded with the ability to handle "everything", but handling is limited to a kind of superficial then, where small specialized functions could go deeper.

Have i said functions? We have everywhere macros. So each time we interact with our flags, compiler produces equivalent code to this macros.
#define QUERY_FLAG(_O_, _F_) \
    (((_O_)->flags[(_F_) / 32] & (1U << ((_F_) % 32))) \
     ? 1 : 0)
#define SET_FLAG(_O_, _F_) \
    (((_O_)->flags[(_F_) / 32] |= (1U << ((_F_) % 32))) \
     ? 1 : 1)
#define CLEAR_FLAG(_O_, _F_) \
    (((_O_)->flags[(_F_) / 32] &= ~(1U << ((_F_) % 32))) \
     ? 0 : 0)
#define SET_OR_CLEAR_FLAG(_O_, _F_, _V_) \
    (((_V_)) \
     ? SET_FLAG((_O_), (_F_)) \
     : CLEAR_FLAG((_O_), (_F_)))
So we don't handle our bits in 8bit(byte) storage, we work in 32bit storages.

This is only to say, what server must do, when we "simple" want to handle a cursed flag.

And we have cursed, dammed, perma cursed, perma damned, known cursed, identified, non identifiable, known indentified we must take care, when we use the buildin logics.

For example the core logic ThingDeclare, stops working when we have
if (QUERY_FLAG(what, FLAG_UNIDENTIFIABLE) || QUERY_FLAG(what, FLAG_IDENTIFIED))
{
  return NULL;
}
This means we can't change other flags, when our item is identified or unidentifiable. This function totally refuse to work. This means if an item is unidentifiable, we can't remove curses with our current logics.

Normally we should "kill half the code". We should go for more small specialized functions, instead of this "all in one" ("fail in all") functions.

You see it's frustating to touch the oldest code structures in code. You can't change anything there, without destroying the logics, because these functions are so overloaded.

Perhaps we remove all the curse logics, when we see what the result for players is? Mostly garbage. 

And then we try to build item enchantements, like sharpen/poison/blessed/fire enchanted weapons. This need a "little" rework in object handling, if we want allow a force in a weapon. But from there cursed is only a negative enchantement in our object. And we build our code mainly for player visible and "loved" effects, where curse could be implemented easy as a "small" side effect. 

Why i have touched this?  Ah yeah, because i want to implement items on torch slot. But i really did not planned to read and rework serveral days our curse mechanics.

So far i made the new function working.

Using remove curse is now same than remove damnation. This was only logical step, when detect curse can detect both and remove damnation can remove both. Perhaps we find in future a difference between damned and cursed stuff? Atm it looks like its only the red D and C what make it different. 

New function don't remove curse or damned flags when perma anymore. Instead it unapply this stuff, when it is perma or to high level.

I didn't touched detect magic or detect curse. They come still from old code and fail on non identifiable items. When i see all the sanity checks in old logic i must ask me, what's wrong in this world?  For sure this is very old code. Looks like a lot of these checks are outdated? But they make me unsure, if i missed an important sanity check. So i need some more test and reading here. I updated the above post to new function. Also messages to players could be improved.