Author Topic: item definitions (Read 214 times)

Dolfo

We have a pain on different ways to define items. Some leading to items deriving from one definition. Other leading to a ton of unique generated versions in playerstock.

We should try to clean this out somehow.

First the cleanest definition is to use the arch name. We have this on lich gauntlets.
They are easy implemented in map with only one line.

Code: [Select]

arch gauntlet_lich

If we change stats in there, it goes on new drops AND old items in player stock.

Second is using "amask". We have this for example on shield_demonic. Its implemented in map this way.

Code: [Select]

arch shield_skull
amask shield_demonic

Normally this should also work clean, we could change the shield_skull or the shield_demonic, BUT
when generate that item. amask is overwriting the base definition of skull shield and forgetting the arch name shield_demonic where it comes from. If we change shield_demonic definitions, we no more touch player base items. We produce more and more different versions of an item.

Instead of overwriting the stats, we could save the amask name somehow in object name. For sure logic around saving would be a pain, to sort out what changes come from skull and what changes come from demoic definitions and this goes more complex, if we use +x or %x changes.

An idea between could be this rule:
"When we have an amask name, don't allow save unique stats change" "Save only base arch and amask arch" . But thats not easy on changes like condition/quality/material.

So when saving we need a kind of build base item WITH amask and compare.
Everything what is different from amask we save. But that would lead to a problem when we try to load an item. We need load first the base arch, then amask it, then overwrite the unique changes like condition, quality, material, additionally buffs.

And thats only our problems using amask, we have more when we build artifacts dynamically.

Also we can easy replace above demonic shield definition in map with

Code: [Select]

arch shield_demonic

shield demonic has "def_arch shield_skull" and derives from there.
Edit: or not somehow arch shield_demonic is not reachable, where arch gauntlet_lich is, coming both from same list.

Dolfo

Why we can use
/generate gauntlet_lich
but not
/generate shield_demonic

They coming both from demon_plane.art.

Edit: Great serveral hours to find out ...

--- its in relation to "editor 2:" comando

Code: [Select]

...
else if (!strncmp(cp, "editor", 6))
{
 if(!strncmp(cp+7,"2:",2)) /* mask only */
  /* Do nothing */;
 else if (!strcmp(cp + 7, "0") || !strncmp(cp + 7, "1:", 2) || !strncmp(cp + 7, "3:", 2)) /* use def arch def_at */
 {
  if (!art)
  {
   LOG(llevError, "\nERROR: Premature editor line in artifact file: %s\n", cp);
   return;
  }
  art->flags |= ARTIFACT_FLAG_HAS_DEF_ARCH;
 }
 else
 {
  LOG(llevError, "\nERROR: Invalid editor line in artifact file: %s\n", cp);
 }
...

Cleaning the arch definition on shield_demonic and changing "editor 2:..." to "editor3:..." will create a clean artifact named shield_demonic we can target with /generate command and we can add in maps with one line.

Next is to test the behaviour of the "amask" command, when we we have "editor 3..."

Edit: Using amask produces also with "editor 3:..." an arch "shield_skull" and manipulate the data, forgetting that it is a "shield_demonic".

We should define, if we want the artifacts on camps as mask (editor:2) or as arches (editor:1) or as both (editor:3).

I think we should clean the artifact lists to use "editor 3..." whereever this is working and change camps to a clean "arch name" definition.

Dolfo

Ok

Using 1 we add items more like a kind connected to database, where all players have same items.
If we change data later, we change also player stock.

Using 2 we build unique, where players get items separated in their data. Atm we use this in situations, where we build dynamically, like +x pow gear. If we change data later, we change not the player stock.

Using 3 is allowing both, this leads to situations, where I can camp Ring of Healer connected to "arch ring_healer" and can find a ring build generic "ring_generic" changed to stats of healer ring.
Balancing ring of healer stats later, would touch playerbase for the non generic and would not touch playerbase for the generic version.

Also we need to define: do we want camped gear should be updated on balance changes in playerstock or not?

Dolfo

Connection to "database logic" on camps will lead to unified player stock data, but would lead also to situations, where we touch all player stock with one change.

We had this for example on lich gaunts (editor:3). We changed all player stock. This leads to situatiions where players instantly have this new item. Players with 10 or more lich gaunts in their stock ... We know what this means.

From this view, I would prefer to generate these items unique. So if we rebalance items, we don't break instantly the item market.

We have also more masked items, than fake arches on camps. BUT we can't change lich definitions to only mask for example. This would wipe out players lich gaunts. In this situations, we can only change to mask AND fake (editor 3:). Then we can change newer lich gaunts drops to unique.

When we think from the other side for one drop quest items, perhaps we better go here to fake items. If not, each time we change these items, players need a reset for their quests to get the new versions.

At some point we need to find solutions to clean out old outdated items. Perhaps give players the option to upgrade/trade to newer versions?

So that's the problems we have. In some situation a connection to a database would be better, in other situations, keeping the items unique, would be better.

Author Topic: item definitions (Read 214 times)

Dolfo

item definitions

Dolfo

Re: item definitions

Dolfo

Re: item definitions

Dolfo

Re: item definitions

Related Topics