Thagoras submitted a new resource:

Moongate System - Moongate system based on original OSI system

This is a system that I have been wanting to put together for a long time. I've always preferred the old OSI moongate system....where you merely see a description of the destinations rather than a klunky gump which takes away some of the fantasy element of the game. I've created other incarnations, but this was the direction I've wanted to go...I just lacked the skills in the past. I thought it was always fun when you're fleeing an opponent and just run through the gate to unknown...

Read more about this resource...
 
Last edited:
Thagoras updated Moongate System with a new update entry:

Classic Moongate System based on original OSI system

This is the update. Fixed a number of bugs. Added optional gump. Removed LostLands key...you will probably get prompted to delete all instances at startup if you had the previous version.
See description.

At some point I'm going to put together a decorate option so you don't need to manually go to every point. I'm not thinking a command, as you may have multiple controllers and controllers are linked to the gates. It'll probably be in the form of another tool.

Read the rest of this update entry...
 
Last edited:
Thagoras updated Moongate System with a new update entry:

Added Shard Decorator.

You need to place the controller. Get the placement tool. Then get the decorator tool. Double click the tool and it'll launch the gump. Right click to abort, OKAY to execute.
You can also add the decorator tool directly....but, as it needs to be associated with the moongate controller, it'll prompt you to target the controller before pulling up the gump.

I intentionally made it a bit more work to get to...so one doesn't accidentally double or triple place moongates. I mean, again, I...

Read the rest of this update entry...
 
Now, I know this is only a little related to this resource, but I didn't want to start a whole new thread just for this little bit of code.

I put together a [Gate command. It's like the [Go command except it opens up a gate. I don't have it setup to perfectly mirror the [Go command. But you can open a gate to a specific XYZ coordinate, Map or Region. Useful when testing escorts, leading pets or other people around...and quite frankly, I don't know why one didn't already exist.
 

Attachments

  • GateCommand.cs
    7.1 KB · Views: 4
To start off this is a real nice system. In using the system I found that the moongates are not displaying their name and description of the destination moongate. Looked at it a bit but not really sure where to fix it.
 
Okay, please don't take offense to these questions....I'm not implying you don't know what you're doing...I just need more information so I can repeat and fix the issue.
1. Do you have the current release? (1.2) I did fix a number of bugs from 1.0 and 1.1.
2. If you did update from a previous version, did you remove the prior instances? I don't think this should cause an issue, but it can sometimes fix conflicts. You know....[remove the controller and then [add a new instance.
3. Did you modify any of the scripts? And if so, what did you change?
4. All your gates have a names and descriptions when they appear on the Controller?
5. Are you using the Gumps for these gates?

The names and descriptions are stored directly on the gates.. The Controller sends each gate which gate is its destination. When you place the cursor on a gate, that gate pulls the name and description directly from the destination, and displays the Name (if selected) and Description....unless you have Gump enabled....which I think just says it's a moongate.
 
1. Yes I have current release
2. Yes I did remove previous instance.
3. Yes I did modify the ClassicPublicMoongate.cs to eliminate the instances calling factions because it was giving an error on compile.
4. Yes all of the gates names and descriptions on the controller
5. No not using gumps for the gates

When I single click the gate it shows the name "a Moongate"
 
Ohhhh....
That's normal. That's just the item name.

You should be seeing the Destination Name and Description when you hold the cursor on the moongate. It's an automatic function of a module called GetProperties. When you move your cursor on many objects, a text box should popup and give a list of properties about that object.
If this isn't happening with the moongates, it's likely it's not happening with other objects and there might be something preventing this function.
 
Ok I do know about the GetProperties function. I do know how it operates and the only thing that it is not working on is the moongates. The properties are displaying fine on the controllers plus other items on the server.
 
Okay. So you removed this from the UseGate module
else if ( Factions.Sigil.ExistsOn( from ) && !m_MGC.Moongates[m_LeftOffAt].HasSigil)
{
from.SendLocalizedMessage( 1019004 ); // You are not allowed to travel there.
return false;
}
and then this from the Gump?
( Factions.Sigil.ExistsOn( from ) == m_mgc.Moongates.HasSigil)

Okay a couple more questions. Are the moongates functional and active? When you pull up the gump at the controller...they're not all gray are they? Have you tried pressing the Restart Cycle button on the controller?
 
All moongates listed in the gump at the controller are functional and active. No none of the listed gates are gray in the controller gump. I have not tried the restart cycle button because the gates were cycling fine.
 
Try replacing the GetProperties in ClassicPublicMoongates.cs with this
in ClassicPublicMoongate.cs:
        public override void GetProperties( ObjectPropertyList list )
        {
            //base.GetProperties( list );
            list.Add(Name);
            if (m_MGC != null && !m_MGC.Deleted && !m_UseGump)
            {
                if (m_LeftOffAt > m_MGC.Moongates.Count-1 )
                {
                    list.Add("...a moongate to nowhere...");
                    list.Add("Endlessness");
                }
                else
                {
                    list.Add(m_MGC.Moongates[m_LeftOffAt].Description);
                    list.Add(m_MGC.Moongates[m_LeftOffAt].NewbieName);
                }
            }
        }
It's just feeling like there's a conflict somewhere and we need to make sure the properties will display. Perhaps something's getting canceled in the base type.

Er, well, you don't actually need to replace it...just comment out the base.GetProperties(list); and insert the new line under it.
 
Well that did not work.
But like I said earlier the only thing that is affected by this issue is the gates themselves. The controllers are displaying properly when you mouse over them.
 
That was just to make sure it wasn't a direct conflict with the moongate and the base item properties.
This is really weird. I'm not even sure how to get this to NOT display the properties.

One thing I ran into while scripting this...and it really frustrated me....was getting the properties to cycle correctly. The gate would go to the right location, but the property display would be off. For some reason, if the graphic doesn't change, the client doesn't feel the need to update the properties. I had the console telling me each time the controller would cycle but the gate itself wouldn't update the destination.
You can see in GetInformation() where I have the line with the documentation "//needed to update properties". This was meant to force the client to "flicker" the graphic each cycle and keep the properties up to date.
The line is still present? It should still work, even if you have a custom gate graphic.
 
I just discovered I don't have the Newbie Names option functioning. They're set to always display. I'll have to fix that.

More questions....I just need to try to reproduce this issue so I can solve it.
The properties displays absolutely nothing? Not even Moongate?
What happens if you go to one of the gates with the controller gump open and toggle Use Gump and Is Active? Making the gate inactive should reduce it to a common item (and display the weight?).

I found a few other tweaks while playing with this.
 
Last edited:
The only thing I can figure is that there's a conflict somewhere...though it makes no sense since this isn't a package that is too out of the ordinary. Plus there are no edits to get it running.
One thing you could try to check if it's the client (perhaps there's a packet conflict) is test the moongate system where it's the only custom. I have several different servers on my computer to test things like this (doesn't everyone?). I don't think the ServUO server I have is current (I'm probably back a few versions)...and perhaps some changes have been made since then. I also use Orion and ClassicUO for my client. I don't use Razor anymore because I found it restrictive (both with gamescreen size and music...amongst other things).
If it works correctly with it being the only custom, then it's conflicting with one of your other customs. If it doesn't work, then it might be an issue with your client. Have you made many changes to your client? Custom graphics?
 
I kind of thought you might have been using an older version of ServUO when I had to take out the faction calls. But, didn't realize you were also using a different client also.

Ok I have 2 different clients and 2 different servers and still doesn't show on mouse over. I made an edit to see if I could get it working properly, but that didn't quite work out. I took out the line calling the base.getproperties and now it shows on single click. This is good for now. Would really like it working on mouse over though.
 
