Jump to content

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


Recommended Posts

I think what would be useful for me is to sort all entries in itemtype.txt by the unique identifier: mgr.typeCreate(5741, newItemType); That way it would be easier to see which itemtype ID's are unused.

The thing is we came up against an upper ceiling on itemtypes (above 14000 the items wouldn't drop) so we had to start counting backwards from there and we almost filled up everything between 13200 (beginning of CM Patch items) and 14000.

Link to comment
1 hour ago, Flix said:

I think what would be useful for me is to sort all entries in itemtype.txt by the unique identifier: mgr.typeCreate(5741, newItemType); That way it would be easier to see which itemtype ID's are unused.

The thing is we came up against an upper ceiling on itemtypes (above 14000 the items wouldn't drop) so we had to start counting backwards from there and we almost filled up everything between 13200 (beginning of CM Patch items) and 14000.

I assume this is dimitrius request ?

 

So you would need a sorted itemtype.txt ? I looked at the EE one and it is pretty sorted already. Is the upcoming Addendum one not sorted like that ? But you would like the convenience that if entries jump that the jumped ones are unused ? Or would you simply like to have a list of unused numbers ? Or both ?

Link to comment
5 hours ago, Charon117 said:

Please exactly specify the software requirements and what the software should do.

The expected function is to:

1. Open the itemtype.txt file

2. Detect all instances of  "if mgr.typeCreate(***, newItemType),"(where *** is a numerical ID) 

3. Analyze, whether there are missing IDs( if the ID(n+1) - ID(n) = z, z > 1, there's z - 1 missing IDs between ID(n+1) and ID(n) )

4. Form a list of all missing ID in a separate txt file.

Edited by dimitrius154
Link to comment
1 hour ago, Flix said:

do you think you could kindly avoid adding in the 13200-14000 range?

It seems I haven't added anything within the interval so far, so taht shouldn't be a problem. I have enough obsolete_dummy's so far.

Edited by dimitrius154
  • Thanks! 1
Link to comment

@Charon117 How hard would it be to make a tool that could add the intensity values together for duplicate creature bonuses?  Here's an example:

mgr.addCreatureBonus( 70, {    bonus = 20,     intensity = 550,     })
mgr.addCreatureBonus( 70, {    bonus = 20,     intensity = 900,    })

Above are two strength bonuses (id=20) applied to creature 70.  The desired result is to have the two lines combined to make a single entry with the intensity values summed, like so:

mgr.addCreatureBonus( 70, {    bonus = 20,     intensity = 1450,    })

It's not worth the effort to do it manually since the game sums them together anyway, but if the process could be automated it would be useful for reducing clutter and more easily working with the values.

Link to comment

Hey man, thanks for the tool.  There are a couple oddities with the latest iteration. It seems to duplicate the closing bracket and parentheses for every bonus, either directly after the original, or else after the comment (also duplicates the comment), like so:

mgr.addCreatureBonus( 2505, {    bonus = 398,     bonus = 398,     intensity = 3500,      intensity = 3500,     })})

or

mgr.addCreatureBonus( 2506, {    bonus = 723,     bonus = 723,     intensity = 800,     intensity = 800,    }) -- Armor Ice}) -- Armor Ice

I could take care of the former with a quick find/replace, but not so much the latter.

Link to comment
12 hours ago, Flix said:

Hey man, thanks for the tool.  There are a couple oddities with the latest iteration. It seems to duplicate the closing bracket and parentheses for every bonus, either directly after the original, or else after the comment (also duplicates the comment), like so:

mgr.addCreatureBonus( 2505, {    bonus = 398,     bonus = 398,     intensity = 3500,      intensity = 3500,     })})

or

mgr.addCreatureBonus( 2506, {    bonus = 723,     bonus = 723,     intensity = 800,     intensity = 800,    }) -- Armor Ice}) -- Armor Ice

I could take care of the former with a quick find/replace, but not so much the latter.

1. I assume this is DF2 material
2. Post the file you are trying to merge.
3. What options are you applying to the file ? eg. 123 ?

 

@Flix @dimitrius154 Can I ask you both to go into your drop.txt, and change

