New client lets you change window size to bigger but it does not work on servUO

Dan(Tasanar)

Dan(Tasanar)

Moderator
SHOW.png

So 640x480 and 800x600

were the old sizes.

They added these 3 bigger ones.

When you pick one of them though it actually makes your screen a little smaller. Is there maybe something in the core that needs to be edited?
 
I wouldn't have thought it would require server-side support, may be worth seeing if they added a new packet though, because the window size would affect the max draw distance, meaning we may have to compensate for a wider view area.
There is a packet for updating the client's draw range, so it may be tied to that.
 
I'm not sure how relevant it is but using the debugger from ultima live when in the old resolutions I get this over and over normally
2017-01-20 12:54:05 [PACKET] Sent CLIENT_UPDATE_RANGE (0xc8)
2017-01-20 12:54:05 [PACKET] Received SERVER_UPDATE_RANGE (0xc8)

the 0xc8 packet seems to correlate with PacketHandlers.cs
line 125 Register(0xC8, 2, true, SetUpdateRange);

and
Packets.cs
line 617 public ChangeUpdateRange(int range) : base(0xC8, 2)


When I switch to the new screen sizes I no longer recieve the CLIENT_UPDATE_RANGE (0xc8) messages.
I don't really know anything about packets so...

*****************************
Update:
I also found in PacketHandlers.cs line 1706
state.Send(ChangeUpdateRange.Instantiate(18));
would now be 24 instead of 18

I think the rest of the issue is from Steam not recognizing the newer resolutions... but you can set the game window size to whatever you want in steam/options, and with the updated range it should work the same.
 
Last edited:
Tasanar said:
View attachment 7739

So 640x480 and 800x600

were the old sizes.

They added these 3 bigger ones.

When you pick one of them though it actually makes your screen a little smaller. Is there maybe something in the core that needs to be edited?
Click to expand...
or possibly razor/steam is causing an issue? have you tried it with both?
what client version is the newest one? I'll update and check it out myself this weekend. would be nice to have a wider view area
 
My first guess is that razor or steam is not compatible with this change. Does this work on OSI using razor or steam?

If that's not it then it's probably something we have to implement.
 
dmurphy said:
My first guess is that razor or steam is not compatible with this change. Does this work on OSI using razor or steam?

If that's not it then it's probably something we have to implement.
Click to expand...
As long as you keep the client resolution to 800x600 Razor will be able to resize the screen to any resolution, if you select any other the client will scale down to 640x480
 
Feeh said:
As long as you keep the client resolution to 800x600 Razor will be able to resize the screen to any resolution, if you select any other the client will scale down to 640x480
Click to expand...

Thanks but that's not the question being asked here :) Good to know though.
 
dmurphy said:
Does this work on OSI using razor or steam?
Click to expand...
i can make a trial acct over the weekend to test since I don't have a real acct that I have to worry about getting banned, or my IP being flagged.

from what I understand they can easily tell if someone is using razor on osi
 
Visam said:
I'm not sure how relevant it is but using the debugger from ultima live when in the old resolutions I get this over and over normally
2017-01-20 12:54:05 [PACKET] Sent CLIENT_UPDATE_RANGE (0xc8)
2017-01-20 12:54:05 [PACKET] Received SERVER_UPDATE_RANGE (0xc8)

the 0xc8 packet seems to correlate with PacketHandlers.cs
line 125 Register(0xC8, 2, true, SetUpdateRange);

and
Packets.cs
line 617 public ChangeUpdateRange(int range) : base(0xC8, 2)


When I switch to the new screen sizes I no longer recieve the CLIENT_UPDATE_RANGE (0xc8) messages.
I don't really know anything about packets so...

*****************************
Update:
I also found in PacketHandlers.cs line 1706
state.Send(ChangeUpdateRange.Instantiate(18));
would now be 24 instead of 18

I think the rest of the issue is from Steam not recognizing the newer resolutions... but you can set the game window size to whatever you want in steam/options, and with the updated range it should work the same.
Click to expand...

making that change does seem to work

upload_2017-1-21_7-21-3.png

but if i change the hue to something more than 18 tiles away my view doesn't update until i'm within 18 tiles of it.
also, that change alone can cause older clients to crash when trying to log in
 
I'm still looking through things I'll add as I find them.

Server\Network\PacketHandlers.cs line 1706
Code: 
state.Send(ChangeUpdateRange.Instantiate(18));

*************
server/Item.cs starting on line line 3511:

Code: 
        public virtual int GetMaxUpdateRange()
        {
            return 18;
        }

        public virtual int GetUpdateRange(Mobile m)
        {
            return 18;
        }

*****
server/Main.cs line starting on line line 32:

Code: 
        static Core()
        {
            DataDirectories = new List<string>();

            GlobalMaxUpdateRange = 24;
            GlobalUpdateRange = 18;
        }

******************
Server/Map.cs has many range values based on #define Map_UseMaxRang. Searching for Map_UseMaxRang will find several places that are defined.
Notes on it are as follows:
Code: 
 * UseMaxRange