Last edited:
Alright, this is going to seem counter-intuitive...but I've run across weirder things.
I had problems in the past getting the GetProperties to function how I intend. I know there are some things you CAN'T do inside this module. Perhaps in the ServUO update (which I can't seem to compile on my computer for some reason) the array doesn't like referencing other objects directly.

ClassicPublicMoongate.cs:
        public override void GetProperties( ObjectPropertyList list )
        {
            base.GetProperties( list );
            
            string toDescription;
            string toNewbieName;
            
            if (m_MGC != null && !m_MGC.Deleted && !m_UseGump)
            {
                if (m_LeftOffAt > m_MGC.Moongates.Count-1 || !m_IsActive)
                {
                    list.Add("...a moongate to nowhere...");
                    if (m_MGC.NewbieTitles)
                        list.Add("Endlessness");
                }
                else
                {
                    toDescription = m_MGC.Moongates[m_LeftOffAt].Description;
                    toNewbieName= m_MGC.Moongates[m_LeftOffAt].NewbieName;
                    list.Add(toDescription);
                    if (m_MGC.NewbieTitles)
                        list.Add(toNewbieName);
                }
            }
        }

Is anyone else having this issue? I'd really like to know. If anyone else is, I'll try harder to get the current ServUO compiled so I can test my submissions better.
 
Thagoras updated Moongate System with a new update entry:

Added a few features

Well, first....who was the jerk who made it so you you had to leave the gump open when you were placing Moongates? Oh right...
So I added a toggle to put an item in your pack which opens the gump so you can close it and then open it when you need to.

And in response to an issue I was completely unaware existed until it was called to my attention...which I failed to figure out...I added the option to have the Moongate describe the destination scene.

Read the rest of this update entry...
That bit of code did nothing in testing it.
Sorry about the delay. Between your last post and now, I lost my job and had to find a new one and get used to the new schedule....so I didn't have a lot of time to commit to figuring out your issue....which I never did.

I think I found an acceptable work-around though *see update*.

Sometimes you need to stop trying to figure out a problem...especially when it doesn't make sense...and look for alternate routes.
 
Last edited:
I've got an issue

