Ender client and bug fixes

Forum for alternative clients, mods & discussions on the same.

Moderator: Phades

Ender client and bug fixes

Postby Xcom » Sun Feb 17, 2013 3:46 am

After getting sick of getting random bugs in the ender client I started to after hundred years of dreaded bug crashes look in the code to figure out where things go wrong. In this thread I will try and address a few bug fixes I have found. If you provide a printout of the crash you get I might be able to fix other bugs you might encounter as well.

Goal is to make the original Ender client more stable and maybe improve on it. Hopefully Ender might show up here on the forums and add it to his update thingy and make the update public. Until then bug fixes might only be available to the people that have the ability to compile there own client from the source code found with the git provided by Ender.

Bug number one. Random crash when trying to load a new area:


This bug shows up along with the show player lines in the client when you walk into a new area, for example in and out of a house or minehole, and immediately try and walk in any direction. You get a nullpointer exception in the console if you have yours open and the client freezes. Other players see you as logged in but on your end everything appears to have frozen up.

The bug is found in src/haven/MapView.java.
Line 1478
relating to this line: g.line(player.sc, pc, 2);

player.sc on some instances shows up as null and causes this bug. To remedy this issue you can simply add a null check before this line changing the line 1478 from what it is to this line.

if(player.sc != null && pc != null) g.line(player.sc, pc, 2);

just to make extra sure you could add a null check on the variable "pc" to assure this bug doesn't show up again.


Bug number two. Clint crash but still shows up as logged in.


This is the most frustrating bug as it is related to the recent bug the server is throwing around where it randomly kicks you from the server. You show up as logged out to other players but you don't know if you are logged out or if its just simply lag. What is actually happening is that you have been kicked by the server but on your end you show up as your logged in. The same bug shows up when you go to the options menu and click log out. Your client freezes up completely and you don't know if your logged out or not.

This was a tricky bug to hammer out. Its related to the main clients startup loop.

src/haven/HavenApplet.java runs a loop at line 159 where it constantly loops from the start screen into the game and if the game ends back to the start screen. The big issue in all of this is that the game never ends in some instances. Even if you try and log out the game keeps going.

By game I mean the line 166 rui.run(h.newui(sess));

To fix this issue you have to look into the Session class as it is this loop that never break.

src/haven/Session.java
This class has 3 loops running the main client.