*
* When defined, enables a minor update that forces Get*InRange methods to
* use Core.GlobalMaxUpdateRange, when no range is specified.
*
* By default, a constant range of 18 is used however, Core.GlobalMaxUpdateRange
* is usually greater than that with a default value of 24.
*
* This update will allow things such as Effects to be displayed to more players,
* as well as increasing the range of player sight.
*
* The benefits of this update appeal to players who choose to increase the
* dimensions of their game window beyond the client's limits.
* (This can also be beneficial for shards that mainly target the Enhanced client)
*/
//#define Map_UseMaxRange

********************
Server/Mobile.cs Starting on line 5134:

Code: 
                    case MessageType.Yell:
                    m_YellHue = hue;
                    range = 18;
                    break;

*************************
Scripts\Services\New Magincia\Magincia Bazaar\Items\StallMultis.cs starting on line 58:

Code: 
        public override int GetMaxUpdateRange()
        {
            return 18;
        }

        public override int GetUpdateRange(Mobile m)
        {
            return 18;
        }

********************
Server/Utility.cs starting on line 704:

Code: 
		public static bool InUpdateRange(Point3D p1, Point3D p2)
		{
			return (p1.m_X >= (p2.m_X - 18)) && (p1.m_X <= (p2.m_X + 18)) && (p1.m_Y >= (p2.m_Y - 18)) &&
				   (p1.m_Y <= (p2.m_Y + 18));
		}

		public static bool InUpdateRange(Point2D p1, Point2D p2)
		{
			return (p1.m_X >= (p2.m_X - 18)) && (p1.m_X <= (p2.m_X + 18)) && (p1.m_Y >= (p2.m_Y - 18)) &&
				   (p1.m_Y <= (p2.m_Y + 18));
		}

		public static bool InUpdateRange(IPoint2D p1, IPoint2D p2)
		{
			return (p1.X >= (p2.X - 18)) && (p1.X <= (p2.X + 18)) && (p1.Y >= (p2.Y - 18)) && (p1.Y <= (p2.Y + 18));
		}

******************
Scripts\Items\Internal\MorphItem.cs starting on line 58:

Code: 
        [CommandProperty(AccessLevel.GameMaster)]
        public int InRange
        {
            get
            {
                return this.m_InRange;
            }
            set
            {
                if (value > 18)
                    value = 18;
                this.m_InRange = value;
            }
        }
        [CommandProperty(AccessLevel.GameMaster)]
        public int OutRange
        {
            get
            {
                return this.m_OutRange;
            }
            set
            {
                if (value > 18)
                    value = 18;
                this.m_OutRange = value;
            }
        }

******************
Scripts\Items\Internal\WarningItem.cs
has the following on lines 19, 32, 79:

Code: 
            if (range > 18)
                range = 18;

******************
Scripts\Gumps\HouseGump.cs line 389

Code: 
            if (sign == null || from.Map != sign.Map || !from.InRange(sign.GetWorldLocation(), 18))

******************
Scripts\Gumps\HouseGumpAOS.cs line 831

Code: 
            if (sign == null || from.Map != sign.Map || !from.InRange(sign.GetWorldLocation(), 18))
[doublepost=1485026014][/doublepost]The list above is all of the places I found besides the two below of note that may need changed but I'm unsure so I'll post them here.

Scripts\Services\Virtue Artifacts\VirtueArtifactsSystem.cs line 47

