To browser these website, it's necessary to store cookies on your computer.
The cookies contain no personal information, they are required for program control.
  the storage of cookies while browsing this website, on Login and Register.

Author Topic:  amask artifacts  (Read 1977 times)

0 Members and 1 Guest are viewing this topic.


« on: 08, July 2020, 15:23:59 »
When loading an object from a map the line 'amask foo' means the object
(which is a (potentially already modified) clone of some arch) will be
artificated (basically as a last step) with amask.

There are several probliems:

1) amask is applied with no checks it is allowed. So currently:

Code: [Select]
if (amask)
    give_artifact_abilities(op, amask);

Fix with:

Code: [Select]
if (amask)
    if (legal_artifact_combination(op, amask) == 0)
        LOG(llevMapbug, "MAPBUG:: blabla!\n");
        give_artifact_abilities(op, amask);

2) This has been an issue since forever. Once artificated there is no way to
undo it, or even recognise that it has been done.

At a basic level say we have an arrow arch with dam 555. Many players get
these. Eventually they're deemed too powerful. Easy, change arch to dam 5. All
objects follow suit.

But amask totally breaks this. There is no way to nerf indiv objects.

3) Related, comments in the artifacts file talk about the poss to disenchant.
How? Even if we knew which amask to undo, I see no way to actually do this.

A partial solution is add:

Code: [Select]
struct object_t
    artifact_t *amask;

Then record op->amask on loaD and on save just save arch and amask when there
is op->amask.

BUT wer'e limited to <=1 amask per object (which prob was intentional anyway)
and any subsequent mods (eg, by scripts) are lost on save.

A better solution is _people_s buff system.

What am I not seeing?


« Reply #1 on: 08, July 2020, 16:07:55 »
Based on my interpretation of this thread, it looks like the intention was always to be able to disenchant artifacts (including special drops such as Excalibur). However, as far as I remember from the code there's no mechanism by which to do this. And I don't think it was designed with such a mechanism being reasonably achievable (as you point out).

While the artifact system doesn't seem to be fully fleshed out, it does have some advantages (t_style, Allowed, chance, difficulty). Perhaps the ideal solution would be to combine both the buff system and the existing arch system? So the object definition in the artifacts file would be essentially a buff_force definition and the stats get applied by the same code as a normal buff.

I still don't see any advantage to the editor x:/path/to/arch thing either.
-- _people_ :)


« Reply #2 on: 08, July 2020, 19:11:39 »
Forgot aabout that thread. My Michtoenglisch is rusty. Need lots of time and lots of coffee.


« Reply #3 on: 08, July 2020, 20:32:09 »
Well if my understanding is correct basically suggestions are as follows:

1. Make a buffed artifact be a copy of the original and then buff it. This means any changes to the original don't affect the buffed version
2. Make it so that artifact points to a reference to the original and then apply the buff. This means that any changes to the original also impact the buffed version.

This issue applies to all artifacts. For example when Joe changed the Killrin Priest Set all the old sets had the old stats. From a player perspective there is also the problem that if stats are changed without player's knowledge it can give problems if a vital stat is removed or changed. For example if a warrior used a couple of Killrin Priest Set items and stats were changed to mirror new stats they'd have WC-100 that means they can't hit anything anymore.

Being realistic I think best solution is the second as it does allow for any broken items to be fixed retroactively but it does have the caveat that changing arches should be avoided unless absolutely essential

As far as being limited to 1 amask per object is it not possible to just overwrite the old amask. Let's say we want to add HP+10 then code is something like amask = amask + HP10 where if there is no previous amask then amask = 0
Doesn't matter, you'd die anyway. ;D Shroud's a hacker. After many hours of deep thought I have came to that conclusion.


« Reply #4 on: 09, July 2020, 11:28:59 »
As masks implicitly used from tls and as fake arches, artifacts are useful, IIUC 'disenchanting' is only intended to be possible fpr fake arches (not convinced it is practical, I'll think on it).

But the explicit amask command from maps (and Lua's CreateArtifact) seem... inadequate.

to atart with, the legality check I suggested above is intentionally omitted:

) Explicit by the object command "amask <artifact name>". When an object is loaded, the
map/object loader will parse the artifact map over the object. chance, difficulty and all
between Allowed and Object is IGNORED. The mask is used even map level is to low or something.

Ignoring chance, diff is fine but it'd unquestioningly allowed to,eg, amask weapon_fools on, IDK, a teapot? This can't be right. At some point if you allow cross-type artifaction you'll end up with broken real objects in player invs which cause server crashes. (Some, not all) players refuse to destroy such items. This is exactly why we ended up having to have a total player wipe 13 years ago after DMs got excited over abusing /create.

Still reading, but I'm lening towards saying use buff system for map/script objects (which also allows for fine(ish) control of disenchantment) and keep mask artifaction for tls/randomitems drops.


« Reply #5 on: 09, July 2020, 23:44:05 »
Just one question but I'll note that when looking at potential to change items it was said that if item is linked directly to the arch then you can change the arch to change the item. However with the amask it currently doesn't seem to be the case so would same problem potentially arise that if someone has a broken amask there is no way to change it in same way as arch.

In that case would it make sense to have predefined amasks with potential to combine a certain maximum amount. For example items can have minor/lesser/small/medium for +1/+2/+3/+4 of stat. It might end up with close to 100 or so if you assume 7 stats x 4 boosts, along with wc/dam/ac/resists etc and hp/mana/grace (along with regens) along with potentially attunements/attacks+%, reflects etc.

Advantage of that approach is let's say you can get a +10% paralysis amask and then players can get 10 of them and paralyse mobs 100% of the time then you can say that paralysis amask is overpowered, lower it to 5% and then it only paralyses 50% of the time.
Doesn't matter, you'd die anyway. ;D Shroud's a hacker. After many hours of deep thought I have came to that conclusion.


« Reply #6 on: 10, July 2020, 10:19:28 »
... if someone has a broken amask there is no way to change it in same way as arch.

That's exactly (part of) the problem.

The rest of your post sounds a bit like a major feature I have (nearly done, but it relies on A B C ... which I'm doing now). But I'm not sure that can solve this.


« Reply #7 on: 10, July 2020, 20:54:02 »
I've thought of a potential bug that could arise. It was mentioned that we could get amask weapon_fools on a teapot. Having said that if a weapon arch was changed into a teapot would all the amasks that were originally considered legal on a weapon now end up applied on a teapot?

While I doubt anyone would deliberately do that if an item's function changes it could have a knock on effect. The other thing to consider is items that change state with classic example being a torch and a burnt out torch where in that case arch naturally changes but what happens to the amask is unclear.
Doesn't matter, you'd die anyway. ;D Shroud's a hacker. After many hours of deep thought I have came to that conclusion.


Related Topics

  Subject / Started by Replies Last post

Started by smacky Scripts

6 Replies
Last post 28, February 2007, 00:18:12
by smacky
37 Replies
Last post 16, January 2021, 13:24:36
by smacky

Started by myths Spoilers

3 Replies
Last post 22, November 2010, 16:24:18
by zrubavel

Started by Joe « 1 2 » Arches

17 Replies
Last post 06, September 2014, 21:30:58
by _people_