.Failed with: 1 errors, 0 warnings
Errors:
+ Items/Functional/PublicMoongate.cs:
CS0101: Line 17: The namespace 'Server.Items' already contains a definition for 'PublicMoongate'
CS0101: Line 276: The namespace 'Server.Items' already contains a definition for 'PMEntry'
CS0101: Line 294: The namespace 'Server.Items' already contains a definition for 'PMList'
CS0101: Line 496: The namespace 'Server.Items' already contains a definition for 'MoongateGump'
CS0111: Line 21: Type 'PublicMoongate' already defines a member called '.cctor' with the same parameter types
CS0111: Line 26: Type 'PublicMoongate' already defines a member called 'Initialize' with the same parameter types
CS0111: Line 34: Type 'PublicMoongate' already defines a member called 'MoonGen_OnCommand' with the same parameter types
CS0111: Line 54: Type 'PublicMoongate' already defines a member called 'MoonGen' with the same parameter types
CS0111: Line 73: Type 'PublicMoongate' already defines a member called 'MoonGenDelete_OnCommand' with the same parameter types
CS0111: Line 78: Type 'PublicMoongate' already defines a member called 'DeleteAll' with the same parameter types
CS0111: Line 98: Type 'PublicMoongate' already defines a member called 'FindGates' with the same parameter types
CS0111: Line 125: Type 'PublicMoongate' already defines a member called '.ctor' with the same parameter types
CS0111: Line 134: Type 'PublicMoongate' already defines a member called '.ctor' with the same parameter types
CS0111: Line 140: Type 'PublicMoongate' already defines a member called 'OnDelete' with the same parameter types
CS0111: Line 147: Type 'PublicMoongate' already defines a member called 'OnAfterDelete' with the same parameter types
CS0111: Line 154: Type 'PublicMoongate' already defines a member called 'OnDoubleClick' with the same parameter types
CS0111: Line 162: Type 'PublicMoongate' already defines a member called 'OnMoveOver' with the same parameter types
CS0111: Line 172: Type 'PublicMoongate' already defines a member called 'OnMovement' with the same parameter types
CS0111: Line 180: Type 'PublicMoongate' already defines a member called 'CanUseGate' with the same parameter types
CS0111: Line 219: Type 'PublicMoongate' already defines a member called 'UseGate' with the same parameter types
CS0111: Line 234: Type 'PublicMoongate' already defines a member called 'PlaySound' with the same parameter types
CS0111: Line 246: Type 'PublicMoongate' already defines a member called 'FindEntry' with the same parameter types
CS0111: Line 251: Type 'PublicMoongate' already defines a member called 'FindEntry' with the same parameter types
CS0111: Line 261: Type 'PublicMoongate' already defines a member called 'Serialize' with the same parameter types
CS0111: Line 268: Type 'PublicMoongate' already defines a member called 'Deserialize' with the same parameter types
CS0111: Line 282: Type 'PMEntry' already defines a member called '.ctor' with the same parameter types
CS0111: Line 286: Type 'PMEntry' already defines a member called '.ctor' with the same parameter types
CS0111: Line 398: Type 'PMList' already defines a member called 'GetList' with the same parameter types
CS0111: Line 438: Type 'PMList' already defines a member called 'IndexOfEntry' with the same parameter types
CS0111: Line 445: Type 'PMList' already defines a member called 'IndexOfEntry' with the same parameter types
CS0111: Line 455: Type 'PMList' already defines a member called 'FindEntry' with the same parameter types
CS0111: Line 465: Type 'PMList' already defines a member called 'FindEntry' with the same parameter types
CS0111: Line 482: Type 'PMList' already defines a member called '.ctor' with the same parameter types
CS0111: Line 502: Type 'MoongateGump' already defines a member called '.ctor' with the same parameter types
CS0111: Line 626: Type 'MoongateGump' already defines a member called 'OnResponse' with the same parameter types
CS0111: Line 715: Type 'MoongateGump' already defines a member called 'RenderPage' with the same parameter types
Scripts: One or more scripts failed to compile or no script files were found.
- Press return to exit, or R to try again.

Can you help me please?
 
Okay. This has nothing to do with this Moongate system because the namespace I used is ClassicPublicMoongate and this error report is saying PublicMoongate has already been defined.

