Future of ROCred and RO Patcher Lite

Do you consider ROCred complete?

  • Yes

    Votes: 25 51.0%

  • No, it's lacking feature xyz (post it)

    Votes: 8 16.3%

  • No, it does not work for me (post it)

    Votes: 0 0.0%

  • No, it's hard to use/configure (post it)

    Votes: 0 0.0%

  • Not using ROCred

    Votes: 16 32.7%

  • Other (post it)

    Votes: 0 0.0%
  • Total voters
    49
  • Poll closed .
Ai4rei

Ai4rei

New member
Messages
243
Points
0
Age
114
Location
Czech Republic
Discord
ai4rei
IRC Nickname
Ai4rei
Github
ai4rei
Hello Hercules Community

I would like to ask you to tell your opinion on the future development of both ROCred (launcher) and RO Patcher Lite (auto-patcher/updater). While I may have an opinion myself, it is you who use it, so I would like to make sure future changes are in favor of the people using those.

Thank you in advance for your cooperation.

Poll is closed. See below for results.

 
Last edited by a moderator:
I'd like to see the patcher feature (I use it to patch from bRO) as a plugin to ROCred so I guess I can choose the official RO that I'll patch from, otherwise it would be nice if you merge them both but let us choose which official RO or whatever we will patch from, btw anything you choose will be nice
default_smile.png


 
I assume that means the patcher should update multiple GRF's at the same time (parallel). There is no real benefit of doing so in comparison to patching one after another (sequentially). Actually the patch process will be slowed down if the connection is over-utilized or storage is a mechanical hard drive (delays through unnecessary seeking due to multitasking).

tl;dr: Already supported, except not in parallel, but sequentially.

 
can you add feature like "auto start" when it done patching? (a checkbox)

 
ROCred + patcher = perfect

ROCred only is bad as people have to use the patcher , run the patcher then exit and start rocred.

but if the rocred as patcher in it,.. it will be the most awesome thing.

 
Ai4rei said:
I assume that means the patcher should update multiple GRF's at the same time (parallel). There is no real benefit of doing so in comparison to patching one after another (sequentially). Actually the patch process will be slowed down if the connection is over-utilized or storage is a mechanical hard drive (delays through unnecessary seeking due to multitasking).

tl;dr: Already supported, except not in parallel, but sequentially.
Click to expand...
well  its ok if the patcher will not patch all of them simultaneously but what is important is atleast the patcher is checking the client if its patch or not. and if it needs to be patched it will patched 1 by 1 

Thank you btw.

 
Last edited by a moderator:
Well, currently ROCred+Patcher (not limited to RO Patcher Lite) can be achieved by specifying ROCred as client in the patcher config.

 
Since there is no further movement in the poll, it concludes with the following result:

rocredrsupoll.png


  • There will be a new "tool", that does both patching and launching (most likely RO Patcher Lite Core built atop ROCred UI).
  • Majority of the RPI's floating around (p-server client survey) are plug-ins responsible for managing patch information, skinning and HTML patch news, which will be part of the new application, so there will be no plug-in system/API for the time being. The RO Patcher Lite API will probably be put on ice as well.
  • No further efforts will be put into ROCred anymore, except bug-fixes (or "security patches" as some people love to word it).
Thank you everyone who participated.
Update 2015-12-23:

Currently struggling (for a few months now) with one of the most basic things: sockets.

The current-public patcher (rsu v2) uses WinINet, a Windows networking component responsible for HTTP and FTP client-side tasks among others, primarily used by Internet Explorer to deal with network, cache and cookies. The API is relatively simple to use and stable, though the latter depends on the Windows version in use (WINE compatibility is a different matter, but it works sufficiently for the patcher to work). Unfortunately this blessing of an API is also a curse, in terms of having no control over it. Somewhere around IE7 or IE8 someone came up with the idea to screw with the timeout handling, referring to the fact, that you can update the timeouts to desired values; the problem is, it does not always work. So people were expected to wait for an connection to timeout after 2 hours, where it should have failed after 15 seconds.

