Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Open Letter to FunCom: Please Fix the Resurrection Box

  1. #1

    Default Open Letter to FunCom: Please Fix the Resurrection Box

    First, I would like to say, I have NO IDEA how your code is written, in what it was written nor how it works. I am also not a guru with programming.

    With that said, your resurrection box is that, a box. It is normally referenced in code as a list box or something similar (Java:Jlist(), Visual C++: LB_*, C++:ListBox, VisualBasic:Listbox…you see the pattern?). Every one of these compilers and interpreters has a function or method that allows you to get the size of the listbox. You guys are currently using this ability in your code because when a rez from a healer happens, you place it into the listbox at the end. Now this may occur through and array which you import into the listbox or you are using the listbox to hold the “array.”

    I keep hearing that someone at FunCom said “it is too hard” to fix the bug with the rez box.

    (The bug: When a healer / conq puts a rez on someone the listbox reorders/reloads and goes to the first resurrection point in the list box. This if fine but if another rez comes through when you are paging to the end of the list box and you hit the “Resurrect Button” at that time, you rez out of an instance to a World Resurrection Point.)

    This “bug” is super easy to fix. As I said, every compiler/interpreter that has a listbox tool has a function or method that returns the integer size of the listbox. (If there are 7 items, the size returned is INT 7) At the point after you reorder/reload the listbox, run the associated function or method needed to get the size of the listbox and set it to a local variable. Then use the listbox selection function or method to set the selected item to <listbox size variable> -1. (Most (All of the ones I have seen) use “0” as the first item in the listbox so you need to go to one less than the size of the listbox)

    No other coding is needed. You just need to do this AFTER you repopulate the list box after rezes go out (And you can make this resurrection dependent. A simple “if” statement, if resurrection, run this code. This way it doesn’t mess with how you have set all the world resurrection points). I would recommend that you put this code in at the end of your repopulation function/method or make this its own function/method and just call it as the last thing that happens after you repopulate a resurrection box.

    Much obliged,
    Tankzo

  2. #2

    Thumbs up

    Quote Originally Posted by Tankzo View Post
    First, I would like to say, I have NO IDEA how your code is written, in what it was written nor how it works. I am also not a guru with programming.

    With that said, your resurrection box is that, a box. It is normally referenced in code as a list box or something similar (Java:Jlist(), Visual C++: LB_*, C++:ListBox, VisualBasic:Listbox…you see the pattern?). Every one of these compilers and interpreters has a function or method that allows you to get the size of the listbox. You guys are currently using this ability in your code because when a rez from a healer happens, you place it into the listbox at the end. Now this may occur through and array which you import into the listbox or you are using the listbox to hold the “array.”

    I keep hearing that someone at FunCom said “it is too hard” to fix the bug with the rez box.

    (The bug: When a healer / conq puts a rez on someone the listbox reorders/reloads and goes to the first resurrection point in the list box. This if fine but if another rez comes through when you are paging to the end of the list box and you hit the “Resurrect Button” at that time, you rez out of an instance to a World Resurrection Point.)

    This “bug” is super easy to fix. As I said, every compiler/interpreter that has a listbox tool has a function or method that returns the integer size of the listbox. (If there are 7 items, the size returned is INT 7) At the point after you reorder/reload the listbox, run the associated function or method needed to get the size of the listbox and set it to a local variable. Then use the listbox selection function or method to set the selected item to <listbox size variable> -1. (Most (All of the ones I have seen) use “0” as the first item in the listbox so you need to go to one less than the size of the listbox)

    No other coding is needed. You just need to do this AFTER you repopulate the list box after rezes go out (And you can make this resurrection dependent. A simple “if” statement, if resurrection, run this code. This way it doesn’t mess with how you have set all the world resurrection points). I would recommend that you put this code in at the end of your repopulation function/method or make this its own function/method and just call it as the last thing that happens after you repopulate a resurrection box.

    Much obliged,
    Tankzo

    Please Do fix this stupid bug. +1

  3. #3

  4. #4

    Default

    +1

    Also hire someone who knows the what-to-fix list, is able to prioritize the bugs and has a pointy stick.

    My list is getting very old:
    - Renown bug (on Crom since server merge)
    - Ress window bug (it was fixed already once!)
    - Loot box bug
    - Multiple quest bugs in FotD, Eiglo, Kheshatta
    - Missing loot of old Caravan (recipe+few items)
    - PvP group bug
    - Transfer all cheaters to Rage
    Tainted Souls on Crom - Johara's Featplanner

    Hushi (HoX) - Igne natura renovatur integra

  5. #5

    Default

    let me at the code, I'll fix it for free!
    Requiem Nex Combat Monitor | Options not Saving temporary Fix
    Can Devs please fix:
    • new ressurections resetting the currently selected ressurect position
    • loot timeout windows disappearing before progress bar completes when box hasn't been opened quickly

  6. #6

    Default

    I like how OP starts with "I have no idea how your code is written" and ends with "this is how to fix it".

  7. #7

    Default

    Quote Originally Posted by Tankzo View Post
    ...
    This “bug” is super easy to fix. As I said, every compiler/interpreter that has a listbox tool has a function or method that returns the integer size of the listbox. (If there are 7 items, the size returned is INT 7) At the point after you reorder/reload the listbox, run the associated function or method needed to get the size of the listbox and set it to a local variable. Then use the listbox selection function or method to set the selected item to <listbox size variable> -1. (Most (All of the ones I have seen) use “0” as the first item in the listbox so you need to go to one less than the size of the listbox)

    No other coding is needed. You just need to do this AFTER you repopulate the list box after rezes go out (And you can make this resurrection dependent. A simple “if” statement, if resurrection, run this code. This way it doesn’t mess with how you have set all the world resurrection points). I would recommend that you put this code in at the end of your repopulation function/method or make this its own function/method and just call it as the last thing that happens after you repopulate a resurrection box.
    ...
    Why do you suggest to select the last item in the list?
    This may conflict with the users selection before the list contents changed.
    I would suggest to leave the current selection where it is as long as the selected item stays in the list.

    The list object seems to rebuild the whole list and reset the selection to 0 each time an item is added.
    Not sure if this could be changed and how complex that would be.

    Not touching this code and just resetting the selection to whatever after the list rebuild finished sounds easy but may cause the next problem.
    What happens if the user clicks the rezz button and the list is being rebuild at the same moment?
    You will have two threads competing, one rebuilding the list and changing the selected index to 0 and back (or to the new last item) and another one sooner or later calling something like "getSelectedIndex".
    If the two threads are not synchronized regarding setting/getting the selected index, you may still get index 0 by chance.
    Nalianda

  8. #8

    Default

    Quote Originally Posted by Leif0311 View Post
    What happens if the user clicks the rezz button and the list is being rebuild at the same moment?
    You will have two threads competing, one rebuilding the list and changing the selected index to 0 and back (or to the new last item) and another one sooner or later calling something like "getSelectedIndex".
    If the two threads are not synchronized regarding setting/getting the selected index, you may still get index 0 by chance.
    have you ever heard about semaphores? it's a standard construct in parallel programming...
    "in the depths of a mind insane fantasy and reality are the same"

    Yawgmoth (Ranger) - Nyxathid (Necro) - Yixlid (HoX) - Kaltas (DT) - Heung (BS) - Teysa (HoX) - Gatzu (Guard) - Krovax (Ranger) - Hurkyl (Barb) - Vedalken (PoM)

  9. #9

    Default

    Quote Originally Posted by Leif0311 View Post
    Why do you suggest to select the last item in the list?
    This may conflict with the users selection before the list contents changed.
    I would suggest to leave the current selection where it is as long as the selected item stays in the list.

    The list object seems to rebuild the whole list and reset the selection to 0 each time an item is added.
    Not sure if this could be changed and how complex that would be.

    Not touching this code and just resetting the selection to whatever after the list rebuild finished sounds easy but may cause the next problem.
    What happens if the user clicks the rezz button and the list is being rebuild at the same moment?
    You will have two threads competing, one rebuilding the list and changing the selected index to 0 and back (or to the new last item) and another one sooner or later calling something like "getSelectedIndex".
    If the two threads are not synchronized regarding setting/getting the selected index, you may still get index 0 by chance.

    Having it move to last item is better than resetting to first item. If I get a res from a PoM, and I scroll to it, I will happily accept the conq res that comes in on top of it rather than have to run from the res pad.

  10. #10

    Default

    Quote Originally Posted by Yawgmoth-VDN View Post
    have you ever heard about semaphores? it's a standard construct in parallel programming...
    I not only heard of them but use them quite often. But it would have gone too far to mention mutex semaphores and stuff like that I thought.

    Quote Originally Posted by Amabala View Post
    Having it move to last item is better than resetting to first item. If I get a res from a PoM, and I scroll to it, I will happily accept the conq res that comes in on top of it rather than have to run from the res pad.
    Yes, I did not mean to select the first item, as it is now, but to keep the selection where ever it was.
    Changing it to selecting the last item is still better than what happens now.
    Nalianda

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •