[RunUO 2.0 RC1] Courageous True Line of Sight

[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//

 

[Gembone]

Crash and unable to restart server.
even tries to recompile and restart but no go.

RunUO - [www.runuo.com] Version 2.0, Build 2445.26067
Core: Running on .NET Framework Version 2.0.50727
Core: Running with arguments: -debug
Scripts: Compiling C# scripts...done (cached)
Scripts: Compiling VB.NET scripts...no files found.
Scripts: Verifying...done (2122 items, 504 mobiles)
Regions: Loading...done
World: Loading...LOS: Configuration system initializing
LOS: Loading tiles.
LOS: Loading tiles.
Error:
System.IO.EndOfStreamException: Unable to read beyond the end of the stream.
   at System.IO.__Error.EndOfFile()
   at System.IO.BinaryReader.FillBuffer(Int32 numBytes)
   at System.IO.BinaryReader.ReadInt32()
   at Server.World.Load()
   at Server.ScriptCompiler.Compile(Boolean debug)
   at Server.Core.Main(String[] args)
This exception is fatal, press return to exit

any ideas before I start from scratch again?

 

[Courageous]

LOS adds nothing to, and expects nothing from, UO world saves in any way.

I don't believe this could be associated with LOS.

Now. If you plopped Mobile.cs and Map.cs over something other than the RC1 versions, I could see how there might be a problem (if my Mobile.cs and the later-than-RC1 Mobile.cs had different serialization attributes, there could be an issue).

C//

p.s. if you discover that you did indeed drop an RC1 Map.cs over a recent SVN one, you should be able to role out the Mobile.cs and Map.cs back to whatever recent was, and all should be golden.

For something from SVN, you need to perform a merge, not a "drop in". Use WinMerge to make this job easy.

 

[Gembone]

running on fresh RunUO2.0 RC1. must be something with my impored spawners then I will try reverting the save and see what happens. thanks

 

[Courageous]

Okie doke. Suggest you add /debug to your compile line for Server.exe. That way we can see where the serialization is having a tizzy. That might give us a little clue.

C//

 

[Gembone]

yeah I did the debug after the crash and it wouldn't start back up. reverted the save and all good. think it was a bad spawner imported from my 1.0. I dont have all the systems in place yet with this current 2.0 build I am working on. Not happy with my old one and some things needed updating anyway. but got it going thanks for the help

On another note. I have noticed with the tLoS system that it blocks vision with any item in the los. even things you would think you could see over without a problem. not sure if this is encluded in what you were saying about the hedges.

Another side note. Could the cache system you are using for this also be used for a lagfree poisonous swamp system? All the PS systems I have seem seem to cause alot of lag.

 

[Courageous]

Not sure what you're saying about blocking vision with any item in the LOS. That really shouldn't be. What kind of items are actually causing a LOL block? Did you validate this with [los effect ?

C//

 

[Gembone]

sorry to have put it as "item" sleep deprevation causes strange things. was talking about creatures and mobs in general. they disapear when behind small rock or bushes that you would think you should be able to see over. hope this is a little clearer

 

[Courageous]

Hmmmm. That shouldn't be, either. Can you post a screen snap somewhere of a "[los effect" showing the case? The LOS system uses the NoShoot flag to determine a LOS block from a tile. You might click [props on the tile to fetch the flags. or "[get flags" on the tile. Also tell me the tileid/itemid.

(In the evenings ... GMT-8/Pacific Time ... and weekends, I'm often on the #runuo IRC channel, and will happily log into your server to check things out if you need a hands on diagnosis; I really want LOS to work right for everyone).

BTW, to answer your poisonous swamps question: possibly. If the author is frequently fetching tiledata, that could be causing a significant (and unnecessary) I/O hit that a simple cache could overcome for frequently visited areas. Reference me a system to download and check, and I'll look into it. That might be fun optimization challenge...

C//

 

[Gembone]

trying to get a screen shot for you but not doinf it now that I can tell. will keep watching it. as far as the PS system I no longer have it sence a hd crash a while back and the forums have been wiped since I believe. it was an old .36 version I updated for 1.0 but have never seen it posted again. I will look thru some old backups and see what I can find. I would love to have poisonous swamps again but without the lag.

 

[Courageous]

Do keep in mind that land tiles themselves can block viz. If a land tile is higher than the location of the player's eyes, it will block LOS to tiles beyond mentioned tile. If mobs were allowed on mountains, this would create the strange case where you couldn't see a mob on the mountain, but it could see you (fortunately, this isn't allowed in runuo).

Every once in a while, where it's not mountains but slightly raised tiles that are doing th blocking, this can generate a correct but strange LOS result. A longer term solution might be to only do land-base LOS on mountain tile ids. Perhaps I should consider that...

C//

 

[Gembone]

I think it may have been the land tiles. was just south of mistas in Ilshenar.
as far as the swamp system I found one. here is a link to it. http://www.runuo.com/forums/showthread.php?t=56700&highlight=Alari's+Swamp Its from early this year and haven't tried to update for 2.0
but its the first I found.

 

[RavonTUS]

Greetings,

I had time to code this and it appears to be working. I am not sure about the windows, either NPCs are not close enough or I am not close enough. I will play with it a little more.

WARNING WISHFUL THINKING BELOW...
I would like a little more reality into the LOS system with trees. It seems a little to easy to just run and hide behind a tree when being attacked by a monster.

If the monster had a 50% chance of following you around the tree, still unseen, and then jump out at you. That would be a little more realistic.

Good job!

-Ravon

 

[Gembone]

was messing with this last night and noticed this.

player char in house.
Lucids lumberyardaddon directly to the side.
only bits and pieces of the addon show up until I leave the house.
I think this is an addon issue with the LOS.