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!

Resource icon

[2.x] Ultima Live Map Streamer and Editor 0.97

No permission to download

Praxiiz

Sorceror
Yes. I will plan on adding this functionality to the next release. I think the logic will go something like this: When UltimaLive receives a set of file definitions, it will check the client folder to see if the existing maps match those definitions. Any maps that match will be copied over. Any maps that don't match will not be copied, but blank maps will be created instead.

I like this suggestion because I think it keeps the logic clean and UltimaLive may not have permission to modify files in the client folder anyway.
 

Eric T. Benoit

Wanderer
Awesome, thanks. Any idea on what could be causing the hue issue?

So far with the testing I have done on our TC this is an amazing piece of programing. :) I look forward to future updates.
 

Praxiiz

Sorceror
I also found an issue with hued statics not displaying correctly. In the attached screen shot the whole bank should be the darker copperish color but it's not, even with my muls copied into the UltimaLive folder it showed the right color for a second and then switched to what you see below.

Originally when I started this project, I had gone through a website that details the file formats for UO. The statics file format, included a note which mentioned that clients don't use the hue number for each static. I now know that this is wrong. During implementation, I chose to stream the hue information because it would have been more work to take it out. That being said, UltimaLive does stream the hue information for each static. Now some of the map operations don't account for hue, but I have corrected that for this next release.

Your version of UltimaLive is streaming hue information, but RunUO doesn't read the hue information from your statics#.mul file.

To fix this, you need to have the hue information from each static read into RunUO's memory. RunUO already allocates memory for the hue information, but it simply never populates it.

There are a couple of options that come to mind to fix this:
  1. Modify the core so it loads the hue numbers
  2. Load the hue numbers in a second pass for each map from a UltimaLive server script
Now I've tried really hard to have as little RunUO distro edits as possible. I could implement a script that would load all the hue information, but there are some drawbacks. First is that RunUO doesn't load the entire map when it first loads up. It loads portions of a map as they are needed. If I added a script that loaded all the hue information, it would essentially cause RunUO to load all the map info at once up front when the world loads. This would make loading from a save longer, but it would also cause RunUO to use some memory that it may not have otherwise used.

The cleanest way to implement this is a core mod:

In TileList.cs around line 59, there is a method called Add e.g. "public void Add( ushort id, sbyte z )"

Below that method, we're going to add a new method that takes a hue as an argument:

Code:
    /* Begin UltimaLive Mod */
    public void Add(ushort id, sbyte z, short hue)
    {
      if ((m_Count + 1) > m_Tiles.Length)
      {
        StaticTile[] old = m_Tiles;
        m_Tiles = new StaticTile[old.Length * 2];
 
        for (int i = 0; i < old.Length; ++i)
          m_Tiles[i] = old[i];
      }
 
      m_Tiles[m_Count].m_ID = id;
      m_Tiles[m_Count].m_Z = z;
      m_Tiles[m_Count].m_Hue = hue;
      ++m_Count;
    }
    /* End UltimaLive Mod*/

In TileMatrix.cs around line 426 in the "private unsafe StaticTile[][][] ReadStaticBlock( int x, int y )" method, you should see a line:

Code:
lists[pCur->m_X & 0x7][pCur->m_Y & 0x7].Add( pCur->m_ID, pCur->m_Z );

replace that line with
Code:
lists[pCur->m_X & 0x7][pCur->m_Y & 0x7].Add( pCur->m_ID, pCur->m_Z, pCur->m_Hue );

For good measure, we're going to do the same modificatoin to TileMatrixPatch.cs. In TileMatrixPatch.cs around line 180, you should see the following line:

Code:
lists[pCur->m_X & 0x7][pCur->m_Y & 0x7].Add( (ushort)pCur->m_ID, pCur->m_Z );

replace it with

Code:
lists[pCur->m_X & 0x7][pCur->m_Y & 0x7].Add( (ushort)pCur->m_ID, pCur->m_Z, pCur->m_Hue );

You could also do a similar modification to MultiData.cs, keeping in mind that it could cascade into additional changes.
 

Eric T. Benoit

Wanderer
Most excellent, I will give this a go tonight on TC and let you know in the morning how it works out for me. As to loading the whole map at once, I don't think I would mind this, personally, as it may help avoid the otherwise (seemingly) unavoidable "flicker" that happens when a player moves around, even in discovered, unchanged areas it would seem. That flicker, actually, is the only thing holding me back from putting this on my production shard at the moment, not sure players would like it hehe. But it would be awesome to be able to put this on our live server allowing us to make changes (mostly to statics, like floating house signs and such) and have them be instantly visible to the players. You rock, all I can say!
 

Praxiiz

Sorceror
Yes, it definitely would cause CRCs to mismatch even if the files were identical server and client side. The server wouldn't read the static hues, which would cause the data going through the CRC function to be different.
 

