SUPER BUG

Apocalyptic
Posts: 7
Joined: Sun Apr 26, 2009 1:42 pm

SUPER BUG

Post by Apocalyptic » Tue May 19, 2009 7:25 am

I am going to post this in here just because of how big this bug really is. I keep making triggers and it works fine for awhile and then all of a sudden I will log back in, without creating anything and changing nothing in my routine and when I come back each trigger has 3 duplicates or more and one response in my user windows will display itself 2-3x as a result. This is silly. This MUST be a bug. I am not telling these triggers and scripts to clone themselves 3-4x after I log out or login. This is silly. Can this be fixed please? This is a HUGE bug. Got to be! I got to believe others are encountering this as well. This is just ridiculous!

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: SUPER BUG

Post by Heiko » Tue May 19, 2009 7:51 am

There is no such bug. Either you illegally have more instances of Mudlet connected to the same profile or your Mudlet binary is totally broken in which case you should report what you are using.

Don't use the ubuntu 64 bit ppa. It's totally broken.

Apocalyptic
Posts: 7
Joined: Sun Apr 26, 2009 1:42 pm

Re: SUPER BUG

Post by Apocalyptic » Tue May 19, 2009 4:37 pm

Not using that. This bug has been around since I started using it. I have had 3 different versions now? I got the pre-4 one. It did it before this one. I doubt that all of my binaries have been broken. This one installed with no problems in the messaging unlike the last one. Sometimes it happens and sometimes it does not. Seems to happen more often if I click the save button and save profile after every little change that I make. Perhaps saving profile multiple times sets it off? If that is the case, then it should not be doing that.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: SUPER BUG

Post by Heiko » Tue May 19, 2009 5:16 pm

I remember that you were on ubuntu. This is not supposed to happen at all unless you illegally use more than one instance of mudlet simultaneously with the same profile. If you want 2 simultaneous connections, make 2 different profiles and use one for each connection.
If you don't do this, your binary is broken. If you are on ubuntu 64 you have to wait for us to sort out the ubuntu 64 bit problems. Ubuntu 32 bit is no problem as well as all other distros if you compile mudlet yourself.

Caled
Posts: 399
Joined: Thu Apr 09, 2009 4:45 am

Re: SUPER BUG

Post by Caled » Wed May 20, 2009 1:30 am

Its happened to me as well, Heiko. Only very rarely, and in honesty, I don't know what you mean when you say: "illegally use more than one instance of mudlet simultaneously with the same profile". Is it possible to do this by mistake? I've never -tried- to have more than one instance of mudlet open under any circumstances.

User avatar
Vadi
Posts: 4728
Joined: Sat Mar 14, 2009 3:13 pm

Re: SUPER BUG

Post by Vadi » Wed May 20, 2009 2:07 am

Yes, it's very possible - atm you can launch more than one instance of Mudlet and they don't know which profile is loaded. But this is sounding like there's something else going on.

Parnakra
Posts: 35
Joined: Tue Apr 21, 2009 10:48 am

Re: SUPER BUG

Post by Parnakra » Wed May 20, 2009 8:22 am

I also have this problem. It always happens when I first start up Mudlet, connect to a mud (Achaea, in this case) - then QQ from that mud, leave Mudlet open and just connect again via the dialog.

It could be interpreted as having two instances connected at once, but I feel like the QQ'ing should properly close/disconnect the first, or there should be a disconnect button in the connect dialog.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: SUPER BUG

Post by Heiko » Wed May 20, 2009 8:29 am

What do you mean by "QQ"?

Parnakra
Posts: 35
Joined: Tue Apr 21, 2009 10:48 am

Re: SUPER BUG

Post by Parnakra » Wed May 20, 2009 8:34 am

Quiting the mud through the ingame QQ-command. This causes me to disconnect and mudlet giving the following message:

Code: Select all

System Message:
Socket got disconnected. The remote host closed the connection
If I then return to the connect dialog and select the same profile, the information label appears telling me the profile is currently loaded, I can't change any parameters and should disconnect it if I want to do so. However, I believe there's no way of disconnecting a profile other than quitting and reopening Mudlet?

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: SUPER BUG

Post by Heiko » Wed May 20, 2009 9:04 am

Caled wrote:Its happened to me as well, Heiko. Only very rarely, and in honesty, I don't know what you mean when you say: "illegally use more than one instance of mudlet simultaneously with the same profile". Is it possible to do this by mistake? I've never -tried- to have more than one instance of mudlet open under any circumstances.
It's the classical dilemma between good features and bad features. On the one hand, it's very nice to be able to be able to run multiple instances of Mudlet if you have more than one screen, on the other hand it makes it difficult to detect what profiles are being used in the "other" instances. We are a multi platform project so we can't easily use OS specific hacks. There are several ways of enforcing the "rules" that I have explained in great length in the manual (that's why i call it "illegal").
1.) using profile specific lock files: This is the classical solution that Mozilla, Thunderbird and other programs use. The big disadvantage of this solution is that it can get terribly annoying for the user if the application crashes, power losses occur or other circumstances cause stale lock files. What do we do in such a case? Ask the user to manually delete it like Firefox/Moziila or pop up a message box asking him if the profile should be freed again which could again cause the same problems if people remove the lock file to get the same profile connected twice.

2.) using some sort of server based approach: The technical side is different, but the resulting problems are the same as in solution 1.

As you can see, there is no perfect solution on the horizon, and this is the reason why I haven't taken on this issue so far and leave it to the user to take care that this doesnt happen. As there is no data loss at stake, it doesn't really matter. And if it happens by accident - which undoutedly will happen at times - users can use the profile history feature in the connection dialog to revert the profile to an older version without doublicates.

Suggestions & comments are welcome.

Post Reply

Who is online

Users browsing this forum: No registered users and 12 guests