Better Version Control for Protections Files

[0zlw]

MyTown needs a better way of managing different versions of mod in protection files. Individual items should be controllable imo. Additionally should allow >, <, = for versioning.

[MuresanSergiu]

At it's core it's a good idea, but I think this will clog most of the protection files to the point where you will not be able to understand what's what in there. I want the protection files to be kept as clean as possible honestly.

Better versioning check for the files themselves is a good idea, and partially implemented this way:

• If you have three versions of a mod: "1.0.1", "1.0.2" and "1.1" and you have a protection file that works with the first two but not the last one you can simply have the version string be "1.0" since the system performs a "start's with" operation the version strings.

What we could do instead is simply modify the structure of the files in the GitHub repository like this:

• each mod will have its own folder with all the files for the different versions
• each of the versions HAVE to be exclusive to one another, so they don't intersect at any point

This will allow people to simply download the whole repository and be good to go. We could even have all protection files from ALL versions of Minecraft in there (unless the structure of the file doesn't change of course) Sure, the repository will be pretty big, but I think it should be fine since it's txt files.

[0zlw]

At it's core it's a good idea, but I think this will clog most of the protection files to the point where you will not be able to understand what's what in there. I want the protection files to be kept as clean as possible honestly.

IMO, this idea is cleaner than what you are proposing. It's much simpler to be managing one file per modification, then 10 files per modification. Not every item would need an additional line, only newly introduced items etc.

If you have three versions of a mod: "1.0.1", "1.0.2" and "1.1" and you have a protection file that works with the first two but not the last one you can simply have the version string be "1.0" since the system performs a "start's with" operation the version strings.

When I say better version control, I mean an improvement over this current system. This is not practical and requires a significant amount of work to maintain, i.e. this requires someone to monitor what version of each and every mod they are using is. If your mod goes from version 1.0 to 1.1, you may not even notice that this has happened, especially in a modpack like Infinity. There are simply far too many mods to remember and identify what versions there are. The options need to be starts with, greater than or less than, anything else is not a long term viable solution for people to maintain protection files with without a significant amount of work.

What we could do instead is simply modify the structure of the files in the GitHub repository like this:

each mod will have its own folder with all the files for the different versions each of the versions HAVE to be exclusive to one another, so they don't intersect at any point This will allow people to simply download the whole repository and be good to go. We could even have all protection files from ALL versions of Minecraft in there (unless the structure of the file doesn't change of course) Sure, the repository will be pretty big, but I think it should be fine since it's txt files.

This is a significant increase in work to maintain for very little gain. It is much simpler, cleaner and substantially less work to allow individual items to be controlled as and when needed instead of files for all the different versions. It still remains drag and drop with my suggested way, with substantially less files.

We run 8+ different types of ModPack on our server. My current process when I need to update protections is that I make the changes to a central file, which is then pushed out to the servers. I then have to take our a class from Gendustry on Dw20 only, and from Lycanites mobs on Banished. Having individual item version control would allow this to be completely drag and drop as well.

---

Let me walk you through a case example. We currently run the Banished modpack. The default file from the MyTown repository we get contains an item called Lycanite mobs that was stopping the protection file from being loaded (fixed now, thanks @krwminer). I assume that the summoning pedestal was introduced in a version later than whatever we are running. Under my system, to fix this issue you would simply work out what version was the summoning pedestal added and add that to this specific item. Under your system you would make an entirely different file for this.

Then, we need to think about what happens when the mod creator adds another block in. Under my system, you would simply add it into the current file with the relevant version parameters. Under your system you would need at a minimum, of 3 files for versioning. Potentially this could be many many more dependent on how strictly mod developers follow intelligent version numbering guidelines. The long and short of it is, I think that they way I'm suggesting is a reasonably elegant solution to what is an issue.

[0zlw]

Example

{
  "modid": "lycanitesmobs",
  "segments": [
    {
      "class": "lycanite.lycanitesmobs.api.entity.EntityCreatureBase",
      "type": "entity",
      "actions": "TRACKED",
      "flags": "MOBS",
      "condition": "isHostile == true",
      "isHostile": [
        {
          "element": "isHostile",
          "type": "METHOD"
        }
      ]
    },
    {
      "class": "lycanite.lycanitesmobs.api.IGroupAnimal",
      "type": "entity",
      "actions": "PROTECT",
      "flags": "PVE"
    },
    {
      "class": "lycanite.lycanitesmobs.api.entity.EntityProjectileBase",
      "type": "entity",
      "actions": "TRACKED",
      "flags": "PVP",
      "owner": [
        {
          "element": "field_70235_a",
          "type": "FIELD"
        }
      ],
      "range": 15
    },
    {
      "class": "lycanite.lycanitesmobs.api.block.BlockSummoningPedestal",
      "type": "block",
      "actions": "RIGHT_CLICK",
      "meta": -1,
      "flags": "ACCESS",
      "version": ">1.13"
    },
    {
      "class": "lycanite.lycanitesmobs.api.item.ItemCustomSpawnEgg",
      "type": "item",
      "actions": [ "RIGHT_CLICK_BLOCK", "RIGHT_CLICK_ENTITY" ],
      "isAdjacent": true,
      "flags": "USAGE"
    },
    {
      "class": "lycanite.lycanitesmobs.api.item.ItemSoulkey",
      "type": "item",
      "actions": "RIGHT_CLICK_BLOCK",
      "isAdjacent": true,
      "flags": "MODIFY",
      "range": 100
    }
  ]
}

Example of how this method could work in practice. (Not completely sure which version it is)

[MuresanSergiu]

I understand now where you're coming from.

The problem with your system is that, if, a mod completely changes its internal code (ex: BuildCraft) we will have a ton of duplicate segments in the same file which we'll have to have it there for the rest of our lives (for backwards compatibility), and every time you make a modification to said file you will encounter all those segments clogging your view.

So, here's a solution: we should have both per file AND per segment version checks. This way if there's a mod that changes everything we can simply move the old stuff to another file and call it a day. Since the code is completely different there's hardly any chance that from there on we will have to add same segments to both files.

I think that may be what you were suggesting earlier, I just misread -.-'

[0zlw]

Cool, I now understand where your coming from as well. Yeah I think your method has a place as well, i.e for dealing with the different versions of chisel.

[0zlw]

Just re reading over everything, I think we had different case examples in mind, I was thinking about new items and additions, and you were thinking about code changes and rewrites. Anyway, I think a combination of both methods will be an effective way of dealing with the issue.