RockPatch -> Ares Migration Assistance

[Renegade]

Good day,

for those of you who didn't follow the other topic, the suggestion to create a converter for those switching from RockPatch has come up.

Given that those who used a previous pd-inspired exe patch will likely be the first ones to adopt the next generation of them, I do think helping and supporting people switching from RP to Ares is an important step in establishing Ares as the new exe patch. (Whether it technically is an "exe patch" or not is a different topic.)

I created this thread (and will sticky it) to serve two purposes:

1. Help switchers directly. This thread shall serve as the central support thread for RP modders having problems switching, and, in the process, hopefully grow into a documentation that answers frequently asked questions about RP->Ares switching before a modder has to ask them.
   
2. Development of a converter. I volunteered to give writing a converter a first try, but I need help gathering the neccessary data: I need to know...
   • What RockPatch-versions are currently in use, and who of the people here uses which?
     
   • What features do you guys know for a fact exist in both RP and Ares, making a conversion possible?
     
   • What RP features do you guys know for a fact do not exist in Ares, making their conversion impossible?
     
   And I need RP INIs. I need real-life RockPatch-ified rulesmd.inis so I can test conversions on actual data. Examples of RP-code and the correct equivalent Ares-code, if you've done such a thing before, would also be greatly appreciated.
   

Obviously, once there is a converter, somebody will also have to actually try the conversion and see if it works as expected, but that's a thing for the future.