Code: 
            if (!Enabled || pm == null || bc == null || !CheckLocation(bc) || !CheckLocation(pm) || !killer.InRange(victim, 18)

*****************
Scripts\Mobiles\Normal\Yamandon.cs line 182

Code: 
                if (target == null || !target.InRange(this, 18))
 
Last edited:
i couldn't get into the EA servers using steam but i did with razor.
connecting through razor made it so i couldn't change the game window size.
and I verified that it worked when connecting with just the client directly.

So this definitely seems to be a razor issue, and most likely the same issue with steam
 
All instances referring to hard-coded "18" values should be replaced with Core.GlobalUpdateRange.
All instances referring to hard-coded "24" values should be replaced with Core.GlobalMaxUpdateRange.

With the latest client publish, we will need to increase 24 to 32 to avoid issues with detecting and sending MobileIncoming packets when moving and such. It has to be relative to the Mobile's update range too. If the server's draw range remains at 24 and the client's max range is set to 24, then there is no "no-man's land", which is effectively an area around the center point that's like a ring or doughnut - anything that falls into this area is either updated or removed from the screen.

There will need to be some extensive testing with this as well as significant core mods and I hope to implement them soon if no one else is officially working on it.

The ore research and data the community can provide, the better!
 
I made the changes you suggested to all of the files I listed above a few days ago. It seems to work fine for me at least but... I'm not much of a test pool lol.
 
I'll download latest repo and make those changes as well, when I can, but may take me a while. RL is taking up a lot more time than usual right now.
 
New real UO client out. Bug fixes.

Classic Client Updates
  • Fixed an issue where approaching names would not display properly in the Classic Client.
  • Resolved a crash in the Classic Client when selecting a full screen resolution that is less than the gameplay window size.
  • Resolved an issue where some block tiles were not the correct height, which could cause collision and rubber banding issues.
  • Fixed issue where the evening gown was not displaying the correct gump art.
  • The circle of transparency is now centered when game window size is changed.
http://uo.com/wiki/ultima-online-wiki/publish-notes/publish-96/
 
The new update makes doors, spawners, and other non static things not update properly for me if I run around.
 
did you increase Core.GlobalMaxUpdateRange to 32?

sounds like that might be the issue, items coming into view aren't updated before you see them.

actually, I remember changing one of these in item.cs

  1. public virtual int GetMaxUpdateRange()
  2. {
  3. return 18;
  4. }

  6. public virtual int GetUpdateRange(Mobile m)
  7. {
  8. return 18;
  9. }
Click to expand...

to 24 and that allowed me to see items outside of 18 tiles update

overall this is going to take a lot of tweaking to get just right
 
I did all of the range changes I posted earlier in this thread the day I posted them, everything worked fine up until I patched a little while ago.

I changed them the way Voxpire had said to using Core.GlobalUpdateRange and Core.GlobalMaxUpdateRange. I set them to 24 and 32

***********
UPDATE:
I moved them back down to 18/24 and everything updates properly again. I'll do some testing with other numbers.

************
UPDATE 2
After trying lots of variations the only settings I could get to work was 18/24 anything larger made items not show up properly. I'd have to assume it's because of not being able to set the game play window size above 800x600 because of limitations in UOSteam, but I'm not really sure just a guess.
 
Last edited:
a problem i'm finding is that if i set server.item.GetUpdateRange more than 18 items won't update.
if i go more than 18 tiles away and back the item doesn't show up anymore
 
Without being able to use the clients new game window sizes I'm not really sure how to test it properly. GetUpdateRange could changed based on what resolution your using, but because steam doesn't recognize it, it doesn't work.
 
only thing i can think of after looking over all this information is finding a way to unlock the client so that people can set there address and just use the client without the loaders
 
you mean remove encryption? UORice is the only program that I can think of. There may be another one though.

The issue we're trying to resolve though is being able to see more than 18 tiles away from the character. It should now being 24 tiles.
Without that increase, the larger playing window is mostly useless ( but I still force it to be bigger with steam/razor )
 
Visam said:
Without being able to use the clients new game window sizes I'm not really sure how to test it properly. GetUpdateRange could changed based on what resolution your using, but because steam doesn't recognize it, it doesn't work.
Click to expand...
I just leave the client settings at one of the original ones and then force the window size bigger via steam.
No matter when resolution you're using, the client will still see the same distance. Resolution difference is just to account for size of the screen you're playing on.
Back when UO first came out, 10" - 15" CRT Monitors were the norm.
 
I "think" it would accept the extended ranges if the larger game window sizes could be set in game. I think it's using different ranges for different game window sizes, but razor/steam doesn't recognize it and sets it back down so we don't see it and can't test it. I know little to nothing about packet snooping though so I could be completely wrong. I just know it was working fine before the newest "fix" update and now it doesn't. I also know the packet info from UOLive's debug window has changed on the server I have that uses it from before the newest one.

This is all just my "assumptions" from things I've tried, I could be totally off base.
 
Last edited:
In previous clients (and in the last one) when just setting still or moving around every second or two I would see:

2017-01-20 12:54:05 [PACKET] Sent CLIENT_UPDATE_RANGE (0xc8)
2017-01-20 12:54:05 [PACKET] Received SERVER_UPDATE_RANGE (0xc8)

the 0xc8 packet seems to correlate with PacketHandlers.cs
line 125 Register(0xC8, 2, true, SetUpdateRange);

Now instead of that I get:
2017-01-27 02:48:50 [PACKET] sent CLIENT_EXTENDED_UNKNOWN_24_(0x24)

the 0x24 packet seems to correlate with PacketHandlers.cs
line 154 RegisterExtended(0x24, false, UnhandledBF);

Also of note... as long as I leave the update ranges the old default on the server everything still works fine as far as playing goes even with it the (0x24) packets.
 
Last edited:
The UO client had another patch after the info in this thread, as far as I can tell it is all working fine. You can switch resolutions in game.
 
Tasanar said:
Correct! As long as you are using the latest client of real UO, you can now adjust just fine.
Click to expand...
Visam said:
The UO client had another patch after the info in this thread, as far as I can tell it is all working fine. You can switch resolutions in game.
Click to expand...
Does anything have to be changed for the render distance? Or just download latest if on an older repo? I notice things still have difficulty if not static staying loaded and disappearing.
 
Last edited:
zerodowned said:
a problem i'm finding is that if i set server.item.GetUpdateRange more than 18 items won't update.
if i go more than 18 tiles away and back the item doesn't show up anymore
Click to expand...

Did you recompile the Core after updating Item.cs?
 
This issue should have been resolved a few weeks ago. We had a few minor hiccups, but for the most part, is working as it does on EA.
 
You must log in or register to reply here.
Back