ESP: The beginning and the modmerging system [S2G/CP1.6/EE2.1/SS,C]

[Flix 5,116]

On 1/3/2020 at 1:27 PM, Charon117 said:

Here is an example. Lets say you do 1000 true DOT. This gets split over 5 seconds

Ok, I see the confusion here, or some of it.

DOT does not work in Sacred 2 like in say, Titan Quest or other games with DOT is set amount spread over a duration.  In games like that,  increasing the duration would just make it take longer to inflict the same amount of damage.  Decreasing the duration would make it inflict the same payload, only quicker.

In Sacred 2, DOT is scripted more like "damage per second."  It will hit a dictated amount every second, for as long as the duration lasts.  So 4 seconds of 1 damage per second will result in a total of 4 damage inflicted.  If you keep the damage the same and increase the duration parameter to 400 seconds, it would still inflict 1 damage per second, but now the total would be 400 damage because it lasted 100x longer.

As to how DOT -X% applies its resistance, I assumed it was damage reduction only, so it would still hit for the same amount of time, just for less damage on each pulse.  I say this because it's called "DOT Damping" in the scripts.

[Charon117 50]

49 minutes ago, Flix said:

DOT does not work in Sacred 2 like in say, Titan Quest or other games with DOT is set amount spread over a duration.  In games like that,  increasing the duration would just make it take longer to inflict the same amount of damage.  Decreasing the duration would make it inflict the same payload, only quicker.

Damage over Time: Fire -X%: Reduces Burn duration (as well as total damage: for example, if incoming DoT was to inflict 250 damage for 5 seconds it would be decreased by "Damage over time:x -65%" to two seconds - 250 damage dealt by the first pulse and 187 damage a second later, summing up to 437 damage which is 35% of initial 1250).

http://www.sacredwiki.org/index.php/Sacred_2:Damage_over_time:_Fire

 

Insert "There can only be one" meme here.

Edited January 3, 2020 by Charon117

[Flix 5,116]

Ah god, this game.

[Charon117 50]

I need a decision about spawn.txt. Do we want to facilitate dublicated sector pos + layermap_id entries by allowing the modmerge system to deal with such entries, or do we, as the community, want to push single entries only, by forcing a preprocessed merge in one way or another ?

 

Edit: Can I assume that "name" is unique for triggerarea.txt ?

Edit2: Can I assume that "name" is unique for triggervolumes.txt ?

Edited January 6, 2020 by Charon117

[dimitrius154 612]

On 1/6/2020 at 10:25 AM, Charon117 said:

want to push single entries only, by forcing a preprocessed merge in one way or another

I'd say it's preferable.

On 1/6/2020 at 10:25 AM, Charon117 said:

Can I assume that "name" is unique for triggerarea.txt

Yes, though those subentries have no connection with displayed area names. 

On 1/6/2020 at 10:25 AM, Charon117 said:

Can I assume that "name" is unique for triggervolumes.txt ?

Yes.

[Charon117 50]

12 minutes ago, dimitrius154 said:

I'd say it's preferable.

Im surprised by this answer, as I thought it would be more important to preserve the current data format. Can you tell me in what way you want to merge the dublicated entries ?

On 12/31/2019 at 5:38 PM, Charon117 said:

 

Quote