local shrinkheadDropMap = 
{    {"SUBFAM_LIFE_ANIMAL",1535},

to

local shrinkheadDropMap = {
    {"SUBFAM_LIFE_ANIMAL",1535},

Thank you.

Edited by Charon117
Link to comment
3 hours ago, Charon117 said:

@Flix You are experiencing a software limitation. Option 1 is only there to switch from {intensity,bonus} to {bonus,intensity} but not back again.

In case this was a request, here you go: Sacred 2 Defrag creatures.zip

Gah, of course, there was no need to choose option 1 because it had already been performed on that file. I guess I thought it might reverse it.

Link to comment

Since I know you're working your way through the server folder, there's another such section in quest.txt for reserving space for certain types of quests:

quest.reserveQuestType {
Killquest = 748,
Rescuequest = 117,
Reachingquest = 1257,
Collectquest = 372,
Convoyquest = 0,
}

The numbers must match the quantity of each quest type. For reference:

Killquest is questtype = 1,
Rescuequest is questtype = 2,
Reachingquest is questtype = 3,
Collectquest is questtype = 4,
Convoyquest isn't used.

  • Appreciation 1
Link to comment
4 hours ago, Charon117 said:

what pathObjects.txt actually does, and in what way somebody might want to mod it ?

Local AI path-building file, if I recall correctly. SHould not be modded, at least not until there's a world editor around.

  • Appreciation 1
Link to comment
13 hours ago, dimitrius154 said:

Local AI path-building file, if I recall correctly. SHould not be modded, at least not until there's a world editor around.

Copyable-only it is then.

 

So, quest.txt. Anything more I need to know about this file ?

reserveQuestType has been explained to me.
I assume I can ignore mgr.addWorldObject ?
quest.reserveQuestType seems to be its own code block. Anything else somebody might want to mod in there ?
quest.createTaskCreature(, quest.createTaskItem( and quest.createQuest( looks like a straightforward replace
I assume I can ignore the function calls in the beginning ?

Link to comment
9 minutes ago, Charon117 said:

So, quest.txt. Anything more I need to know about this file ?

Should not be touched with a ten-feet pole. It's being processed bottom-top upon every game reload. Not-so-weird things happen, if you change anything within that file, then load a legacy character.

Other files mentioned should be left as is, IMHO.

Edited by dimitrius154
Link to comment
5 minutes ago, dimitrius154 said:

Should not be touched with a ten-feet pole. It's being processed bottom-top upon every game reload. Not-so-weird things happen, if you change anything within that file, then load a legacy character.

Is that you professional Sacred 2 modder oppinion ? As far as I understand it you can add quests, the appropriate items and creatures correspondind with it, and then recount quest types.

I do use quest.txt as a simple way to spawn creatures wherever I want, revive story bosses and other mods do other stuff. What should keep us from doing that automatically ?

 

8 minutes ago, dimitrius154 said:

Other files mentioned should be left as is, IMHO.

Other files as in other files than the quest.txt ? Or other files as in other functions inside of quest.txt ?

Link to comment

 

1 hour ago, dimitrius154 said:

Should not be touched with a ten-feet pole.

Oh come now, we both have to go into that file to fix things sometimes, at the very least.

I take your point about legacy characters though. A fantastic way to break all manner of things is by loading an old character into an altered quest.txt, or into any altered file in the server folder for that matter.

I edit quest.txt liberally in Diablo 2 Fallen.  The Community Patch itself not only edited it quite a bit but also reformatted it. Same goes for questscripts.txt.  In fact that was the original goal of the CM Patch, pretty much just quest fixing, and if you want to do that, you gotta touch quest.txt and questscripts.txt.

1 hour ago, Charon117 said:

I assume I can ignore mgr.addWorldObject ?

I've experimented with adding world objects in that block, with no results. I don't think anyone would edit it.

1 hour ago, Charon117 said:

quest.reserveQuestType seems to be its own code block. Anything else somebody might want to mod in there ?

I can't think of anything, aside from updating the quantities of each quest type.

1 hour ago, Charon117 said:

quest.createTaskCreature(, quest.createTaskItem( and quest.createQuest( looks like a straightforward replace

Should be, yes. But it's hard to imagine merging two mods successfully that altered the same entries, as there's so many variables.  If one mod simply added some entries, sure.

1 hour ago, Charon117 said:

I assume I can ignore the function calls in the beginning ?

That's out of my depth, I don't think they've ever been tampered with.

Link to comment
54 minutes ago, Flix said:

But it's hard to imagine merging two mods successfully that altered the same entries, as there's so many variables.  If one mod simply added some entries, sure.

I dont see the difficulties. I assume all relevant information is present in quest.createQuest(. If you assume base A and merge B, than all relevant information has to be in merge B. The worst that can happen is that you (1) deactivate a quest of base A (2) change a necessary item or creature into something else.

But that fundamental problem is present for all merge systems, that is that you cant prevent unwanted overwritten IDs, because no system can differentiate between human intention. Or to put it in plain words: no software can prevent merging conflicts between 2 mods.

    (1) It is up to the mod author to prevent conflicting data on the suspected lower base
    (2) The only "real" solution would be an open database of which identifier for which file havent been taken, in order to avoid unwanted overwritten ID. Much in the same way you negotiate conflict avoidance about itemtype.txt with dimitrius.
         But apart from that there is no software solution to keep one mod inadvertedly from disabling another.
    (Final) Like I already said, the best solution is that the mod author checks if all used IDs are compatible with popular and known content. 

This is less of a problem than you may think:

  • It doesnt concern EE or Addendum, as they are base applications right after the CP.
  • This is a problem which every game has, not only Sacred 2. The result is that people usually avoid having mods which alter the same aspect. So only 1 full conversion mod, 1 weapon mod, 1 quest mod, etc ... . Mod authors usually adapt to this by looking sideways and giving information about which mod is likely to conflict with their own, and which isnt.
  • A partial solution is to specifiy which modmerge build a mod is built to work conflict free on. Like [CP1.6|EE2.2||SomebodiesSuperDuperWeaponMod0.5].

 

I mean ... if we think about a possible solution.

A possible solution for avoiding unwanted merging data is to add authors intention with it. Like [Add] or [Overwrite]. If an ID has an [Add] tag, but realises base A already has this ID, it can reroll another, unused ID. Then it has to apply said rerolled ID to all relevant data, even other files. Which requires all files with linked IDs to be open at the same time. If [Overwrite] is specified it either overwrites the entry, or adds it if non-existent. All of that would require big data management, which is a lot bigger than the Sacred 2 modding community, potentially even bigger than the combined modding community for all games. Things at that level usually become commercial, and then things get complicated. And we dont even have a merging system for Sacred 2 yet. Dream big, but make one step at a time.

 

Edit: A possible medium solution would be to add tags to mods, and the software asking for confirmation if mods with the same tags are about to get merged. But that would be after we have a functional mergings system, and is depending whether or not the modmerging system even takes off for the Sacred 2 community.

An example would for EE, Addendum and CP would be [FullConversion].
Smaller mods could have txt files as tags like [quest.txt, itemtype.txt] etc ... .

Edited by Charon117
Link to comment
  • The title was changed to ESP: The beginning and the modmerging system [S2G/CP1.6/EE2.1/SS,C]

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...
Please Sign In or Sign Up