Praxiiz

Sorceror
The unavoidable flicker is caused by the reloading of the map and statics on the client side. It also causes additional bandwidth to be used because the client re-requests all monsters and dynamic items/statics in the area. It was a simple way that I found to "refresh" the client after the map or statics had changed. I did some optimization on it by only having it send out the refresh after a full hash-query had been completed (up to 25 blocks updated instead of a refresh after each one).

To avoid the flickering, I would need a good understanding of the client's internal data structures for maps and statics. I would also need a good way of finding them in memory across different clients. If I had that info, then UltimaLive could simply parse the data structures and update them. You wouldn't notice any annoying flickering. The other consideration is if those data structures change from client to client. This approach is the most difficult, and could introduce concurrency issues.

The other way to mitigate the flickering would be to just cause it to happen less often. Each time a player moves a CRC is requested by the server for the surrounding 25 blocks. If any of them are different, they are streamed from the server and a refresh occurs. That 25 number could be increased at the cost of additional bandwidth.

The final way is to just turn the streaming feature off and use UltimaLive as a mechanism to use additional maps. No flickering because the maps are already the same on both the client and server. You could even turn off the hash-queries and essentially the only extra bandwidth used would be during map changes.
 

Eric T. Benoit

Wanderer
Ah, yes, I hadn't thought of the data structure changes from client to client. That would probably the toughest thing to compensate for and, the more clients you want to support the more difficult it would become. These updates happen whenever the dynamic items change also? I had thought it was only checking for map/static changes.
 

Praxiiz

Sorceror
It only happens when there is a change in maps and statics. Basically UltimaLive tricks the client into thinking it is out of sync with the server. The client reloads it's map and statics, but it may request other things as well as part of its resynch procedure.
 

fwiffo

Sorceror
Small fixes are needed in file UltimaLive/LoginHandler.cpp

this is simply a "glitch" fix, since when you first login, you receive the login confirm, but from this point onwards, if you switch the map, you always get from the client the Login Confirm.
The patch I put in there will fix this issue in the correct way.
 

Attachments

  • LoginHandler.cpp.patch
    1.3 KB · Views: 9

fwiffo

Sorceror
Another thing that I noted is the Black Screen glitch when you re-login a second time without closing the client, it could be solved by sending a mobile status update, but if the player doesn't have own status gump open (not paperdoll, but the status with health etc) it will remain black until the status is opened, so I bet this can be solved by forcing the client to open the status bar (client side) and sending the mobileupdate packet to client from the server, no resynch is needed this way.
 

Praxiiz

Sorceror
Avoiding resyncs is always good. I will definitely look into this.

I am almost ready to do another release. I have found and fixed some major bugs from v0.75 which make the system much more stable. Right now my test targets are Windows 7, and Windows XP. I'm testing using client 7.0.2.2 and client
7.0.30.3. The first client is a pre-uop client and the second one uses the uop format for its maps. I would be happy to add more test targets to my list if someone wants to request one.
 

Praxiiz

Sorceror
Praxiiz updated Ultima Live Map Streamer and Editor with a new update entry:

Version 0.91

0.91
Added support to Copy existing mul files if they're the correct dimensions instead of creating new ones (both pre-UOP and UOP)
Refactored to remove some duplicate code from subclassed file managers into basefilemanager
Changed various integer types to be more consistent

0.90
Added support to Copy existing mul files if they're the correct dimensions instead of creating new ones (pre-UOP only at this time)
Added progress dialog window to let users know the current progress of importing...

Read the rest of this update entry...
 

Praxiiz

Sorceror
Version 0.91 Released! This version has some changes to the way hashing is done to handle map wrapping points. It is NOT compatible with v.0.75, so you will need to clean out your streamed files, and replace some of the server side files. You will also need to do another alteration to playermobile.cs to support server side scripts that check to see if a player is using UltimaLive and the version. This is useful for world teleporters / moongates if you want to check to see if a player is using UltimaLive before sending them off to a map that their client may not be able to handle otherwise.

This system is being tested for a live production server, and as such, there have been many things that have been corrected. There aren't many features left that I would like to implement, and so I am now testing and preparing for v.1.0. I am sure there will be many more bug fixes as a playerbase of non-programmers starts using it.
 

Praxiiz

Sorceror
I have attached my first attempt at a userguide. For now it contains step by step instructions to get everything working. Later I will add some more descriptions of how the system works, and other information pertaining to how the system works, the bandwidth costs, and recommendations for production shards. I will also include it in the UltimaLive zip archive the next time I update it.
 

Attachments

  • UltimaLive User Guide.pdf
    1.6 MB · Views: 25

Filou

Sorceror
Sounds epic and i am sad, the Server crashed visiting "Ambrosia".
I have to wait for the next contrib... this tool doesn't do for me what it is written for.
 
Top