RunUO Community
This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
I solved the 4.0.10 Stuck On Death problem!!! (Admins, please read!)
- Thread starter Lysdexic
- Start date
- Status
The devs will have it fixed with the next RunUO release, I assume. Other members of the community have posted temporary fixes for the problem that will hold you over until the next release.Orngrimm said:Hm... I just saw this thread... Looks like someone ressed it today again
If , why it is not fixed ATM?
We did a temp fix on our shard by just editting out a few lines in playermobile.
This well stop the freeze on death bug, of course it will make ressing a little annoying because if you run up to an ankh it will open and close the gump almost the same time, but if you don't move and double click it it will reopen. All this does is stop the freeze if the gump is open issue, by not checking to see if the gump is open and returning a false. If you move it will close the gump, so you can't drag the gump around on your ghost and ress anywhere. Its a temp fix until the runuo devs fix the issue.
P.S. Its possible to add a m.frozen = true; in ressurectiongump.cs, when the gump opens and when you close the gump m.frozen = false; or something similar, that way you don't need to have a gump check in playermobile, in order to make sure the player isn't moving.
Code:
public override bool Move( Direction d )
{
NetState ns = this.NetState;
if ( ns != null )
{
GumpCollection gumps = ns.Gumps;
for ( int i = 0; i < gumps.Count; ++i )
{
if ( gumps[i] is ResurrectGump )
{
//if ( Alive )
{
CloseGump( typeof( ResurrectGump ) );
}
/*else
{
SendLocalizedMessage( 500111 ); // You are frozen and cannot move.
return false;
}*/
}
}
}This well stop the freeze on death bug, of course it will make ressing a little annoying because if you run up to an ankh it will open and close the gump almost the same time, but if you don't move and double click it it will reopen. All this does is stop the freeze if the gump is open issue, by not checking to see if the gump is open and returning a false. If you move it will close the gump, so you can't drag the gump around on your ghost and ress anywhere. Its a temp fix until the runuo devs fix the issue.
P.S. Its possible to add a m.frozen = true; in ressurectiongump.cs, when the gump opens and when you close the gump m.frozen = false; or something similar, that way you don't need to have a gump check in playermobile, in order to make sure the player isn't moving.
MeddeMarigald
Wanderer
a wild guess
Ive been on a shard that whenever you just died even with no gump around you simply froze and only logout logon would help.
Im quite a noob on this but maybe its not just on the gumps, maybe it has to do with your ghost appearing over the body, I mean, maybe the layer in which the body is now laid somehow messes with the tile the ghost appears. An invalid walking terrain perhaps?
I noticed also that this happens more frequently on heavily customized shards.
If my mumbling has any logic it could be avoided by spawning the ghost to a neighbor tile, of course it should be an unblocked one.
well, here is my 2 cents, I hope it helps the real specialists to cast a light on this, its really very annoying.
Thanx
Ive been on a shard that whenever you just died even with no gump around you simply froze and only logout logon would help.
Im quite a noob on this but maybe its not just on the gumps, maybe it has to do with your ghost appearing over the body, I mean, maybe the layer in which the body is now laid somehow messes with the tile the ghost appears. An invalid walking terrain perhaps?
I noticed also that this happens more frequently on heavily customized shards.
If my mumbling has any logic it could be avoided by spawning the ghost to a neighbor tile, of course it should be an unblocked one.
well, here is my 2 cents, I hope it helps the real specialists to cast a light on this, its really very annoying.
Thanx
MeddeMarigald said:
it is because of the resurrection gump even when person closes it sometimes it doesn't get removed from the gumpcollection array so on death it checks to see if you have resgump during movement..... even if it is not on your screen the gumpcollection still may have it so its waiting for you to use gump before your allowed moving..... many quick fixes have been proposed and found around the forums
I found this fix simpler I did have it posted but post is gone so here is just the resgump fix I proposed found easier to just check onbeforedeath method for a resgump and remove it if there after all there shouldn't be no resurrection gump at death time lol
Code:
public override bool OnBeforeDeath()
{
////////////////////////Added to remove resurection gumps before death if any///////////////
GumpCollection gumps = NetState.Gumps;
for (int i = 0; i < gumps.Count; ++i)
{
Gump gump = gumps[i];
if (gumps[i].GetType() == typeof(ResurrectGump))
NetState.RemoveGump(i);
}
////////////////////////Added to remove resurection gumps before death if any///////////////
m_InsuranceCost = 0;
m_InsuranceAward = base.FindMostRecentDamager( false );
if ( m_InsuranceAward is BaseCreature )
{
Mobile master = ((BaseCreature)m_InsuranceAward).GetMaster();
if ( master != null )
m_InsuranceAward = master;
}
if ( m_InsuranceAward != null && (!m_InsuranceAward.Player || m_InsuranceAward == this) )
m_InsuranceAward = null;
if ( m_InsuranceAward is PlayerMobile )
((PlayerMobile)m_InsuranceAward).m_InsuranceBonus = 0;
return base.OnBeforeDeath();
}My tries with this problem
Well, first off, i'm not an admin,but a programmer.But once i checked this problem.
The previous post is the right solution:remove the container from the container list.
If you do a search on the source code for the server, looking for where the containers are removed from the list, you'll find that they're called from the core, when a certain message is received.
If an action is taken in the client to close a gump, that message is sent.If the server asks the client to close the gump,the message is *not* sent.
That message looks like an ack from the client telling the server the gump has been closed in the client.
If you add a line in the core (sorry,dont have the core source, and cant find it in the web) so the server prints a line when the "gumpclosed message" is received,you can check it by yourself.(core recompilation needed)
Example of this is the runebook problem:
Using 2 runebooks, make 2 tests:
1) Open first.Close it.Open second.Close it.Add rune in the first.It works well.
2)Open first.Dont close it, but open second.Close the second.Add a rune on the first.Will tell you it's open.
Thats because in the first case, the client asks the server to close the gump.
In the second case, is the server who asks the client to close the first gump (first runebook), and the client does, but dont send back the "ack" message to the server.So it doesnt remove it from the gump list.
Looks like they decided that message was not important, and, in fact, maybe it's not.If the server decides to close a gump, doesnt need any message back from the client.
But RunUo relies on that message to come back from the client to actually remove the gump.
--
So, the fix for it is to remove the gump from the list if you know that the gump has to be removed from the server.This is, if you know that if there is an open runebook, you need to close it before open another, send the CloseGump message, *and* remove it from the list.
This would affect,at least, at all those gumps that were supposed to be "replaced" when opening a container of the same type.
The way to replicate the problem with the res gump, i was not able to tell, but the problem is the same.
Well, first off, i'm not an admin,but a programmer.But once i checked this problem.
The previous post is the right solution:remove the container from the container list.
If you do a search on the source code for the server, looking for where the containers are removed from the list, you'll find that they're called from the core, when a certain message is received.
If an action is taken in the client to close a gump, that message is sent.If the server asks the client to close the gump,the message is *not* sent.
That message looks like an ack from the client telling the server the gump has been closed in the client.
If you add a line in the core (sorry,dont have the core source, and cant find it in the web) so the server prints a line when the "gumpclosed message" is received,you can check it by yourself.(core recompilation needed)
Example of this is the runebook problem:
Using 2 runebooks, make 2 tests:
1) Open first.Close it.Open second.Close it.Add rune in the first.It works well.
2)Open first.Dont close it, but open second.Close the second.Add a rune on the first.Will tell you it's open.
Thats because in the first case, the client asks the server to close the gump.
In the second case, is the server who asks the client to close the first gump (first runebook), and the client does, but dont send back the "ack" message to the server.So it doesnt remove it from the gump list.
Looks like they decided that message was not important, and, in fact, maybe it's not.If the server decides to close a gump, doesnt need any message back from the client.
But RunUo relies on that message to come back from the client to actually remove the gump.
--
So, the fix for it is to remove the gump from the list if you know that the gump has to be removed from the server.This is, if you know that if there is an open runebook, you need to close it before open another, send the CloseGump message, *and* remove it from the list.
This would affect,at least, at all those gumps that were supposed to be "replaced" when opening a container of the same type.
The way to replicate the problem with the res gump, i was not able to tell, but the problem is the same.
Seanchen.net
Wanderer
Cyndrz said:
Any code that fixes the problem for 4.0.10 would fix the problem for any versions and including 4.0.10
- Status