The plan was to make replacement (pretty much like rsulib was for libgrf) for the next major release, which would be rsu v4 along with the result of this poll (which only has rocred built atop of it). The result should be 4 more components (internally referred to as snippets, ex. the absent code from rocred reference source): socket, telnet, http and ftp. The last three are pretty much done. But socket, which actually is around for a while (which is maybe one of the problems), cannot deal with conditions beyond localhost and multi-threading properly, and the API merely mirrors the BSD sockets. It also tends to lose data on *nix for a certain reason. So while trying various models and occasionally experimenting with inconsistent IPv6 parts of the API, both releases are being delayed.

Why I do not use some of the available libraries, ex. curl? Some use GPL, some did not work for me and the last few I am merely too stupid to figure out how they work.

Update 2016-02-21:

Things are finally starting moving. While I still cannot state some ETA, sockets are being actively worked on, basically typing.

Also while going through some Windows SDK headers, I found some support code to implement support for IPv6 without having to raise the minimum OS requirements (the code provides down-level functions for OSes without IPv6 support).

Update 2016-09-29:

Sockets are complete, time to put all those puzzle pieces together.

Update 2017-04-15:

The core still needs some work, but it starts to look good.

 
Last edited by a moderator:
Merging is still in progress, the rsu codebase is messy, so it will take some time.

Update 2017-08-04:

Someone give me a full week hikikomori mode without disturbance and I can release it...

Update 2017-08-05:

People who will want to extend the functionality of the patncher, can start learning COM. The plug-in will have to establish communication with a call like this:

hr = CoGetClassObject(CLSID_PluginServiceProvider, CLSCTX_INPROC_SERVER, NULL, IID_IClassFactory, &lpServiceProvider);


Update 2020-08-18:

Obviously no one will read this, and no one will dare to make a necro-post in response to this. Since I have nothing to do for a week, I'm finishing that thing. Things are coming along quite well so far. The updater part is written from scratch, since the RSU code-base is too outdated. Not sure about the ROCred part, there is currently no UI. Oh yeah, there is no name either...

 
Last edited by a moderator:
Ai4rei said:
Merging is still in progress, the rsu codebase is messy, so it will take some time.

Update 2017-08-04:

Someone give me a full week hikikomori mode without disturbance and I can release it...

Update 2017-08-05:

People who will want to extend the functionality of the patncher, can start learning COM. The plug-in will have to establish communication with a call like this:

hr = CoGetClassObject(CLSID_PluginServiceProvider, CLSCTX_INPROC_SERVER, NULL, IID_IClassFactory, &lpServiceProvider);

hr = CoGetClassObject(CLSID_PluginServiceProvider, CLSCTX_INPROC_SERVER, NULL, IID_IClassFactory, &lpServiceProvider);


Update 2020-08-18:

Obviously no one will read this, and no one will dare to make a necro-post in response to this. Since I have nothing to do for a week, I'm finishing that thing. Things are coming along quite well so far. The updater part is written from scratch, since the RSU code-base is too outdated. Not sure about the ROCred part, there is currently no UI. Oh yeah, there is no name either...
Click to expand...
Of course, people will read it 😀. Atleast I am waiting to see how this turns out.

 
Update 2021-02-26:

While this still has no tangible name, currently running under the working name SKAL (which was previously ELUR and permutations thereof, including LURE, even though it won't lure anyone), the patching launcher itself is taking form. The plug-in system will be post-poned to a later version, because currently it is very fragile and the built-in functionality ought to be enough for anybody.

The skin support, as opposed to ROCred, will use PNG rather than BMP. While magenta will still serve as transparent color and alpha-blending support is absent, at least the skin files will be smaller. Like pre-2.4.5 RSU plug-ins PANTEXT and PANHTML, the patch news will be built-in and use the IE WebView for HTML patch news (how that works out on Win10 will be left for community feedback). The major difference is, that you can summon multiple patch news (as much as Windows allows), for example for providing seem-less interactive controls to the interface, like server status. As in ROCred the amount of buttons is also limited by available memory only.

The patch part builds on top of the RSU4 framework and the RSULIB3 library so you get the same performance, but with multi-GRF support. RGZ support is planned in the initial version. Later versions may introduce support for ZIP, RAR, 7Z/LZMA, either built-in, or as plug-ins.

The launcher part remains essentially unchanged to ROCred.
 

How configuration will be provided is not yet decided, options are three. Embedded into the plauncher (AV vendors hate this), a separate file or files, or all resources stored in a remote location.

 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top