Jump to content

Future of ROCred and RO Patcher Lite  

48 members have voted

  1. 1. Would you favor both applications to be merged into one, that does both auto-patching and launching?

    • Yes, merge both applications into a new one that does both
    • Yes, but make ROCred an optional module (plug-in) of RO Patcher Lite
    • Yes, but make RO Patcher Lite an optional module of ROCred
    • No, keep it separate as is
    • Other (post it)
      0
  2. 2. What do you primarily use RO Patcher Lite for?

    • Updating official data (kRO, iRO, ...)
    • Updating custom data (own plug-in, ipatch functionality/plug-in)
    • Updating official and custom data in one go (own plug-in)
    • Not using RO Patcher Lite
  3. 3. Do you consider ROCred complete?

    • Yes
    • No, it's lacking feature xyz (post it)
    • No, it does not work for me (post it)
      0
    • No, it's hard to use/configure (post it)
      0
    • Not using ROCred
    • Other (post it)
      0


Recommended Posts

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.

Edited by Ai4rei

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites
 

 

Add thor Patcher feature with it will be great..

For example?




Its hard to explain so I will just DRAW it for you, sorry for the drawing hahah.



Note:
- The Start button will only be available if the 3 patchers are 100% or done patching.

 

post-2388-0-72790500-1420199892_thumb.jpg
 

Edited by karazu

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

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.

Edited by karazu

Share this post


Link to post
Share on other sites

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.

Edited by Ai4rei

Share this post


Link to post
Share on other sites

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...

Edited by Ai4rei
Progress.

Share this post


Link to post
Share on other sites
On 7/9/2017 at 2:56 PM, 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...

Of course, people will read it 😀. Atleast I am waiting to see how this turns out.

Share this post


Link to post
Share on other sites

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.

Edited by Ai4rei

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.