What's happening is it appears that you have two copies of the file PublicMoongate.cs. The second copy (the one that it's complaining about) is the one that came with ServUO....located in Scripts\Items\Functional. I can't help you with the location of the first one though...you'll probably have to do a search for it.
Whenever you see "already contains a definition for" or "already defines a member called" that means that another script has a module or namespace with the same name (there's more to this but this is the short explanation). The compiler report will usually tell you in which script this occurs so you can correct it.
Due to the fact that so many duplicates exist in the file: Items/Functional/PublicMoongate.cs (especially when it's a namespace) I assumed that somehow the file got copied.
 
Okay. This has nothing to do with this Moongate system because the namespace I used is ClassicPublicMoongate and this error report is saying PublicMoongate has already been defined.

What's happening is it appears that you have two copies of the file PublicMoongate.cs. The second copy (the one that it's complaining about) is the one that came with ServUO....located in Scripts\Items\Functional. I can't help you with the location of the first one though...you'll probably have to do a search for it.
Whenever you see "already contains a definition for" or "already defines a member called" that means that another script has a module or namespace with the same name (there's more to this but this is the short explanation). The compiler report will usually tell you in which script this occurs so you can correct it.
Due to the fact that so many duplicates exist in the file: Items/Functional/PublicMoongate.cs (especially when it's a namespace) I assumed that somehow the file got copied.
I've resolved te issue by deleting the original file, now it works fine, i don't have any degree in informatics, i'm a mecchanical technician that work in fire safety, i know the barely minimun in pc working and programming.
 
I gathered that you didn't understand the error messages....that's why I explained what they meant.
No judgement intended. We all started out knowing nothing.

I like to be informative and teach when I can because I remember how frustrated I was when I was first starting out.
I always preferred it when the person helping me would explain what my problem was and then explained the solution rather than just solving the problem for me.
 
I gathered that you didn't understand the error messages....that's why I explained what they meant.
No judgement intended. We all started out knowing nothing.

I like to be informative and teach when I can because I remember how frustrated I was when I was first starting out.
I always preferred it when the person helping me would explain what my problem was and then explained the solution rather than just solving the problem for me.
Don't worry,i was only explaining my ignorance :)
I'm learning, and i'm having fun to learn.
 
On tick, the controller sends the command to each moongate to update itself.
The GetInformation() module in ClassicPublicMoongate.cs then simply advances where it is on the array to the next legal destination.
If it's at the end of the array, it starts the cycle over.

This system is dependent on the order that the moongates are placed. ..as that's the order of the cycle (i.e., how they're added to the array)...not the actual moongate location...which would have been more accurate to how the original moongates worked. I DID consider this during development but realized that it would require more processing and slow down the server each update.
I guess that's the price of a custom dynamic system.
I suppose I could have made it so you could move the array items around, but at the time I wasn't really sure how I was going to do that.
 
The reason I ask is because the gates seem to get stuck in a triangle of gates quite often and they have to be reset.

Was wondering if there is something that could be done to alleviate this from happening so much.
 
Define "triangle"....because finding triads (where you go from one gate, to another, to another and back to the first one) isn't uncommon. You'd see this on OSI frequently...and it doesn't mean there's something wrong with the code....though I could look into it more. Perhaps triads result from having a specific number of available gates and the triads just progress through the array or maybe how the gates are found in the array when they're placed. If you're caught in a triad with the same three, try deleting one of them and replacing it. That should interrupt the triad because it will move that gate's entry in the array to the bottom of the list....though...if it's a key issue...you'll just see the same three, regardless.

Are you staying at one gate and watching its progress and it's only cycling through three? That's probably an issue with the properties (keys). The gate needs to be "unlocked" to go to other facets...it's automatically unlocked to its own facet so the only way you'd have a problem with a trammel gate on trammel is if one gate is on the main map and the other is in the dungeon area including lost lands and the underworld key isn't checked. Additionally, if the gate is "Only Out" it won't show up on the cycle.

I need you to be clear with your issue. I've been running my gates, uninterrupted, for the past year and they're still cycling normally.
 
Well to describe what happens is that the gates will lock into a circle of only a few of the gates that are in the list. Once that happens the gates need to be manually reset to get more of the gates in the list to used.

I have gone in a circle between probably 5 gates out of 18 gates. Then reset it manually and it added more gates in the list.

I don't have any gates marked as "Only out".
 
I tried to get it to do that on my shard....I couldn't.
Here's a thought. I ran into this while I was working on my decorator. Have you restarted the server since you've noticed this happening?
I'm thinking maybe I didn't make sure that one timer was removed before creating another. Having multiple timers running can cause chaotic effects like that....and I didn't discover this until I saw the chaotic events happening with my decorator...and since the decorator is based on the moongate system (in part)....some of the code from one is found in the other.
I'm off on Monday and can look at the code to make sure that's not happening.
 
I have done a couple different restarts for adding some new code into the server. It does also end up going back to that cycle eventually.
 
Do these gates have anything in common? How are they different from the other gates which don't get cycled?
I need to replicate this issue so I can fix it but don't know where to start.
 
It's just random gates that it gets stuck on. This morning it was stuck on 6 gates. Don't remember exactly which ones. I have Felucca and Trammel gates on one controller and there was 4 Felucca gates and 2 Trammel gates in the cycle. I reset the cycle and all gates were present in the cycle again.
 
Back