Reverse Engineering txt files

Users who are viewing this thread

Genveir

Recruit
Hello everyone,

I was just wondering why I haven't seen a tool to reverse engineer the txt files into python scripts for the module system on here. I have one that's about half done (I just grab module_scripts, module_simple_triggers, module_triggers and module_parties plus all the ID files at the moment.) Is there some sort of taboo? Or did no one get around to making one?

I just figured I'd ask before I get a full application, put it online like "look what I made :grin:" and instantly get stoned for heresy...
 
as Sir Henry said, if a mod author wants their source to be available then they release it, if they don't then they don't make it public. 

However, I can also comment on this further since I wrote the troop editor.  Personally, I found just trying to translate the single troops.txt file fairly difficult, some stuff was easy, but trying to figure out all the various flags and other stuff was a pain and some of it I never figured out.  Then, combine the fact that people can add new stuff to the headers, create their own variables, nest code blocks inside of code blocks, etc, I think you are underestimating how difficult this would be.  The text files also don't contain the comments so those would be missing as well unless you used comments from the native game.  I'm not saying this isn't possible, and you might be able to get it to work with a few files or an un-modified native game, but I personally think a full application that would work on various mods is almost impossible (in my opinion).  But maybe you are better at it then I was, but if you are going to spend time on something like this I'd vote for a new unofficial editor type of tool.
 
HokieBT said:
as Sir Henry said, if a mod author wants their source to be available then they release it, if they don't then they don't make it public. 

However, I can also comment on this further since I wrote the troop editor.  Personally, I found just trying to translate the single troops.txt file fairly difficult, some stuff was easy, but trying to figure out all the various flags and other stuff was a pain and some of it I never figured out.  Then, combine the fact that people can add new stuff to the headers, create their own variables, nest code blocks inside of code blocks, etc, I think you are underestimating how difficult this would be.  The text files also don't contain the comments so those would be missing as well unless you used comments from the native game.  I'm not saying this isn't possible, and you might be able to get it to work with a few files or an un-modified native game, but I personally think a full application that would work on various mods is almost impossible (in my opinion).  But maybe you are better at it then I was, but if you are going to spend time on something like this I'd vote for a new unofficial editor type of tool.

Personally I started it as a tool to reverse engineer parties.txt to a python script, so that I could use a different map with my home-built-only-for-me mod. Pretty much like the tool you made. But then I decided I liked 1257 AD better than native, although I missed some changes I'd made to the original game (like, for example: higher wages for troops and companions all starting at level 1.) To that end I had to reverse engineer the scripts of 1257AD, make the changes I wanted, and rebuild it. I modded a mod, instead of the original game.

I can see how people would want to protect their hard work on a mod though. You don't want 2000 versions of 1257 AD with "improvements" floating around, stealing all your glory as original author. That could be a good reason not to release a reverse engineering tool. But for the rest... A reverse engineered txt file will miss comments, some constants and even local variable names (which makes module_scripts.py a pain to read), but you have the exact process by which files are converted in your process_* files, so reverting that will work for any mod.

As an example:

The original code from a clean module_scripts.py for process_kingdom_parties_ai reads:
  ("process_kingdom_parties_ai",
    [
      (try_for_range, ":troop_no", kingdom_heroes_begin, kingdom_heroes_end),
        (troop_slot_eq, ":troop_no", slot_troop_occupation, slto_kingdom_hero),
        (neg|troop_slot_ge, ":troop_no", slot_troop_prisoner_of_party, 0),
        (troop_get_slot, ":party_no", ":troop_no", slot_troop_leaded_party),
        (gt, ":party_no", 0),
        (call_script, "script_process_hero_ai", ":troop_no"),
      (try_end),
  ]),

while a version reverse engineered from scripts.txt is like this:
("process_kingdom_parties_ai",
  [
  (try_for_range, ":localVar0", "trp_kingdom_1_lord", "trp_knight_1_1_wife"),
      (troop_slot_eq, ":localVar0", slot_troop_occupation, slto_kingdom_hero),
      (neg|troop_slot_ge, ":localVar0", slot_troop_prisoner_of_party, 0),
      (troop_get_slot, ":localVar1", ":localVar0", slot_troop_leaded_party),
      (gt, ":localVar1", 0),
      (call_script, "script_process_hero_ai", ":localVar0"),
  (try_end),
  ]),

As you can see, :troop_no and :party_no got replaced with the rather nondescriptive :localVar0 and :localVar1, and in the "try_for_range", the constants for the start and end of the kingdom heroes are actual troops and not constants. I could have put the constants in, but I'm not sure if try_for_range always uses them. So it might end up with some strange-looking, albeit functional, script lines. It looks a bit different, but it does the same thing.

I've been playing M&B with reverse engineered and rebuilt scripts/triggers for quite a while, and it all works just fine. I'm absolutely convinced it will work for any mod. I'm just wondering if it's something the community would like to have or if the importance of keeping your "source" secret weighs more heavily in people's opinion than the ability to adjust non-native modules. :smile:

About a new unofficial editor... I'm really not up for building a GUI to edit all this stuff. The module system is good enough for me.

Genveir


edit: I picked this script because it's really short by the way. But the huge complicated scripts work just as well. They just tend to go up to like ":localVar57". But basically you could change those names to anything you like. As long as you change all instances of :localVar57 to :no_jiggly_balloons it will end up exactly the same in your scripts.txt file anyway.
 
actually, you are completely correct.  I was thinking about 'converting' text files, where you would have to manually do the translation.  But if you reverse the process python type of files you would achieve what you described.  I don't think a lot of modders would appreciate it all that much, but I had not thought of this concept before.

edit:  there have been a few cases where people have released a mod but lost their source code, so it could potentially be helpful in situations like that....  But you should remember to backup your source code, etc.
 
Its pretty ironic that a game which makes itself open to modders is then taken by some to become a closed proprietary mod who jealously guard their code against others doing with theirs what they did with TaleWorlds...

Or is there some outstanding reason that I'm missing why TLD is different and needs to be closed?
 
Maybe they'd prefer not to spend 100's of hours working on something just to see a kid's mod that just compiles every spare source code they can find end up getting more attention? There's arguments on both sides really, which is why it's good modders have a choice right now.
 
Mordachai said:
Its pretty ironic that a game which makes itself open to modders is then taken by some to become a closed proprietary mod who jealously guard their code against others doing with theirs what they did with TaleWorlds...

Or is there some outstanding reason that I'm missing why TLD is different and needs to be closed?
Well, it's just that if every mod was 100% open source, then every bit of code would get used and reused until most mods have very little uniqueness about them.
 
Back
Top Bottom