private class Ticker extends HackThread {
private class RWorker extends HackThread {
private class SWorker extends HackThread {

These subclasses are run in a magical loop that even I am not fully familiar with. But it is clear that the variable boolean alive; is mostly responsible for keeping these loops going. From first glance this variable is set to false when the funtion interrupt(); is called in the subclass SWorker. But something goes wrong somewhere and the interrupt(); function is never called. As a quick fix I forced the client to interrupt by adding these interrupt function in the function close() found on line 677 public void close() {

By simply adding these 2 lines I made the client force the alive variable to false and actually break the loops that never were stopping to loop.
ticker.interrupt();
rworker.interrupt();

line 677 changed from:
public void close() {
sworker.interrupt();
}

to:

public void close() {
ticker.interrupt();
rworker.interrupt();
sworker.interrupt();
}

Mysteriesly the bug disappeared on my end when doing this change. Now the client actually does log out and go into the login screen when I crash or if I click the log out button. As I am not fully familiar with the inner workings of the sworker function I am unsure of the exact reasons why this actually works and I don't get 50 errors when interruptions are made prior to them actually be made by the sworker function. But it works as intended so that makes me happy and hopefully wont make my pc explode. I can't say I know why exactly it works but I know it is stable and been working reliably for 2-3 weeks now.


Bug number three. Mouse item buggering up your zoom.


The Ender client added a very nice feacher where you could zoom in and out compared to the original client. But a small bug came along with it. When you pick up an item all world actions are disabled until the mouse item is dropped on the ground or into the inventory. No move action or object interaction, not even zoom works. The zoom feacher is fixable to make you able to zoom in and out while holding a mouse item. You can also scroll items in and out of your inventory holding mouse items. This bug is easily fixable.

There is also a way to make the client interact with the world when holding mouse items but its buggy to implement and honestly I would not suggest to add this feacher unless you know what your doing. You wont get a client crash or anything but you might have the mouse item bug out and force you to drop the item to fix the different client codes from competing over the mouse item.

Zoom fix:

The client code was made so if in the future mouse wheal action connecting to the item you are holding on the mouse cursor was added the code would be already implemented. But as of now there are no mouse cursor and mouse scroll interactions. This whole feacher can be disabled freeing the mouse scroll from the mouse item and , enabling you to use scroll wheal even while holding a mouse item.

To fix this bug / adding of feacher you need to look into src/haven/UI.java

lines 331 to 335 shows you the code you need to edit to make this work.

if(mousegrab == null)
root.mousewheel(c, amount);
else
mousegrab.mousewheel(wdgxlate(c, mousegrab), amount);
}

to fix this simply edit all lines except "root.mousewheel(c, amount);"

makeing it look like this

//if(mousegrab == null)
root.mousewheel(c, amount);
//else
// mousegrab.mousewheel(wdgxlate(c, mousegrab), amount);
//}

This should enable mouse scroll action even when mouse items are held and its honestly stable as I have been using it for over a month.

The ability to move around with mouse items is a bit more complicated. I will only show this feacher if its requested in this thread as its tricky and honestly not stable at all. It also requires a bit of extra code to be added into UI.java, RootWidget.java and Config.java. With a bit of finesse and tinkering it could become more stable and honestly added into the client as a complete feacher but as of now I have no idea how to add it in a way so its intuitive and stable enough.

I hope someone finds this info useful and can add it to there client. If requested I will try and help fix more common bugs.
User avatar
Xcom
 
Posts: 1105
Joined: Wed Dec 14, 2011 1:43 pm

Re: Ender client and bug fixes

Postby mvgulik » Sun Feb 17, 2013 4:12 am

PS: Suggest you just try to ping Ender and talk with him a bit about possible ways to provide potential bug fixes/patches to the Ender client.

Good luck
mvgulik
 
Posts: 3742
Joined: Fri May 21, 2010 2:29 am

Re: Ender client and bug fixes

Postby borka » Sun Feb 17, 2013 1:17 pm

pointed Ender to this thread in haven channel...

ty Scientist for posting this :D
Avatar by SacreDoom
Java 8 - manually downloads - good to check for actual versions url here:
viewtopic.php?f=42&t=40331
Remember what the dormouse said: Feed your head Feed your head
User avatar
borka
 
Posts: 9965
Joined: Thu Feb 03, 2011 7:47 pm
Location: World of Sprucecap

Re: Ender client and bug fixes

Postby aghmed » Sun Feb 17, 2013 8:34 pm

when we touch Mapview 1 tweak that is very useful:
Code: Select all
 private void drawGobPath(GOut g) {
   Moving m;
   LinMove lm;
   Coord oc = viewoffset(sz, mc);
   g.chcolor(Color.ORANGE);
   synchronized (glob.oc) {
       for (Gob gob : glob.oc){
         if(gob.isHuman() && gob.id != glob.oc.getgob(playergob).id )
         {
            KinInfo kins = gob.getattr(KinInfo.class);
            if(kins==null) g.chcolor(255, 0, 0, 90);
            else
            switch(kins.group)
            {
               case 0: g.chcolor(255, 255, 255, 90); break;
               case 1: g.chcolor(0, 255, 0, 90); break;
               case 2: g.chcolor(255, 0, 0, 90); break;
               case 3: g.chcolor(0, 0, 255, 90); break;
               case 4: g.chcolor(51, 255, 204, 90); break;
               case 5: g.chcolor(255, 255, 0, 90); break;
               case 6: g.chcolor(255, 0, 255, 90); break;
               case 7: g.chcolor(255, 150, 50, 90); break;
            }
         }
      else
      g.chcolor(Color.ORANGE);
      if ((Config.showgobpath && gob.isHuman()) || (Config.showothergobpath && !gob.isHuman())) {
         if(gob.sc == null){continue;}
         m = gob.getattr(Moving.class);
         if((m!=null)&&(m instanceof LinMove)){
             lm = (LinMove) m;
             g.line(gob.sc, m2s(lm.t).add(oc), 2);
         }
      }
       }
   }
   g.chcolor();
    }


shows player walk path equal to kinlist color (if not kin then red), sometimes you can get really scared seeing orange line and its just ladybug xd
public static class StupidJavaCodeContainer {
/* oh, i love swing. */
class checkOutMyPathfinder{
Image
}}
User avatar
aghmed
 
Posts: 238
Joined: Fri Sep 07, 2012 7:20 pm
Location: between London and third part of LSD

Re: Ender client and bug fixes

Postby EnderWiggin » Mon Feb 18, 2013 3:12 pm