mgr.addSpawn (61,13,0,{ -- Butwald Augen |||     layermap_id = 3,
mgr.addSpawn (11,51,0,{ -- Orc Bear Groupspawn |||     layermap_id = 1,
mgr.addSpawn (58,54,0,{ -- Weihnachtsbaeume |||     layermap_id = 3,
mgr.addSpawn (58,54,0,{ -- Weihnachtsbaeume |||     layermap_id = 2,
mgr.addSpawn (58,55,0,{ -- Weihnachtsbaeume |||     layermap_id = 3,
mgr.addSpawn (58,55,0,{ -- Weihnachtsbaeume |||     layermap_id = 2,
mgr.addSpawn (58,56,0,{ -- Weihnachtsbaeume |||     layermap_id = 3,
mgr.addSpawn (58,56,0,{ -- Weihnachtsbaeume |||     layermap_id = 2,
mgr.addSpawn (59,55,0,{ -- Weihnachtsbaeume |||     layermap_id = 3,
mgr.addSpawn (59,55,0,{ -- Weihnachtsbaeume |||     layermap_id = 2,
mgr.addSpawn (59,56,0,{ -- Weihnachtsbaeume |||     layermap_id = 3,
mgr.addSpawn (59,56,0,{ -- Weihnachtsbaeume |||     layermap_id = 2,

 

Edited January 7, 2020 by Charon117

[dimitrius154 612]

11 minutes ago, Charon117 said:

what way you want to merge the dublicated entries ?

To be considered duplicated, entries have to match the following criteria: 

addSpawn (x,y,z,  - x,y,z sequence is identical

'total_density' value is identical

'layermap_id' value is identical

If match, then compound other non-identical subenties.

 

[Charon117 50]

8 minutes ago, dimitrius154 said:

To be considered duplicated, entries have to match the following criteria: 

addSpawn (x,y,z,  - x,y,z sequence is identical

'total_density' value is identical

'layermap_id' value is identical

If match, then compound other non-identical subenties.

 

There are no such dublicates, dublicates only refer to sector pos + layermap_id data.

[dimitrius154 612]

4 hours ago, Charon117 said:

There are no such dublicates

I'd say there's no merging needed. Varied spawn density is obviously by design.

[Charon117 50]

I am currently having an issue. It is the "What if any file has dublicates ?" problem. While I can write extensive cleanup programs for individual files it doesnt solve the question whether some random base files might have dublicates. This obviously should be avoided by base file authors, but again, doesnt answer the question. Sooooooooooooooooooooooooooo ...

1) I could write a generic cleanup program which checks the base file for dublicates and cleans them up in one fellow swoop. The big downside of this is that such cleanup programs are very expensive in resources, and would take 80% of the the total time to search for dublicates which might not even exist. I mean after you´ve gone once over all your files they definitely dont exist anymore.

2) Solution number 2 would be to outsource such a cleanup program which users would have to use before using the modmergse software. Im very averse to this solution, as relying on the user is generally not a good strategy. Software is there to adapt to humans, not to make humans adapt to software.

3) Number 3 would be to cleanup the community database. But that again would not really answer the question when somebody digs up a dirty file from somewhere else.

4) Dimitrius mentioned that if dublicates exist the last entry takes precedence. If that would be the case for all txt files than the software could simply modifiy the last entry it finds, instead of the first one. This would be a very elegant solution as it would take up zero additional resources, and still reliably produce the proper modmerge effect. So I would ask Dimitrius to look into the Sacred 2 source code and make some reliable checks whether or not somebody without a reasonable doubt could say that the last dublicated entry takes predence over all other ones for at least 99% of files.

[dimitrius154 612]

12 hours ago, Charon117 said:

look into the Sacred 2 source code

Thing is, there's none around. The German colleagues have mentioned, the devs have actually lost their notes at some point I the past. What I do is veritable reverse-engineering of the Assembler code.

12 hours ago, Charon117 said:

if dublicates exist the last entry takes precedence

That's right, txts are read sequentially top -> bottom. Formatting convention is to be observed at all times, as a single misplaced symbol prevents the file from being properly interpreted.

 

12 hours ago, Charon117 said:

make some reliable checks whether or not somebody without a reasonable doubt could say that the last dublicated entry takes predence over all other ones for at least 99% of files

Hmm, dunno why we need all files. Blueprint.txt, surface.txt, behaviour.txt, itemtype.txt, iteminfo.txt, creatures.txt, creatureinfo.txt, drop.txt, spells.txt, animation.txt fit the last entry criterion.

[Charon117 50]

9 hours ago, dimitrius154 said:

Thing is, there's none around. The German colleagues have mentioned, the devs have actually lost their notes at some point I the past. What I do is veritable reverse-engineering of the Assembler code.

Oh. oh. I thought we had .. a little more than that. I get the picture now.

9 hours ago, dimitrius154 said:

Hmm, dunno why we need all files. Blueprint.txt, surface.txt, behaviour.txt, itemtype.txt, iteminfo.txt, creatures.txt, creatureinfo.txt, drop.txt, spells.txt, animation.txt fit the last entry criterion.

Because the software should be 110% of the best quality. If some files differ in their behaviour reverse searching wouldnt cover everything.

 

So the base files will be searched for backwards now, to guarantee modding content to be actual taken by the game, even if the file has dublicated entries. Merging files will still be read from the top, so the last entry will take precedence as well.

Both dublicated entries in base and merge files shouldnt happen, but if they do, we got em covered. The ideal state would be clean files for everybody, but we need a medium to get us there, so the modmerge system will be able to work with clean and dirty files alike. It especially covers situations like:

• An yet unknown file has dublicates, which no special rule has been written for.
• Merging dirty files with dirty files, like upgrading from EE 2.1 to EE2.2. And other situations.

[Charon117 50]

The drop.txt has a single entry that has 2 numbers,

    {"SUBFAM_LIFE_DRAGON",1544,4123},

all other entries have 1 number only. Is that intended ?

[dimitrius154 612]

1 hour ago, Charon117 said:

{"SUBFAM_LIFE_DRAGON",1544,4123},

Interesting. Can anyone confirm, whether an item called "Glaurung's Head" can be looted from dragons and lizards very often?

Edited January 13, 2020 by dimitrius154

[Charon117 50]

20 minutes ago, dimitrius154 said:

Interesting. Can anyone confirm, whether an item called "Glaurung's Head" can be looted from dragons and lizards very often?

[Flix 5,116]

3 hours ago, Charon117 said:

The drop.txt has a single entry that has 2 numbers,

    {"SUBFAM_LIFE_DRAGON",1544,4123},

all other entries have 1 number only. Is that intended ?

I added that.

1 hour ago, dimitrius154 said:

Can anyone confirm, whether an item called "Glaurung's Head" can be looted from dragons and lizards very often?

It shouldn't be very often, since it would have to be a Dryad playing to get the shrunken head to drop at all, and it's a tier 13 item so shouldn't be too common anyway.

[Charon117 50]

Im sorry, I still have to come back to the total_density issue. Does anybody know if how total_density works ? If total density only checks the total number of creatures in sector pos + layermap_id we can make a triple identifier build. But if it counts creatures inserted from previous layermap_ids its a different story.

 

Edit: Can I assume "Pfad" in waypoints to be the unique identifier ? It seems to be except for "Pfad_Wache2_Gabelung", which doesnt contain data.

Edit2: I assume "dbid =" to be the unique identifier for weaponpool.txt. No dublicates exist.

Edit3: weather.txt seems to be written in a similar fashion than spawn.txt. A simply fashion of "spawning" weather. In what kind of way would it be desired to get merged, if at all ?

Edit4: worldobjecthints.txt is empty.

Edit5: "mgr.addWorldObject( NUMBER," seems to be the identifier for worldobjects.txt, but there are a few dublicates:

 

mgr.addWorldObject( 1051307088, {
mgr.addWorldObject( 1011816865, {
mgr.addWorldObject( 1019605033, {
mgr.addWorldObject( 1051305930, {
mgr.addWorldObject( 1051650490, {
mgr.addWorldObject( 1023656262, {
mgr.addWorldObject( 1023656067, {
mgr.addWorldObject( 1023656231, {
mgr.addWorldObject( 1023656067, {
mgr.addWorldObject( 1023656262, {
mgr.addWorldObject( 1023656231, {
mgr.addWorldObject( 1023656231, {
mgr.addWorldObject( 1023656067, {
mgr.addWorldObject( 1023656262, {
mgr.addWorldObject( 1023656067, {
mgr.addWorldObject( 1023656262, {
mgr.addWorldObject( 1023656231, {
mgr.addWorldObject( 1023656262, {
mgr.addWorldObject( 1023656067, {
mgr.addWorldObject( 1023656231, {

@Refresh @Flix @dimitrius154.

Edited January 18, 2020 by Charon117

[dimitrius154 612]

On 1/15/2020 at 11:59 AM, Charon117 said:

seems to be the identifier for worldobjects.txt, but there are a few dublicates

It's not a world-level, but a Loka-ID-level identifier for interactable statics, so unless strings match completely(which would mean two objects of the same type at the same coordinates, a-la matryoshka) they can't be considered duplicates.

Edited January 18, 2020 by dimitrius154

[Charon117 50]

2 hours ago, dimitrius154 said:

It's not a world-level, but a Loka-ID-level identifier for interactable statics, so unless strings match completely(which would mean two objects of the same type at the same coordinates, a-la matryoshka) they can't be considered duplicates.

Which means we are missing a useable identifier. Copy-able only it is.

[Charon117 50]

• books.txt: I assume BOOK_TYPE + NUMBER is the unique identifier.
  Btw I always tried to read that "BOOK_ORCISH_INTRODUCTION" thing, but never could. Does it even exist ?
   
• creatureinfo.txt:   I assume "type         ="  to be the unique identifier
   
• defines.txt is getting used ?
   
• iteminfo.txt: "type           =" is the unique identifier ?
   
• itemtype.txt: "mgr.typeCreate(NUMBER," is the unique identifier ?

 

@Flix @dimitrius154 Thx for the help.

[dimitrius154 612]

41 minutes ago, Charon117 said:

Btw I always tried to read that "BOOK_ORCISH_INTRODUCTION" thing, but never could. Does it even exist ?

It does. Called "Book 3 -Nor Plat" ingame. "Geography of Ancaria" section.

43 minutes ago, Charon117 said:

defines.txt is getting used ?

Yes.

43 minutes ago, Charon117 said:

• iteminfo.txt: "type           =" is the unique identifier ?
   
• itemtype.txt: "mgr.typeCreate(NUMBER," is the unique identifier ?

Correct.

[Flix 5,116]

1 hour ago, Charon117 said:

I assume "dbid =" to be the unique identifier for weaponpool.txt. No dublicates exist.

creatureinfo.txt:   I assume "type         ="  to be the unique identifier

Yes to both.

On 1/15/2020 at 2:59 AM, Charon117 said:

Edit3: weather.txt seems to be written in a similar fashion than spawn.txt. A simply fashion of "spawning" weather. In what kind of way would it be desired to get merged, if at all ?

I've never experimented with it.  I suppose one could use it to add a guaranteed weather effect to a certain sector(s).

[Charon117 50]

Welcome to itemtype.txt, ill just quickly merge 332k lines. Or not. Maybe take a seat until its ready. Coffee ?

264 pre compiler optimised seconds later ...

Still not bad for a file which takes up 30 percent space of all EE text files.

Optimised time is 97 seconds. For 10 mb it could be better, could be worse.

 

• material.txt: "mgr.createMaterial(NUMBER;" is the unique identifier ?
   
• spells.txt: "mgr.defineSpell( "NAME"," and "mgr.addTokenBonus( {"NAME"," are the unique identifiers ?
   
• staticinfo.txt is empty ?
   
• typification.txt: "mgr.createTypification(NUMBER," is the unique identifier ?

 

@Flix @dimitrius154

[Flix 5,116]

Well itemtype.txt is the workhorse of the scripts, responsible for all the items, creatures, structures, and big chunks of landscape.

 

33 minutes ago, Charon117 said:

material.txt: "mgr.createMaterial(NUMBER;" is the unique identifier ?

typification.txt: "mgr.createTypification(NUMBER," is the unique identifier ?

You could use those, or the "id" line, or even the "name" line, since the name is what's referenced in most other files.

33 minutes ago, Charon117 said:

staticinfo.txt is empty ?

Looks like it. Modified date is from 2005, I doubt it ever did anything in Sacred 2.

33 minutes ago, Charon117 said:

spells.txt: "mgr.defineSpell( "NAME"," and "mgr.addTokenBonus( {"NAME"," are the unique identifiers ?

Correct.

The game accepts additional custom Spells.  The game does NOT accept additional Token Bonuses.  Existing ones must be modified. The tokens point to specific bonuses in blueprint.txt.  It's highly recommended to follow convention and always comment in the blueprint bonus name assigned to a token.

[dimitrius154 612]

1 hour ago, Charon117 said:

material.txt: "mgr.createMaterial(NUMBER;" is the unique identifier ?

typification.txt: "mgr.createTypification(NUMBER," is the unique identifier ?

Yes. The "name" subentries are hardcoded. Custom names won't work.

1 hour ago, Charon117 said:

spells.txt: "mgr.defineSpell( "NAME"," and "mgr.addTokenBonus( {"NAME"," are the unique identifiers ?

Yes. The spell names are also hardcoded to the spell tooltip table. Therefore spells with custom names can have no spell, or property tooltips.

Edited January 19, 2020 by dimitrius154