 |
 |
|
|
| Author |
Message |
Rogdush
Joined: 10 Feb 2006
Posts: 21
|
 Posted: Sat Sep 02, 2006 5:58 pm Post subject: MoveObjectToLocation realm-to-realm problem |
 |
|
Hi, I've discovered a little problem with MoveObjectToLocation
When I try to move item from ilshenar, location 1212, 1122, -25, 2 to 6000, 1200, 0, 0 I've got:
error{ errortext = "Location (6000,1200,0) is out of bounds" }
like MoveObjectToLocation is comparing bound of ilshenar to location in britannia. When I try to move at 1000, 1200,0,0 its no problem.
The same thing occurs when item is equipped or in backpack of a person in ilshenar realm.
When my char is in brit realm, there is no problem at all ofc.
Second thing, when item in backpack or item equiped is moved far away from client location (not seenable by client) there is no update sent to him, so he thinks that he still got item, but that item is not accessible. So, this is only visual aspect. In backpack, problem can be fixed by reopening it. When item is equipped, there is not much u can do (except moving original item in location seenable by client, so he can learn where the proper location of an item is)
Edit: one more thing. MoveObjectToLocation do not send current lightlevel, its always set to 0. This is a little odd problem with lightlevel. I fixed it manually, but I need to set different lightlevel from current (i mean, last set) client lightlevel, or else it will ignore it. Is it pol fault? or client? dunno.
After all, I need to do this, to restore current light level:
who.setlightlevel(31, 1);
who.setlightlevel(current_level, 1);
But.. weather state (rain/snow) is properly updated here.
Another thing, are seasons. Hm.. but there is no implementation for seasons, is it? I use packets to change season, so I need to send it always when client is moving from realm to realm. The same problem.
My sugesstion is to create a function SetClientSeason, which would remember current season should client have and update it on moving, or global season state like SetSeason. |
|
 |
|
|
|
|
| Author |
Message |
MuadDib
POL Developer
Joined: 13 Feb 2006
Posts: 830
Location: Indiana, USA
|
| Posted: Sat Sep 02, 2006 7:06 pm Post subject: Re: MoveObjectToLocation realm-to-realm problem |
|
|
| Rogdush wrote: | | When I try to move item from ilshenar, location 1212, 1122, -25, 2 to 6000, 1200, 0, 0 |
Ishlenar is not that big. Check your realms.cfg for the Ishlenar map for it's dimensions. Map sizes are unfortunately hardcoded in the client.
| Rogdush wrote: |
Second thing, when item in backpack or item equiped is moved far away from client location (not seenable by client) there is no update sent to him, so he thinks that he still got item, but that item is not accessible. So, this is only visual aspect. In backpack, problem can be fixed by reopening it. When item is equipped, there is not much u can do (except moving original item in location seenable by client, so he can learn where the proper location of an item is) |
I will look into this tonight if I get time. Doing some optimization work, but should have time I hope, to get it in before next beta. Expect this in the 096.3 release too, since this would be a bug in 096 core too.
| Rogdush wrote: |
Edit: one more thing. MoveObjectToLocation do not send current lightlevel, its always set to 0. This is a little odd problem with lightlevel. I fixed it manually, but I need to set different lightlevel from current (i mean, last set) client lightlevel, or else it will ignore it. Is it pol fault? or client? dunno.
After all, I need to do this, to restore current light level:
who.setlightlevel(31, 1);
who.setlightlevel(current_level, 1);
But.. weather state (rain/snow) is properly updated here.
Another thing, are seasons. Hm.. but there is no implementation for seasons, is it? I use packets to change season, so I need to send it always when client is moving from realm to realm. The same problem.
My sugesstion is to create a function SetClientSeason, which would remember current season should client have and update it on moving, or global season state like SetSeason. |
Same here, this would also be a 096.x bug, and as thus, will try to work on this soon for both 96 and 97. I can't promise I will have these before the next releases, but will do what I can. |
|
|
|
|
|
|
|
|