  1. well, this change is pretty safe. But it would be better to find out why exactly player coordinate becomes null. Oh, and pc can't be null on that line - it is assigned value right before it. Though I think I'll implement this null-check into client, if I get time.
  2. this is more shady ground. What exactly is this still logged in issue you are talking about? Client crashes, but still remains running in memory?
  3. Zoom change is pretty safe too - there is no current places where grabbed item actually uses mousewheel, so it is safe to exclude it from grabbing. At least until loftar adds some action to it. Other change is not good - it will lead to various bugs.

As for coloring path lines with kin colors - why don't take colors themselves from BuddyWnd.gc? This will make your code much smaller. And colors would actually match with colors from kin list.
User avatar
EnderWiggin
 
Posts: 1069
Joined: Sat Mar 20, 2010 8:23 pm

Re: Ender client and bug fixes

Postby mvgulik » Mon Feb 18, 2013 4:43 pm

EnderWiggin wrote:
  1. xxx
  2. this is more shady ground. What exactly is this still logged in issue you are talking about? Client crashes, but still remains running in memory?

One behavioral example:
- When logging out with ":lo" or the "log off" GUI option in a lag period,
- The client stalls*, like its waiting for some confirmation of the log-off process (that, if the lag period is long enuff, always seems to fail(the confirmation).)
stall: All actions that seem to rely on some server feed back become unresponsive. (other general client actions, like moving or opening gui windows still work.)

- - -

@general:
Note: With the vanilla client I manged to get the client(1) to log-off, while the character/server seems to skip the log-off of the character (seen at client(2)). In this case I supplied some additional walking commands to the character after issuing a "log-off" action.
(Could not get the vanilla client to stall in a reliable way. *1)

--- --- ---

*1) Possible because of insufficient lag :shock: (~65 players), as the Ender client was giving some reproduction problems here to. But I did managed after a few tries to get the character at Client(2) to log-off, while client(1) was still showing the character doing the infamous HnH walk.
mvgulik
 
Posts: 3742
Joined: Fri May 21, 2010 2:29 am

Re: Ender client and bug fixes

Postby Xcom » Tue Feb 19, 2013 7:04 am

Glad it came in handy :)

Regarding the mouse item disable. It might be possible with some clever implementation to add it. The rare few instances the mouse item disable gets confused is often related to flower menus and some rare instances with under lapping behind UI windows, by that I mean the mouse item shows up behind the UI windows (Inventory, Equipment and other windows).

With a simple mouse item disable the mouse item momentarily disappears when right or left mouse item is pushed down and reappears after its lifted. If that mechanic was turned of it might be possible to remove bug with the mouse item docking behind UI windows.

One out of three possible ways to add this is via a slender button similar to the other disable functions. The other is via a quick command like Ctrl + H and possibly the best solution would probably be to connect it to scroll lock and have it enable and disable on the state.

Forcing it to not bugger up might be a bit tricky and might require a few changes in the flower menu mechanics. Somehow flower menus are connected to mouse items. The client might also need a few adjustments to the item handling while the disable is on to not have the client be able to pick up a new item.

Its a bit of a hassle to get it working in a proper way. But I can't say I regretted enabling this mechanic on my own. It comes in handy in allot of instances. I guess till Loft says otherwise it wouldn't hurt trying to get it working.
User avatar
Xcom
 
Posts: 1105
Joined: Wed Dec 14, 2011 1:43 pm

Re: Ender client and bug fixes

Postby Xcom » Sun Mar 03, 2013 12:26 pm

A while back when I was fiddling around with the res files I was confused to not find some of the res of allot of different objects and items. For example pigs, LCs and other world objects, even inventory items were missing. A few days back I was fiddling around with my windows user account folders and found the missing res files.

On Windows 7:

C:\Users\ [your login account on your pc] \.haven

All the res files that were missing from haven-res.jar were all there. I used bowsha's jar extractor and found that it really was all the missing res stuff. Image and whatnot. Maybe it's possible to update your haven-res.jar from that list and make the haven-res.jar complete and updated.

This might come in handy to some people that want to make new updates to the graphics but to me it came a bit late as I badly needed it back when I was fiddling with the neg files.
User avatar
Xcom
 
Posts: 1105
Joined: Wed Dec 14, 2011 1:43 pm

Re: Ender client and bug fixes

Postby mvgulik » Sun Mar 03, 2013 5:07 pm

Xcom wrote:All the res files that were missing from haven-res.jar were all there(haven cache folder).
nitpick: Technically its all the Res files that you needed so far.
Res files for object or items you have never run into yet do normally not show up. Until you run into them in the game of course.

bowsha's jar extractor
?
Boshaw LayerUtil perhaps ?

Maybe it's possible to update your haven-res.jar from that list and make the haven-res.jar complete and updated.
Its possible. (note: *.Jar = *.Zip, and *.cached = *.res)
If I recall correctly you also need to ditch/clear the Jar specific res-file autorisation files. (See "META-INF" folder in Jar file.)
There are also a number of older res files that are not used anymore that could be removed. ("not used" as in "as far as I know".)

--- --- --- --- --- --- --- --- ---

I created a updated "haven-res.jar" file: See topic "Updated "haven-res.jar" file. (...)".
mvgulik
 
Posts: 3742
Joined: Fri May 21, 2010 2:29 am

Re: Ender client and bug fixes

Postby Xcom » Thu Jul 11, 2013 12:15 am

More ender client bug fixes found here:
viewtopic.php?f=4&t=32342

and here:
viewtopic.php?f=4&t=32239

I didn't find the source code but I think the bugs are source code related.
User avatar
Xcom
 
Posts: 1105
Joined: Wed Dec 14, 2011 1:43 pm

Next

Return to The Wizards' Tower

Who is online

Users browsing this forum: Google [Bot] and 1 guest