I'm also open to suggestions how the converter should look/work.
Currently, my idea is making it a wxWidgets application (got to be something cross-platform, 'cause I can't do native Windows development), having a load button to load RP rules, an execute button, a text field which shows the converted sections and other notes, and a "save to ini" button to save the complete converted ini. (I will make it preserve comments, 'cause I hate those tools that just wipe them out.) I don't know whether I'll actually parse the INI yet, or if I'll just do simple text operations, but that's ultimately an implementation detail, nothing more.

I *may* offer the option to generate a diff between converted and original file, if a diff util is present, but that's low priority.

So yes. Talk to me about the converter, shower me with your wisdom and code, and help those who want to join the next generation of YR modding.
(Administrative side note: This thread will, by design, attract newbies. You don't have to accept full-blown n00b behavior, as usual, but in general, be lenient and nice - while the n00bs are a lost cause, the newbs could grow into formidable modders - if we don't push them to the n00b havens.)

---

Features known to work in both RP and Ares:

• Coming soon
  

RP-features known not to work in Ares:

• Coming soon
  

Post here if you need help switching from RockPatch to Ares!
Please include the exact version designation of the RockPatch you're using and all other information available, such as which RP features you're using, where and how exactly the problem occurs, and what you have attempted to fix it so far.

[Tempest]

I'm just gonna go download the Rockpatch documentation and compare against ares'. That'll probably give a lot of 'possibles' and 'impossibles'..

[Professor_Tesla]

Here is a RockPatchified rulesmd.ini (attached to this post). It is huge. And when I made the changes to it, I was using Rock Patch 1.10 Super Mega Turbo Lightning Hyper Fighting Edition, revision 36.

[Renegade]

Thanks, both of you

Any interface/functionality suggestions?

[Renegade]

This is pre-alpha, the most functionality it has right now is calling the open/save dialogs, but I thought I'd give you something shiny to look at, and get your comments on the layout right away:    

Ignore the colors, that's just my personal theme, nothing fixed. Two main questions to answer:

1. How do you like the layout overall? Good, bad? Anything important missing?
   
2. The checkbox option is badly labeled, imo, but I can't come up with a better label. Ultimately, what will happen is, if that checkbox is checked, the converter will check for RockPatch flags which are set in the INI, but have no equivalent Ares function yet; it will then comment those flags out, with a special marker to tell the converter to check these outcommented flags in the future, in case that functionality got added to Ares. (If unchecked, the converter will just ignore RP flags there is no Ares equivalent for, leaving them in the INI.) So...how to label that checkbox? I'd like to keep the label length roughly in the current dimensions, and avoid multiple lines...just a quick, succinct summary of what one is checking there. Any ideas?
   

As mentioned before, it's being done in C++ with wxWidgets, so it'll be cross-platform compatible, and I'm compiling with the -ansi flag, which limits the code to "The 1998 ISO C++ standard plus amendments.", so the code should compile on any system wxWidgets works on in the end, and be compilable with any standards-compliant C++ compiler.

In all likelihood, I'll drop the source in Ares's tools repository once I release, which poses another question: Which license to use? By default, I'm tending towards GPL, but I'm open for suggestions, in case someone would prefer a different license for a good reason?

[DCoder]

Layout is good.

Checkbox = "Remove unsupported"?

License = BSD. Just because.

[Professor_Tesla]

I think the overall layout looks good. Maybe the checkbox could be labeled "Disable unsupported."

[WoRmINaToR]

Now, I fully understand that NPatch was not a PD project and most people don't really like it... but it is relatively similar in many aspects. Would it be too far of a stretch to include NPatch conversion functionality into this?

If not, I can cope, as it wouldn't be too incredibly difficult to go rewrite some of my rules entries, but it would be nice since you're going this far out for RockPatch.

Also, if I may say so, the interface looks good so far. Nice and simple with a somewhat professional touch on the interface colors.

For the checkbox, for a little extra clarity, you could perhaps say "Disable Unsupported Flags", as simply "Disable unsupported" may perhaps be a bit vague. You can reduce text size slightly if multiple lines is a problem for you.

[Renegade]

Disclaimer: In all instances, "you" is a general, plural "you" in this post, not a personal "you" directed at WoRmINaToR. This message applies to all NPatch users.

As it has been stated numerous times before, we do not offer NPatch support.
VK's abrasive nature, his utter lack of quality assurance, random decisions to stop coding, and the general bugginess of his code have all been known for a very long time.

In other words: Anyone who decided to go with NPatch had it coming.

You can't say "fuck quality", abandon ship, go with the mad scientist of EXE hackers for a year, totally mess up your rules and mod with NPatch-induced madness, and then realize "oh shit...the RenProj dudes were right - this sucks!" and then expect us to be waiting here investing time and energy to fix your problems for you.
If NPatch was built reasonably, I might have done it. The way it is, I refuse to wade through the documentation to try to understand wth he was thinking. That is, if there is any documentation at all. Would surprise me.

And, to be perfectly honest, even if I wanted to support NPatch, I couldn't - since VK has no problem randomly renaming flags and changing functionality just because, I would have to constantly track what exactly currently works how in NPatch and adapt the converter. No way.

Sorry, but if you decided to go with VK's madness despite us constantly and continuously pointing out how badly NPatch is developed and how unreliable VK is, then you're on your own. Choosing NPatch despite its problems was your decision, not ours, and there's no reason we should have to support his bullshit just because people chose not to listen and go with him anyway.



That being said, I did not plan on recompiling the converter every time a new Ares is released. I plan on implementing a text-based file format that describes which changes to perform, so that we only have to release new translation files should something change, not an entirely new converter.
So if you're up for it, once it's developed, you can just go and edit the translation file to work on NPatch flags instead. But that will not be officially supported. If you want to, you can even start an NPatch->Ares thread on your own and debate with other users how to migrate. I won't sticky it, I won't provide support, but I won't kill the thread, either.
It's not like we're telling NPatch users they can't use Ares. We're happy if NPatch users switch.
We just feel that, if, after reiterating over and over and over again that we advise against NPatch usage, people still chose to go with that rather than RP or Ares, the consequences of that decision are their problems to deal with, not ours.

In addition, as pointed out further up, the converter will be coded in standards-compliant C++, under an open source license, using an open source widget library - so even if pure translation file editing doesn't help, nothing's stopping anyone from making the necessary changes for it to support NPatch.

Bottom line: NPatch support can be added to the converter, but I won't be the one doing it.

[WoRmINaToR]

alright, well I got my answer (gosh, seems like you could write a book on how much you hate NPatch )...
(On a side note about documentation... while his grammar is absolutely atrocious, it is documented in quite good detail, at least in his NPAE MDK. His NPAE was at least somewhat stable, given that I haven't messed with some of the more complex features...)

yeah, I'm one of the guys that is avidly following Ares development... i'm switching immediately the second a stable release comes out, whether I do it the easy way or the hard way.

Anyways, yes, it's quite alright; don't think i'm one of those idiots who's going to storm in here and say "SUPPORT NPATCH NOW OR U SUCK RAWRBWABWABWA!!!", since I do know that NP is not well-liked... I followed VK out of necessity (man do I wish pd would have stayed on rockpatch, but i understand why he stopped); It did have several features that I used however that RP didn't have so for my purposes I used it instead because I knew those features would never make it into a RP. besides, it's more of a personal mod at this point anyways... i've been considering going public as it's got massive potential, but i am hindered greatly by the fact that I don't have any webdesigning experience, so i effectively cannot get hosted...

Anyways, I'm rambling...

[Renegade]

It's less the amount of hate making a book necessary, it's the number of things wrong with NPatch

If NPatch is well-documented, then it should be easy for you to write replacement logic. Ultimately, it'll be nothing more than simple instructions along the lines of "if you find this flag, change it to this and place the value there".
I don't know what kind of format I'll give the file yet, but it looks like wxWidgets comes with classes to parse XML documents, so it may end up something like this:

Code:

<old flag="Foo" values="2" seperator=",">
    <new flag="Bar">$1</new>
    <new flag="Baz">$2</new>
</old>

to change

Code:

Foo=42,69

to

Code:

Bar=42
Baz=69

I totally just made that up as I went, so it's absolutely not fixed, I don't even know what kind of reformatting options I'll need to have in place, since I still don't know which flags are translatable in the first place, but it's one way I could imagine it to work, and it should be easy enough for you to adapt for NPatch.

In general RockPatch to Ares INI Converter news, since "RockPatch to Ares INI Converter" is a mouthful, I have found myself adopting "Arpytuares" inside the source and as the binary filename. So if I talk about that, I mean the converter.
I had the thing as far as loading INIs, displaying them, and showing a progress bar while it loaded, but I refactored the code so the working logic wasn't in the GUI event handlers, and am currently having a segmentation fault somewhere. I'm pretty sure I know where and why, though >_> so that should not be a big obstacle.
Something more concerning is execution time. The most convenient way to step through the INI wxW offers is a TextFile handler that allows me to go through text files line by line. It works as expected, it's easy to use, and I'm very sure it'll make the actual conversion very easy to write.
The problem?
The virgin rules I have here are 31068 lines long, Tesla's RP rules have 35593.
That takes....long, to put it mildly.
I'll have to check whether the displaying code is what slows it down, or whether that's just the way the handler is. If it's just the displaying, I can let it work without outputting the code and do that later, but if the handler itself is that slow, you'll have to test whether the speed is acceptable for a one-time or infrequent conversion, or if I have to rewrite it to use a different handler.

I'll keep you posted.

[Renegade]

Tiny live update as I'm coding: I've kicked the segfault I got in the balls earlier, and have determined that, indeed, running through the lines goes a lot quicker when lines are not output as they are parsed. As such, I'll try to work with that file parser for the moment, and just show a summary in the text window once the conversion is done.

I'm currently about to try implementing the conversion rules parser, and this is the syntax I will try to make it understand:

Code:

    <flag simple="1">
        <old name="Soylent"/>
        <new name="GreenIsPeople"/>
    </flag>
    
    <flag simple="0">
        <old name="Owner" seperator=","/>
        <new name="Pwnz0r">$1</new>
        <new name="H4&gt;&lt;0r">$2,$4</new>
        <new name="Lam0r">$3</new>
    </flag>

With that also comes that, once I succeeded in implementing it, I'll have to actually test it. For that, I would really appreciate if people could help me craft lists of available flags of both Ares and RP, and see which functionalities overlap. (That goes especially for the RP-using crowd...you're the ones who'll be using this, after all )

Without that data, I can't possibly debug this thing.

Edit: And since it's been a week anyone but me posted in here, I might just assume nobody cares and stop investing time into this...

[Beowulf]

We didn't think you'd gotten far enough yet.

If you have the XML unhardcoded, I'm probably going to make one for NPatch... as insane as that is.

[Dubzac]

I wasn't expecting this forum to be run by a child.

i intent to change all tags if need be . i have no superweapons that required Npatch or its complex Addon's. Only thing i need is its Ingame.

GUI Menu function for my 3rd side
Air to Air Combat Flying mechanics


I couldn't give a Sh*t if you hated V.K.!, Renegade. that was not the question. Answer Correctly Not a dumb answer please.

Ares dont have
- Superweapon clones
- New sides
- Nextstage logic
- Custom radiation for weapons
- Prerequisite logics
* More, but they are not needed to make the switch

I use none of the above since i read the topics "Guest"

that answer your question?

[Beowulf]

Then you won't have an issue migrating so why the hell are you complaining?