[RunUO 2.0 RC1] Courageous True Line of Sight

[Cheetah2003]

Sadly, another crash, just after discovering the Razor thing. What did I do? I have an object called a StaffOrb which toggles my AccessLevel between Owner and Player. I double clicked it and took 2 steps and....

RunUO - [www.runuo.com] Version 2.0 [SVN 75], Build 2437.34841
Core: Running on .NET Framework Version 2.0.50727
Core: Running with arguments: -service
Using: [CoreScripts] Version 1.2.934.34926
Scripts: Compiling C# scripts...done (cached)
Scripts: Compiling VB.NET scripts...no files found.
Scripts: Verifying...done (3816 items, 755 mobiles)
XMLServerOptions.cs -- Version 1.0
Loading configuration file Data/ServerConfig.xml...
Configuration loaded!
FSATS XML Configuration -- Version 1.0
Loading FSATS configuration from Data/FSATSConfig.xml...
FSATS configuration loaded.
ACC Registered: Server.ACC.CM.CentralMemory
ACC Registered: Server.ACC.PG.PGSystem
Regions: Loading...done
World: Loading...done (237 items, 1 mobiles) (1.13 seconds)

----------
Loading ACC...
 - Loading Central Memory   - Done.
 - Loading Public Gates   - Done.
Done in 0.1 seconds.
----------

Serverlist.cs: 2.1
Acquiring IP address from: http://www.ipaddy.com/
Internet IP: 71.209.72.199 (http://www.ipaddy.com/)
Account Purge v1.0 Initialized -- Next Purge time in: 08:24:41.7456250
Address: 127.0.0.1:2693
Address: 10.0.0.2:2693
Client: 127.0.0.1: Connected. [1 Online]
Login: 127.0.0.1: Valid credentials for 'cheetah'
Client: 127.0.0.1: Connected. [2 Online]
Client: 127.0.0.1: Disconnected. [1 Online] [cheetah]
Login: 127.0.0.1: Account 'cheetah' at character list
### LOS System: Configuration system initializing
LOS: Loading tiles.
LOS: There appeared to be NO WHITELISTED TILES defined in the configuration file!
LOS: Loading tiles.
Error:
System.NullReferenceException: Object reference not set to an instance of an object.
   at Server.Mobiles.PlayerMobile.CanSee(Mobile m) in d:\source\c#\RunUO Core Scripts\RunUO Core Scripts\Mobiles\PlayerMobile.cs:line 3133
   at Server.Mobile.SendEverything() in d:\source\c#\RunUO\RunUO\Mobile.cs:line 6716
   at Server.Mobile.set_AccessLevel(AccessLevel value) in d:\source\c#\RunUO\RunUO\Mobile.cs:line 6168
   at Server.Items.Staff.StaffOrb.SwitchAccessLevels(Mobile from) in d:\source\c#\RunUO Core Scripts\RunUO Core Scripts\Customs\Items\StaffOrb.cs:line 139
   at Server.Items.Staff.StaffOrb.OnDoubleClick(Mobile from) in d:\source\c#\RunUO Core Scripts\RunUO Core Scripts\Customs\Items\StaffOrb.cs:line 81
   at Server.Mobile.Use(Item item) in d:\source\c#\RunUO\RunUO\Mobile.cs:line 4110
   at Server.Network.PacketHandlers.UseReq(NetState state, PacketReader pvSrc) in d:\source\c#\RunUO\RunUO\Network\PacketHandlers.cs:line 1310
   at Server.Network.MessagePump.HandleReceive(NetState ns) in d:\source\c#\RunUO\RunUO\Network\MessagePump.cs:line 238
   at Server.Network.MessagePump.Slice() in d:\source\c#\RunUO\RunUO\Network\MessagePump.cs:line 108
   at Server.Core.Main(String[] args) in d:\source\c#\RunUO\RunUO\Main.cs:line 502
Crash: Backing up...done
Crash: Generating report...done

[Courageous]

I went line 3133 in PlayerMobile.cs from the 1.0B release. It appears that you have a different PlayerMobile.cs than I do. Please PM me yours, and I will diagnose. You'll be glad to know that in the next release, you won't be required to twiddle with your PlayerMobile at all. In talking this over in the chat channel, I realized that many people have modded PlayerMobiles, but most don't have a modded Mobile. So I found a way to do it all in Mobile, leaving PlayerMobile intact. In the next release you'll leave your PlayerMobile as-is.

Be that as it may, line 3133 doesn't look like a good line to me in my PlayerMobile (it's a line between functions). Please send me yours. I'll happily diagnose and repair this error if I can, up to and including running your Server and any source you care to have me run...

