Jump to content
  • Sign Up

Aeomin

Members
 View Profile  See their activity

  • Content Count

    69

  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Aeomin

  2. Posted

     

     

    I'm not sure if it makes a difference, but the error only occurs when the Thor Patcher is located in the directory of the RO Client. If it's located anywhere else in the file system, there is no error at all.

     

    EDIT: I tried to test 2.6.4.13b but I am not able to pack the configuration with ConfigGenerator.exe. It says that it fails. Packing works with 2.6.4.13 but not 2.6.4.13b.

    Interesting. so something to do with permission then.

    Packing works here, maybe you need move patcher out ro client first or run packer in administrator.

    Ah, yeah it was a permission issue. I haven't disabled UAC on this new computer.

     

    2.6.4.13b does not have any errors when executed outside OR inside the RO Client directory on a Windows 10 machine. Nice job. :)

    Oh that's the cause then.. I will need check updates on that component then

  3. Posted

    I'm not sure if it makes a difference, but the error only occurs when the Thor Patcher is located in the directory of the RO Client. If it's located anywhere else in the file system, there is no error at all.

     

    EDIT: I tried to test 2.6.4.13b but I am not able to pack the configuration with ConfigGenerator.exe. It says that it fails. Packing works with 2.6.4.13 but not 2.6.4.13b.

    Interesting. so something to do with permission then.

    Packing works here, maybe you need move patcher out ro client first or run packer in administrator.

  4. Posted

    @@Aeomin

     

    maybe he is talking about the loader like something like "rocred"

    The main challenge I would say is that input box. To style windows's input box to a good looking is hard if not impossible. Custom implementation takes a lot of time.

    If people are okay with whatever windows's built in one, then I can just export to script API and implement the logic themselves.

  5. Posted

    Aeomin, do you plan to integrate the loader in the patcher on 3.0?

    What loader?

     

     

     

     

    When launching with V2.6.4.13 I'm getting this error:

    lt3WTTd.png

     

    After I click okay, Thor will start up.

     

    EDIT: I am running Windows 10.

    Yes I do receive similar bug report. However I couldn't figure out the reason as I wasn't able to reproduce it on both windows 10 and 8
    Hmm, that's strange. I'll provide more information if I ever figure out anything else.

     

    Is it possible to release a version that's in debug mode so that I can get you more information on where the error is occuring at runtime?

     

    If not I suppose I'll patiently wait for version 3. :P

    The latest build included the exception handler. It's a third party component I have used long ago. Maybe the version is not compatible with windows 10.

    I'll reupload see if remove it would solve the problem.

  6. Posted

    When launching with V2.6.4.13 I'm getting this error:

    lt3WTTd.png

     

    After I click okay, Thor will start up.

     

    EDIT: I am running Windows 10.

    Yes I do receive similar bug report. However I couldn't figure out the reason as I wasn't able to reproduce it on both windows 10 and 8

    evilpuncker reacted to this

  7. Posted

    I think there a problem when using the Start func becuase the exe didnt popup when tryed using 2.6.4.9 to 2.6.4.12 but if i try 2.6.4.8 the exe will popup normally.

    That's odd.. there is no related change between 2.6.4.9 and 2.6.4.8. I will take a look though,

    evilpuncker reacted to this

  8. Posted

    Oh cool, you figured out thor format.

    I took a glance your implementation, it seems fine.

     

    One recommendation though. The "Mode" you are referring (0x21, 0x30) is actually version number. While there are earlier versions, they are already dropped. The plan is drop out 0x21 in the future.

    So even for patching patcher and client, use 0x30 is good enough. The reason I use 0x21 in thormaker only because when 0x30 came out, people needs upgrade old patcher but those of course won't able to read it.

    All the version after that will recognize it, there is no special treatment during patching. And what happens after all these years? "If it's not broken, don't fix it" (terrible btw).

    So always use 0x30 when creating thor file if that makes your life easier. 

     

    Will there be any more format change?

    Maybe.. I do have some ideas floating around to have some kind extensible format, but I don't think it justify the needs right now. Will likely open specification if it ever happens though.

    evilpuncker reacted to this

  9. Posted

    my brain just exploded now, jk

     

    what I mean is not making a private localization file for me, but one so you can distribute it with the patcher itself :P

    Just give me the files, I will include it. There is no special approval process.

  10. Posted

    @@Aeomin

    if you plan to have localization into the patcher, provide me the file as soon as possible so I can translate it to pt-BR for you :P

     

    That feature is been there for years. 3.0 will use json instead ini files though. You will need add a json file in Configuration/Languages. Take Default.json as base template..

    Do note that json specification doesn't allow comment, but patcher's parser is generous enough to allow that at this moment.

    You will also need to modify Configuration/LanguageMap.json to map the language to locale ID. ID can be found in LCID Dec column at http://msdn.microsoft.com/goglobal/bb964664.aspx

     

    And very important: the language file needs to save in UTF-16 LE with BOM, otherwise patcher might display gibberish.

  11. Posted

    A quick update.

     

    After days of rushing through, I hereby releasing alpha version of 3.0. This is mainly for those who want get familiar with new setup earlier than completely puzzled later as document is scarce as usual.

     

    There is another reminder to make sure it sticks: ONLY USE FOR TEST PURPOSE, DO NOT RUN IN PRODUCTION ENVIRONMENT.

    evilpuncker and Legend reacted to this

  13. Posted

    Hey guys. Sorry for not being active for a long time (like 2 years?).

    I'm still struggling with time and patience to continue on. But will get there! Working on get back to track.

     

    Anyhow, I have decided to abandon version 2.7 and move to v3 due to major changes that are not even marginally close to backward compatible.

    For some, this might be good, for others maybe is "WTF R U DOIN?"

    For those who already knew what would be in 2.7, yes v3 is going to use json and config (maybe something else, but definitely not ini) and use lua scripts to finer control behaviors.

    evilpuncker and Legend reacted to this

  14. Posted

    I've been using thor for many years now and never experience major issues only after you publish ver2.6.1.66+ the issues occurred. And I think the most stable right now is 2.6.1.66 no offense.

     

    I also notice while patching the download speed is not normal.

     

    that's why we reverted to 2.6.1.66. Is it possible that you implement this feature

     

    [2014-03-29] Aeomin - Progress bar now uses system native style, change color feature is deprecated. Use image based progress bar if needed.

    in 2.6.1.66

    You mean that's the cause of corruption? I doubt so...

     

     

    There isn't any known issue, but I have changed a lot in the code. So it could be regression happening. If you have reproducible problematic patch file, send them to me.

    Well, there isn't any duplicate file detection because it would decrease performance.

    https://www.mediafire.com/?rymv44z6l2122c9

    The "Corrupted" folder is the original patch that failed, I believe it was the textureÀ¯ÀúÀÎÅÍÆäÀ̽ºmap[email protected]<script cf-hash='f9e31' type="text/javascript"> /* */</script> and [email protected]files that were corrupt. The "Clean Repatch" folder was my attempt to fix it by repatching the original files, but it failed to repatch them. I left the original data files in there as well so you can see that the originals weren't corrupt.

     

     

    As a note, I found out that if I add a patch with a different file using the same name, then patch the original file again, it usually fixes it. So for example, if HeadgearA.spr gets corrupted, I could just rename RandomHG.spr to HeadgearA.spr, patch it, then patch in the original HeadgearA.spr again and it wouldn't be corrupted anymore. It definitely seems like there's something preventing it from repatching identical files, so maybe it's integrated into the GRF library you're using or something.

    I haven't tested that file yet, but my speculation that somehow renaming fixed corruption would be the new file is larger than the old one? When new file file is larger, it goes to a different mechanism..

    There isn't anything that prevents repatching identical file, and the GRF library is custom made.. I will test it out.

    evilpuncker reacted to this

  15. Posted

    Sorry for this long delay, I have not been monitoring the forum. Was expecting getting email notification but doesn't seem to be the case.

     

    hi, is there a way to run the patcher as admin by default?

    It used to be run as admin by default, but mechanism changed to run as admin when needed. Is it not working properly?

     

     

    http://superuser.com/a/605012

    ^ That explains how to make the patcher run as admin automatically, for all those that have been asking. It requires the Windows SDK (which is free) to do so, but it only take a few minutes to set it up.

     

     

    By the way, Aeomin, there seems to be some kind of issue with the newest version (2.6.4.8) giving corrupt patches. I know for a fact that the files I'm patching aren't corrupt (if I put them in a GRF myself they work fine, and even viewing in Windows via thumbnail shows up fine), but as soon as I patch them using the latest Thor they'll be corrupt. It only happens with a few select files, but if I try to re-patch them (again, using the clean, non-corrupt files), they'll still be corrupt. If I try patching those same files in again with a new file name, they'll suddenly be okay.

     

    Which leads me to 2 questions:

    1) Is there a known issue with certain files or file names not being packed properly by Thor? It seems to happen with various file types (.spr, .bmp, etc), so I'm not sure exactly what causes the corruption. It's definitely not a problem with the original files, though.

    2) Does the new patcher have some kind of check to avoid duplicate files being patched in? It seems odd that I can't just re-patch the clean files to fix them, and doing multiple patches so I can rename corrupt files is a little excessive.

     

     

    As a note, I previously used version 2.6.1.64 and never had a single corrupt patch go through that one, so it's definitely something that was changed in the patcher in one of the more recent updates.

     

    Thanks. :o

    Yea, that is how previous versions enforces admin privilege. But mechanism changed.. the new method might be crap though..There is another way that is more user friendly but haven't try it yet.

     

    There isn't any known issue, but I have changed a lot in the code. So it could be regression happening. If you have reproducible problematic patch file, send them to me.

    Well, there isn't any duplicate file detection because it would decrease performance.

    Yea , older versions might work.. but I do remember they have memory problem, so it might work for you but crash for others.

     

    same here I'm having issues patching in latest thor and also the .dat file, the latest thor doesn't read the old .dat file so when the patcher.exe is replace it patch again in the very first patch.

    Which old version?

    evilpuncker reacted to this

  16. Posted

    is it possible to have player send their main file hash ? client.exe has it featured built in in thor patcher can you please make it can be configured to tell specific file to send their hash to server to confirm

     

    Hashing related function is marked deprecated.

    evilpuncker reacted to this

  17. Posted

     

     

    Yes Aeomin, i Mean, do all the current features, and after patch is complete, when you click on Launch button, the patcher prompts for the user and password, then sends it to the exe as hash (since they removed login window)

     

    Currently it is at feature freeze. New feature would be possible starting next major release, which is bit overdue now. Hopefully I have some time next 2 months.

     

    I hope everything is going fine to you =) this is still the best patcher ever xD

    I find myself working on this project every now and then. Time and laziness kills.

    evilpuncker reacted to this

  18. Posted

    Yes Aeomin, i Mean, do all the current features, and after patch is complete, when you click on Launch button, the patcher prompts for the user and password, then sends it to the exe as hash (since they removed login window)

     

    Currently it is at feature freeze. New feature would be possible starting next major release, which is bit overdue now. Hopefully I have some time next 2 months.

    evilpuncker reacted to this

  19. Posted · Edited by Aeomin

    Can I suggest something, Aeomin?

    Could you bundle a "loader" part in the patch? after the patch is complete, this would make this patcher so awesome!!!!! :D

    loader part?

     

    Aeomin, I was using the exact same patcher that I had sent you for reverse-engineering.

    2.6.1.66? There are known bugs in this version...

    [EDIT]

    Oh you are updating to current version. Have you tried the one I provided from last reply?

  25. Posted

     

     

    Aeomin can you add feature to it that it can pass parameter?

     

    :meow:

    parameter? from where to where?

    from external login to patcher to exe..like Ai4rie rsu patcher it can pass parameter..

     

    :meow:

    Oh, I will take note of that.

×
×
  • Create New...

Important Information

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

  I accept