C//

p.s. I may fiddle around with Razor to see if how it goes there. I know that this is a commonly used add-on.

p.p.s. possibly if this is a world that already has a save state, there might be something I didn't do right, although I do replace the code in my own world quite frequently.

[Cheetah2003]

Originally Posted by Courageous

p.s. I may fiddle around with Razor to see if how it goes there. I know that this is a commonly used add-on.
[/i]

I strongly recommend you try it with Razor to see what I was experiencing. Be sure to turn off the client's built in 'Show names of approaching creatures/people' and turn on the one in Razor instead.

It's pretty wild.

As far as my PlayerMobile.cs. Please don't hurt me, but I think that second time I put the patch in, I forgot to copy over MaybeInvalidateLos() from yours to mine. This time I triple checked all the PlayerMobile diffs and think I got it right, will letcha know after it compiles and I tinker with it.

Edit...
Yeah, that was it. Stupid me. It's working *GREAT* now. Thanks for all your support!!

[Cheetah2003]

New crash...

Error:
System.ArgumentException: An item with the same key has already been added.
   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at Server.Mobiles.PlayerMobile.MaybeInvalidateLos() in d:\source\c#\RunUO Core Scripts\RunUO Core Scripts\Mobiles\PlayerMobile.cs:line 3156
   at Server.Mobile.SetLocation(Point3D newLocation, Boolean isTeleport) in d:\source\c#\RunUO\RunUO\Mobile.cs:line 8903
   at Server.Mobiles.PlayerMobile.SetLocation(Point3D loc, Boolean isTeleport) in d:\source\c#\RunUO Core Scripts\RunUO Core Scripts\Mobiles\PlayerMobile.cs:line 1444
   at Server.Mobile.Move(Direction d) in d:\source\c#\RunUO\RunUO\Mobile.cs:line 3170
   at Server.Mobiles.PlayerMobile.Move(Direction d) in d:\source\c#\RunUO Core Scripts\RunUO Core Scripts\Mobiles\PlayerMobile.cs:line 1339
   at Server.Network.PacketHandlers.MovementReq(NetState state, PacketReader pvSrc) in d:\source\c#\RunUO\RunUO\Network\PacketHandlers.cs:line 1395
   at Server.Network.MessagePump.HandleReceive(NetState ns) in d:\source\c#\RunUO\RunUO\Network\MessagePump.cs:line 238
   at Server.Network.MessagePump.Slice() in d:\source\c#\RunUO\RunUO\Network\MessagePump.cs:line 108
   at Server.Core.Main(String[] args) in d:\source\c#\RunUO\RunUO\Main.cs:line 503
Crash: Backing up...done
Crash: Generating report...done

I tamed something and then added it to a BOD (making it disappear.) and it crashed. Attached my PlayerMobile.cs to this post.

[Courageous]

Yeah, that was it. Stupid me.

Nah. Not stupid. Stupid me for giving you PlayerMobile deltas. That's why you don't have to do that in the next release, this sort of stuff is bound to happen.

Anyway, the last crash you saw is my error. Your line :3156 should be removed entirely (just comment it out so that our line#'s will match if you have another error). I fixed this a bit back in my own version.

I've also figger'd out what's happening in your Razor. It's the very same thing that's happening in my client when I go around obstructions, it just manifests differently in Razor. It's a packet type problem. The mod I made to the core was modded in an area of code where mobs don't come in and out of existence inside the range perimeter. With them coming into view at a shorter range, a different type of packet must be sent: MobileUpdate.

C//

p.s., those conditional checks you're putting in match something similar I'm doing in the next release or two, FYI.

[LordHogFred]

Just realised a possible problem.
Some people are using the player statues script but with this the statues wouldn't show up behind walls despite the fact that they are supposed to be statues not mobiles.
Would it be possible to do a Whitelist for mobiles where any mobiles included in the list are uneffected by LOS, that way it would be possible to add things such as the statues or possibly even have a Whitelist property check so anyone with staff status can be seen by any char when visible.
Just a suggestion .

[Courageous]

Q: Would it be possible to do a Whitelist for mobiles where any mobiles included in the list are uneffected by LOS?

A: If the mobile were of a particular class or otherwise discretely identifiable, it would be possible. Although I don't know why you want to go out of your way to see something that is out of sight. The next release will offer a config option to deny LOS to items...

Q: ...check so anyone with staff status can be seen by any char when visible...

A: Staff members are not LOS'd.

[Kirin-Man]

In my fav.s I will deffiently be using this system.
Thank-you!

[Courageous]

The fix for the updating mobile title problem, which some users encounter using Razor, and in any case happens when mobs pop in and out of site, has turned out to be a tad trickier than I anticipated. An early easy fix only served to remove titles altogether, which I don't think would work in the long run. I'm having to create a new data structure to do the right thing, and will take until the weekend.

I think I commented on this already, but the next release will not require an (obnoxious) PlayerMobile mod. The mod is strictly in the core, which is less likely to conflict with things other shard owners have integrated. Users who have an unmodded RC1 core will be able to simply drop-in replace the core mod files and recompile. Voila.

The next release will be 1.1 beta. It has optional support for LOS for items as well as LOS for non-player mobs. These settings may impact performance, however, I'll leave the decision to the shard-owner.

There are also some additional commands included: a couple to turn the system on or off at run time, another to reset the cache and all of the arrays, reread the config file, and restart the system entirely.

The 1.1 alpha is probably more stable than the 1.0 beta. If your using the system and want support, feel free to come over to the chat channel.

Expect an update this weekend.

For those readers sending nice karma messages, thank you for all your supporting words.

C//

[RavonTUS]

Greetings,

I finally had a few moments to code this and I get a weird problem.

First, I am using RunUO v2 r83 (from the SVN). Thanks to your fine notes, it was easy to copy sections of code from LOS1.1a. I am also using just the client 5.0.4c (no Razor).

Here is the problem...The server starts normally and loads the world file just fine.

When I log into the world, I can see my NPC mobiles. If I walk away from them, so that they are no longer on the screen, and then return to where they were, they are gone. I can still hear the cows mooing, but don't see them. This seems to happen on every facet.

Any ideas?

-Ravon

[Courageous]

I'll take a peak at what you have. Do you walk all the way away and then they don't come back, or you go around a corner, they go out of LOS, and don't come back?

*peeking: whoa, some areas are a lot different than mine, is this in SVN, or do you have a modded core yourself?*

*looking some more: on line 7920 you comment out the body of CanSee(object), but this isn't right. You need to leave CanSee(object) in, and apply the comments out and deltas to CanSee(Item) and CanSee(Mobile) independently*

*I will do an SVN checkout and check some other stuff for you, please wait*

I do happen to know that someone else fiddling around with SVN latest was having some troubles. I suppose that your way might be the right way: perhaps anyone likely to be willing to try a core mod is also likely to have SVN latest. That's not the way I went, though.

How many people here think it should be against latest instead of RC1?

C//

[Erica]

Originally Posted by Courageous

I'll take a peak at what you have. Do you walk all the way away and then they don't come back, or you go around a corner, they go out of LOS, and don't come back?

I do happen to know that someone else fiddling around with SVN latest was having some troubles. I suppose that your way might be the right way: perhaps anyone likely to be willing to try a core mod is also likely to have SVN latest. That's not the way I went, though.

How many people here think it should be against latest instead of RC1?

C//

Should make both that way the ones that has latest svn can use it and for the ones useing the RC1 as well.

[RavonTUS]

Greetings,

Ah, thank you I missed that. I will recompile and check it later tonight.

I enjoy bleeding edge RunUO SVN. After a long, but not too painful, conversion from v1 to v2, I decided to stay as current as possible.

As for core mods, I only have two - LOS 1.1a and Instance Corpses v1.0.0 written by arul. I have committed this week to adding both of them, as well as updating from SVN r72 to r83.

-Ravon

[Joeku]

Yet again, I am amazed. Awesome work, C.

[Courageous]

Joeku: thank you for your kind words. I appreciate them.

Ravon: with the mentioned fix in place, I cannot replicate your error with svn.r83. I ran several screens north of a set of mobiles with LOS on as an ordinary player, returned and they were there.

Thank you for testing, and have fun. 1.1A appears stable so far, and is probably more stable than 1.0B. There will be a 1.1B this weekend that contains somed additional fixes and a few additional minor features.

For example, I'm including an option where you can only see thru a window if you are close to it. I'm thinking about a variety of interesting options like that. For example, shrubs block LOS at range > N, but not at range 1, and so forth. These will all be configurable, but should provide a nitfy little charge to PvP shards in particular.

[I'm contemplating looking at different ways to decide what you can see versus what you can shoot as well, but that will probably be a bit of work]


C//

[nomad707]

Ummm... i love you.

this is an awesome script.
makes pvp and tournaments fun fun

[Courageous]

Still working. First, regarding Ravon's problem: MobileUpdate did what I thought it did in PlayUO only. My mistake for not testing it the base UO. It's a CPU hog, and I don't like to run it.

The code in question is here:

                                if ( CanSee( m ) )
                                {
                                    //ourState.Send( new MobileIncoming( this, m ) );
                                    ourState.Send( new MobileUpdate( m ) );
                                    if ( m.IsDeadBondedPet )
                                        ourState.Send( new BondedStatus( 0, m.m_Serial, 1 ) );
                                    if ( ObjectPropertyList.Enabled )
                                    {
                                        ourState.Send( m.OPLPacket );
                                    }
                                }

Note the line that is currently commented out. It should be commented back in, and the one below it commented out.

Now. On this issue of all names. I've discovered a snag. MobileUpdate() just doesn't do what I need it to do. That leaves me with some painful compromise decisions to make.

It turns out that the information is not in the MobileIncoming packet I'm sending out to the client at all, but rather the client is responding to the server with a "LookReq" (packet 0x09, the same packet that is sent when you single click a mob) whenever MobileIncoming is sent to the client. I have no way of knowing reliably whether or not that single click is initiated by the player directly, or by the software.

This is a tough one, because I'm facing choices like disabling the single click response for 60 seconds every time I send the MobileIncoming packet to the client. That very same interval will keep the name from appearing over the mobs head for 60 second periods, but if you go in and out of LOS alot, you could see it several times.

See the problem I'm facing here?

I'm being pushed towards altering code that will impact the player directly. If I do it, things will work, but then a single click on a mob for a name you missed will silently fail during the quiet period. You'd have to double-click instead.

C//

[RavonTUS]

Greetings,

I made the change above and it works. Mobiles & Players disappear correctly now.

-Ravon

[Courageous]

Other than the known names problem, is all going well?

Addendum: upon closer investigation, the names problem doesn't occur in the main UO client without Razor. It occurs in the main UO client with Razor, and in the PlayUO client.

I'm still working a fix, however I'm not particularly troubled if it doesn't work out. This appears to be a problem with both PlayUO and Razor themselves, not UO. In Razor, I believe you can disable the always-display all names feature (which is malfunctioning: the commercial UO coorrect handling is to not dup an all name if it's already ballooned over the mob's head).

C//

[Courageous]

Updated to 1.1B.

This release seems stable on my end.

Notice! For those of you who already have modded cores, you'll find folding in my mods easier (and mistake free!) if you use a merging tool. Try this one: http://winmerge.sourceforge.net

On to the updates:

• Applies a (configurable) squelching mechanism to suppress the all-names chatter using razor (non razor users won't need this).
  
• Fixes some minor packet issues.
• Fixes a problem with item support in the previous version, where multis couldn't be seen.
• Fixes some issues with some windows in the game, due to UO itself not flagging them as windows properly.
• Adds a (configurable) feature where you have to be close to a window to see thru it.

There are two known defects with this system:

1. One can occasionally "see a little" thru building corners in some cases. I have reasoned out how to fix this, but haven't written the code yet. It will be a bit of a pain.

2. The name suppression technique that prevents the razor bug has a downside: the server won't respond to single-click prop requests during the squelch period. As far as I know, this is as much as I can do. The problem is really with Razor, as the UO client itself seems to function properly when multiple mobile-status (in runuo "MobileIncoming") packets are sent to it.

I don't currently experience crashes or other oddness. If you do get a crash, please post a traceback.

FUTURE...

I'm considering doing something similar to windows for trees, where if you are close to the truee, you can see thru the foliage. This will be configurable.

I've already added a feature in my test base, where you can turn LOS off or on on a per facet basis.

Happy testing, all.

C//

[Gembone]

was this update supposed to fix the dissapearing doors and building signs? they are still dissapearing who los is blocked

Love the system. great work

[Courageous]

Well. Doors and house signs are items (so are multis, and I added special code so that all multis are always not los'sed).

No one mentioned this as a problem previously, but I agree with you, it is kind of annoying, isn't it?

I'll look into how to determine the identity of doors and house signs during the week and figure a strategy (worst case, is I enumerate in the xml, best case is that a few flags and what not determine what's what).

Thanks for testing, and have fun.

C//