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!
XmlPoints
- Thread starter ArteGordon
- Start date
ArteGordon
Wanderer
good idea. I'll add that in.
stormwolff
Knight
Got a crash with the following error using 1.02
Code:
Error:
System.FormatException: String was not recognized as a valid Boolean.
at System.Boolean.Parse(String value)
at Server.Engines.XmlSpawner2.XmlPoints.BroadcastKills_OnCommand(CommandEvent
Args e) in c:\runuo\Scripts\Custom Scripts\Systems\Xmlspawner\XmlAttachments\Xml
Points.cs:line 288
at Server.Commands.Handle(Mobile from, String text)
at Server.Mobile.DoSpeech(String text, Int32[] keywords, MessageType type, In
t32 hue)
at Server.Network.PacketHandlers.UnicodeSpeech(NetState state, PacketReader p
vSrc)
at Server.Network.MessagePump.HandleReceive(NetState ns)
at Server.Network.MessagePump.Slice()
at Server.Core.Main(String[] args)ArteGordon
Wanderer
ah, sorry. I forgot to trap the argument parsing in broadcastkills.
fixed for the next release.
here is the fix. Around line 549 put exception trapping around the bool.Parse calls like this
fixed for the next release.
here is the fix. Around line 549 put exception trapping around the bool.Parse calls like this
Code:
[Usage( "BroadcastKills [true/false]" )]
[Description( "Determines whether pvp results will be broadcast. The killers (winner) flag setting is used. " )]
public static void BroadcastKills_OnCommand( CommandEventArgs e )
{
ArrayList list = XmlAttach.FindAttachments(e.Mobile,typeof(XmlPoints));
if(list != null && list.Count > 0)
{
if(e.Arguments.Length > 0)
{
try{
((XmlPoints)list[0]).Broadcast = bool.Parse(e.Arguments[0]);
} catch {}
}
e.Mobile.SendMessage("BroadcastKills is {0}",((XmlPoints)list[0]).Broadcast);
}
}
[Usage( "SystemBroadcastKills [true/false]" )]
[Description( "GM override of broadcasting of pvp results. False means no broadcasting. True means players settings are used." )]
public static void SystemBroadcastKills_OnCommand( CommandEventArgs e )
{
if(e.Arguments.Length > 0)
{
try{
m_SystemBroadcast = bool.Parse(e.Arguments[0]);
} catch{}
}
e.Mobile.SendMessage("SystemBroadcastKills is {0}.",m_SystemBroadcast);
}ArteGordon
Wanderer
updated to version 1.04
New to v1.04
- added the ability to publicly display your points overhead by saying "showpoints", similar to the OSI showscore command. As on OSI, players will see you actually say showpoints, although unlike OSI the points appear before, instead of after the words. (thanks to AHappyAdmin for the suggestion)
- added in some optional newbie protection code in the OnKill and OnKilled methods in XmlPoints.cs that can be uncommented in the OnKill and OnKilled methods to help keep experienced players from killing newbies for points. (thanks to sUpplier1 for the suggestion).
- fixed a crash bug with the [broadcastkill command (thanks to stormwolff for pointing this out).
- added the [seekills [true/false]" command that lets players control whether or not they see the broadcast results of pvp kills (thanks to sUpplier1 for the suggestion).
New to v1.04
- added the ability to publicly display your points overhead by saying "showpoints", similar to the OSI showscore command. As on OSI, players will see you actually say showpoints, although unlike OSI the points appear before, instead of after the words. (thanks to AHappyAdmin for the suggestion)
- added in some optional newbie protection code in the OnKill and OnKilled methods in XmlPoints.cs that can be uncommented in the OnKill and OnKilled methods to help keep experienced players from killing newbies for points. (thanks to sUpplier1 for the suggestion).
- fixed a crash bug with the [broadcastkill command (thanks to stormwolff for pointing this out).
- added the [seekills [true/false]" command that lets players control whether or not they see the broadcast results of pvp kills (thanks to sUpplier1 for the suggestion).
ArteGordon
Wanderer
updated to version 1.05
New to version 1.05
- added the ability to filter/search the leaderboard by player names or guildnames. In the "[topplayers" leaderboard gump, a comma separated list of guildnames can be entered into "Filter by guild" and all guilds that match the entries in the list will be displayed. Similarly, entering a comma separated list of names, or partial names into "Filter by name" will display all entries with matching player names.
New to version 1.05
- added the ability to filter/search the leaderboard by player names or guildnames. In the "[topplayers" leaderboard gump, a comma separated list of guildnames can be entered into "Filter by guild" and all guilds that match the entries in the list will be displayed. Similarly, entering a comma separated list of names, or partial names into "Filter by name" will display all entries with matching player names.
I received following crashes several times:
Bug is connected with TopPlayersGump, you can reproduce it (for example) by recording macro via Razor - recalling to somewhere and then [TopPlayers and play macro. This will lead to the crash.
Code:
Exception:
System.NullReferenceException: Object reference not set to an instance of an object.
at Server.Engines.XmlSpawner2.TopPlayersGump.OnResponse(NetState state, RelayInfo info)
at Server.Network.PacketHandlers.DisplayGumpResponse(NetState state, PacketReader pvSrc)
at Server.Network.MessagePump.HandleReceive(NetState ns)
at Server.Network.MessagePump.Slice()
at Server.Core.Main(String[] args)Bug is connected with TopPlayersGump, you can reproduce it (for example) by recording macro via Razor - recalling to somewhere and then [TopPlayers and play macro. This will lead to the crash.
ArteGordon
Wanderer
thanks, I'll check it out.
ArteGordon
Wanderer
well, I wasnt able to reproduce that but I added some additional bulletproofing code that should take care of it. Try it out and let me know.
ArteGordon
Wanderer
updated to version 1.06
from the changelog
New to version 1.06
- added some additional bulletproofing to the [topplayers gump to deal with a potential crash bug.
from the changelog
New to version 1.06
- added some additional bulletproofing to the [topplayers gump to deal with a potential crash bug.
ArteGordon
Wanderer
updated to version 1.07
from the changelog
New to version 1.07
- added checkboxes to the points gump to toggle the seekills and broadcast kills settings. These can be used instead of the "[seekills [true/false]" and "[broadcastkill [true/false]" commands.
- added topplayers and challenge buttons to the points gump that are equivalent to issuing the "[topplayers" and "[challenge" commands.
from the changelog
New to version 1.07
- added checkboxes to the points gump to toggle the seekills and broadcast kills settings. These can be used instead of the "[seekills [true/false]" and "[broadcastkill [true/false]" commands.
- added topplayers and challenge buttons to the points gump that are equivalent to issuing the "[topplayers" and "[challenge" commands.
The bug that I mentioned in the previous message repeated again in the latest version of your system (v1.07). I ran server with the -debug option so:
So maybe info.GetTextEntry( 200 ).Text should also have be some "!= null" checks?
Code:
Exception:
System.NullReferenceException: Object reference not set to an instance of an object.
at Server.Engines.XmlSpawner2.TopPlayersGump.OnResponse(NetState state, RelayInfo info) in c:\UO\RUnUO\Scripts\_CustomNew\XML-spawner\XmlAttachments\XmlPoints.cs:line 1363
at Server.Network.PacketHandlers.DisplayGumpResponse(NetState state, PacketReader pvSrc)
at Server.Network.MessagePump.HandleReceive(NetState ns)
at Server.Network.MessagePump.Slice()
at Server.Core.Main(String[] args)
Code:
if(m_attachment != null)
{
m_attachment.guildFilter = info.GetTextEntry( 200 ).Text; <<<< 1363
m_attachment.nameFilter = info.GetTextEntry( 100 ).Text;
}So maybe info.GetTextEntry( 200 ).Text should also have be some "!= null" checks?
ArteGordon
Wanderer
thanks, I'll get the fix in.
ArteGordon
Wanderer
updated to version 1.08
from the changelog
- expanded the Challenge feature to support challenges between any players rather than just within guild. Challengers will be set to Enemy notoriety during the challenge. Corpses will be given the notoriety they would normally receive for innocent death. Challenge battles are allowed under both Fel and Tram rules. Insurance is handled as in any other pvp situation.
- a confirmation gump for issuing a challenge has been added, and in both the issue and accept confirmation gumps, the player is informed if the result of the challenge would yield no points to allow such challenges to be rejected.
- challenges can be cancelled by issuing another challenge and targeting another player (self-target is allowed for this purpose). There is a 15 minute timeout from the time the cancellation request is made. This default time can be changed in the static variable CancelTimeout.
- Ongoing challenges will be displayed in green in the points gump. Challenges in the process of being cancelled show up red.
- added a new installation step (Step 5) to support the expanded pvp Challenge system.
- points and top players gumps are now refreshed automatically on kills and other status changes if they are open.
- added some more bulletproofing for the topplayers gump.
from the changelog
- expanded the Challenge feature to support challenges between any players rather than just within guild. Challengers will be set to Enemy notoriety during the challenge. Corpses will be given the notoriety they would normally receive for innocent death. Challenge battles are allowed under both Fel and Tram rules. Insurance is handled as in any other pvp situation.
- a confirmation gump for issuing a challenge has been added, and in both the issue and accept confirmation gumps, the player is informed if the result of the challenge would yield no points to allow such challenges to be rejected.
- challenges can be cancelled by issuing another challenge and targeting another player (self-target is allowed for this purpose). There is a 15 minute timeout from the time the cancellation request is made. This default time can be changed in the static variable CancelTimeout.
- Ongoing challenges will be displayed in green in the points gump. Challenges in the process of being cancelled show up red.
- added a new installation step (Step 5) to support the expanded pvp Challenge system.
- points and top players gumps are now refreshed automatically on kills and other status changes if they are open.
- added some more bulletproofing for the topplayers gump.
ArteGordon
Wanderer
a quick update to version 1.08a
- added some additional checks to handle the cases of multiple simultaneous challenges. Resolves all multiple challenge scenarios.
It wont let me manage the attachments at the moment, so v1.08 is still there. I'll up 1.08a as soon as it lets me.
(edit)
ok, its up
- added some additional checks to handle the cases of multiple simultaneous challenges. Resolves all multiple challenge scenarios.
It wont let me manage the attachments at the moment, so v1.08 is still there. I'll up 1.08a as soon as it lets me.
(edit)
ok, its up
ArteGordon
Wanderer
Just a note on a change in v1.08 that I forgot to mention.
Within-guild challenge duels no longer give points. I'm going to make it a toggle that can be set in the next version, but for the moment it is off.
Within-guild challenge duels no longer give points. I'm going to make it a toggle that can be set in the next version, but for the moment it is off.
midniterider
Wanderer
Good script
ArteGordon
Wanderer
updated to version 1.09
from the changelog
New to version 1.09
updated 12/13/04
- added a new LastManStanding (LMS) Challenge game. This can be accessed through the points gump. Initiating a game will create an Challenge Gauntlet that is placed on the ground under the player.
- added the "[lmschallenge" command which creates a a new LastManStanding (LMS) Challenge game. This is identical to creating one from the points gump.
- the challenge game gump can opened by double clicking the challenge gauntlet.
- Any ongoing challenge match is listed in the points gump, and the challenge gump for that game can be opened by pressing the ? button next to the status message.
- Version 1.08 disabled within-guild 1 on 1 challenge duels for points. The ability of within-guild duels to give points can now be set with the static bool AllowWithinGuildPoints which is set to false by default.
- 1 on 1 Challenge duels can now ignore the required minimum time between kills of the same player for points. This is false by default but can be enabled by setting the static bool UnrestrictedChallenges to true. I do not recommend enabling this unless you have a small non-pvp oriented shard and dont care about pvp ranking due to the possibility of points exploiting.
- Players can be automatically resurrected after 1 on 1 challenge duels by setting the XmlPoints static variable AutoResAfterDuel. This is false by default.
Last Man Standing Rules
- The player that initiates the game is responsible for adding/removing players, setting game conditions, and is responsible for starting the game.
- Individual participants must accept the challenge by selecting the accept button in the LMS gump.
- An optional entry fee in gold that each player must pay in order to participate can be specified. The entry fee will be taken from the players bank account when the game starts.
- Once a participant is killed, they are out of the game. The last remaining participant is the winner. That player takes the purse which is the total of all entry fees.
- An optional arena size that defines the valid playing area can be specified.
- Players that leave the arena area, defined by the distance from the challenge gauntlet, will have a specified amount of time to return in bounds before they can be disqualified. This time is 15 seconds by default but can be adjusted with the LastManStandingGauntlet static variable MaximumOutOfBoundsDuration.
- Players that become hidden will have a certain amount of time to become visible before they can be disqualified. This time is set to 10 seconds by default but can be adjusted with the LastManStandingGauntlet static variable MaximumHiddenDuration.
- Players that are offline will have a certain amount of time to return before they can be disqualified. This time is set to 60 seconds by default but can be adjusted with the LastManStandingGauntlet static variable MaximumOfflineDuration.
- Players that change maps can be immediately disqualified.
- Players must be "caught" to be disqualified by having a participant or organizer press the Refresh button on the LMS gump when they are in violation.
- While a game is being set up, players can accept or withdraw at any time prior to the game starting.
- Once a game has been started, individual players can drop out of the game by pressing the forfeit button (X) next to their name in the LMS challenge gump.
- Completed challenge gauntlets will remain for a short period before they decay so that players or observers can see the results. The default decay time is 5 minutes but can be adjusted with the LastManStandingGauntlet DecayTime property.
- Players are automatically resurrected after being killed in the match by default. This can be changed by setting the LastManStandingGauntlet AutoRes property.
- The default interval between killing the same player for points is enforced by default during the match. This can be overridden by changing the LastManStandingGauntlet UseKillDelay property. While you can change this, I would not recommend it due to potential for exploits unless you are running a small non-pvp oriented shard where you dont really care about rankings.
- Note that the organizer of a Challenge game does not have to actually participate in it. This makes it easy for staff to organize matches.
- Players can only participate in one Challenge game or 1 on 1 challenge duel at a time.
- Players can only organize 1 challenge game at a time. Attempting to organize a second challenge game while one is still being set up will result in the first being cancelled.
- Note that changing game conditions after players have already accepted, such as adding/removing players, changing the entry fee, or arena size, will require that players must reaccept the new conditions.
- There is no limit to the number of players that can participate in an LMS match by default. This can be changed with the LastManStandingGump constant MaxTeamSize.
- The challenge gump lists the total number of participants in the Players: field, and the number of remaining participants in the Active: field.
from the changelog
New to version 1.09
updated 12/13/04
- added a new LastManStanding (LMS) Challenge game. This can be accessed through the points gump. Initiating a game will create an Challenge Gauntlet that is placed on the ground under the player.
- added the "[lmschallenge" command which creates a a new LastManStanding (LMS) Challenge game. This is identical to creating one from the points gump.
- the challenge game gump can opened by double clicking the challenge gauntlet.
- Any ongoing challenge match is listed in the points gump, and the challenge gump for that game can be opened by pressing the ? button next to the status message.
- Version 1.08 disabled within-guild 1 on 1 challenge duels for points. The ability of within-guild duels to give points can now be set with the static bool AllowWithinGuildPoints which is set to false by default.
- 1 on 1 Challenge duels can now ignore the required minimum time between kills of the same player for points. This is false by default but can be enabled by setting the static bool UnrestrictedChallenges to true. I do not recommend enabling this unless you have a small non-pvp oriented shard and dont care about pvp ranking due to the possibility of points exploiting.
- Players can be automatically resurrected after 1 on 1 challenge duels by setting the XmlPoints static variable AutoResAfterDuel. This is false by default.
Last Man Standing Rules
- The player that initiates the game is responsible for adding/removing players, setting game conditions, and is responsible for starting the game.
- Individual participants must accept the challenge by selecting the accept button in the LMS gump.
- An optional entry fee in gold that each player must pay in order to participate can be specified. The entry fee will be taken from the players bank account when the game starts.
- Once a participant is killed, they are out of the game. The last remaining participant is the winner. That player takes the purse which is the total of all entry fees.
- An optional arena size that defines the valid playing area can be specified.
- Players that leave the arena area, defined by the distance from the challenge gauntlet, will have a specified amount of time to return in bounds before they can be disqualified. This time is 15 seconds by default but can be adjusted with the LastManStandingGauntlet static variable MaximumOutOfBoundsDuration.
- Players that become hidden will have a certain amount of time to become visible before they can be disqualified. This time is set to 10 seconds by default but can be adjusted with the LastManStandingGauntlet static variable MaximumHiddenDuration.
- Players that are offline will have a certain amount of time to return before they can be disqualified. This time is set to 60 seconds by default but can be adjusted with the LastManStandingGauntlet static variable MaximumOfflineDuration.
- Players that change maps can be immediately disqualified.
- Players must be "caught" to be disqualified by having a participant or organizer press the Refresh button on the LMS gump when they are in violation.
- While a game is being set up, players can accept or withdraw at any time prior to the game starting.
- Once a game has been started, individual players can drop out of the game by pressing the forfeit button (X) next to their name in the LMS challenge gump.
- Completed challenge gauntlets will remain for a short period before they decay so that players or observers can see the results. The default decay time is 5 minutes but can be adjusted with the LastManStandingGauntlet DecayTime property.
- Players are automatically resurrected after being killed in the match by default. This can be changed by setting the LastManStandingGauntlet AutoRes property.
- The default interval between killing the same player for points is enforced by default during the match. This can be overridden by changing the LastManStandingGauntlet UseKillDelay property. While you can change this, I would not recommend it due to potential for exploits unless you are running a small non-pvp oriented shard where you dont really care about rankings.
- Note that the organizer of a Challenge game does not have to actually participate in it. This makes it easy for staff to organize matches.
- Players can only participate in one Challenge game or 1 on 1 challenge duel at a time.
- Players can only organize 1 challenge game at a time. Attempting to organize a second challenge game while one is still being set up will result in the first being cancelled.
- Note that changing game conditions after players have already accepted, such as adding/removing players, changing the entry fee, or arena size, will require that players must reaccept the new conditions.
- There is no limit to the number of players that can participate in an LMS match by default. This can be changed with the LastManStandingGump constant MaxTeamSize.
- The challenge gump lists the total number of participants in the Players: field, and the number of remaining participants in the Active: field.
ArteGordon
Wanderer
updated to version 1.10
from the changelog
New to version 1.10
updated 12/14/04
- added a new Deathmatch Challenge game This can be accessed through the points gump. Initiating a game will create an Challenge Gauntlet that is placed on the ground under the player.
- added the "[deathmatch" command which creates a a new Deathmatch Challenge game. This is identical to creating one from the points gump.
- added a timer to automatically check disqualification status during Challenge games, so players no longer have to manually refresh the gump to "catch" players for rules violations.
Deathmatch Rules
- The player that initiates the game is responsible for adding/removing players, setting game conditions, and is responsible for starting the game.
- Individual participants must accept the challenge by selecting the accept button in the Deathmatch gump.
- An optional entry fee in gold that each player must pay in order to participate can be specified. The entry fee will be taken from the players bank account when the game starts.
- The match completion conditions can be specified as a target score or a match length, or both. If a target score > 0 is specified, then the first player to reach that score is the winner. If a match length > 0 is specified, then the player with the highest score at the end of the match is the winner. In the case of a tie, the purse is split between them. If both target score and match length are specified, then the game continues until one of those conditions is met.
- When a participant is killed, their score is reduced by one and they are resurrected with full health/mana/stam. The killer has their score increased by one.
- An optional arena size that defines the valid playing area can be specified.
- Players that leave the arena area, defined by the distance from the challenge gauntlet, will have a specified amount of time to return in bounds before they will be penalized and respawned at the gauntlet location. This time is 15 seconds by default but can be adjusted with the DeathmatchGauntlet static variable MaximumOutOfBoundsDuration.
- Players that become hidden will have a certain amount of time to become visible before they are penalized and made visible. This time is set to 10 seconds by default but can be adjusted with the DeathmatchGauntlet static variable MaximumHiddenDuration.
- Players that are offline will have a certain amount of time to return before they are penalized. This time is set to 60 seconds by default but can be adjusted with the DeathmatchGauntlet static variable MaximumOfflineDuration.
- Players that change maps are immediately penalized and respawned at the gauntlet location.
- While a game is being set up, players can accept or withdraw at any time prior to the game starting.
- Once a game has been started, individual players can drop out of the game by pressing the forfeit button (X) next to their name in the Deathmatch challenge gump.
- Completed challenge gauntlets will remain for a short period before they decay so that players or observers can see the results. The default decay time is 5 minutes but can be adjusted with the DeathmatchGauntlet DecayTime property.
- Players are automatically resurrected with full stats after being killed in the match by default. This can be changed by setting the DeathmatchGauntlet AutoRes property.
- The default interval between killing the same player for points is enforced by default during the match. This can be overridden by changing the DeathmatchGauntlet UseKillDelay property. While you can change this, I would not recommend it due to potential for exploits unless you are running a small non-pvp oriented shard where you dont really care about rankings.
- Note that the organizer of a Challenge game does not have to actually participate in it. This makes it easy for staff to organize matches.
- Players can only participate in one Challenge game or 1 on 1 challenge duel at a time.
- Players can only organize 1 challenge game at a time. Attempting to organize a second challenge game while one is still being set up will result in the first being cancelled.
- Note that changing game conditions after players have already accepted, such as adding/removing players, changing the entry fee, or arena size, will require that players must reaccept the new conditions.
- There is no limit to the number of players that can participate in a Deathmatch game by default. This can be changed with the DeathmatchGump constant MaxTeamSize.
from the changelog
New to version 1.10
updated 12/14/04
- added a new Deathmatch Challenge game This can be accessed through the points gump. Initiating a game will create an Challenge Gauntlet that is placed on the ground under the player.
- added the "[deathmatch" command which creates a a new Deathmatch Challenge game. This is identical to creating one from the points gump.
- added a timer to automatically check disqualification status during Challenge games, so players no longer have to manually refresh the gump to "catch" players for rules violations.
Deathmatch Rules
- The player that initiates the game is responsible for adding/removing players, setting game conditions, and is responsible for starting the game.
- Individual participants must accept the challenge by selecting the accept button in the Deathmatch gump.
- An optional entry fee in gold that each player must pay in order to participate can be specified. The entry fee will be taken from the players bank account when the game starts.
- The match completion conditions can be specified as a target score or a match length, or both. If a target score > 0 is specified, then the first player to reach that score is the winner. If a match length > 0 is specified, then the player with the highest score at the end of the match is the winner. In the case of a tie, the purse is split between them. If both target score and match length are specified, then the game continues until one of those conditions is met.
- When a participant is killed, their score is reduced by one and they are resurrected with full health/mana/stam. The killer has their score increased by one.
- An optional arena size that defines the valid playing area can be specified.
- Players that leave the arena area, defined by the distance from the challenge gauntlet, will have a specified amount of time to return in bounds before they will be penalized and respawned at the gauntlet location. This time is 15 seconds by default but can be adjusted with the DeathmatchGauntlet static variable MaximumOutOfBoundsDuration.
- Players that become hidden will have a certain amount of time to become visible before they are penalized and made visible. This time is set to 10 seconds by default but can be adjusted with the DeathmatchGauntlet static variable MaximumHiddenDuration.
- Players that are offline will have a certain amount of time to return before they are penalized. This time is set to 60 seconds by default but can be adjusted with the DeathmatchGauntlet static variable MaximumOfflineDuration.
- Players that change maps are immediately penalized and respawned at the gauntlet location.
- While a game is being set up, players can accept or withdraw at any time prior to the game starting.
- Once a game has been started, individual players can drop out of the game by pressing the forfeit button (X) next to their name in the Deathmatch challenge gump.
- Completed challenge gauntlets will remain for a short period before they decay so that players or observers can see the results. The default decay time is 5 minutes but can be adjusted with the DeathmatchGauntlet DecayTime property.
- Players are automatically resurrected with full stats after being killed in the match by default. This can be changed by setting the DeathmatchGauntlet AutoRes property.
- The default interval between killing the same player for points is enforced by default during the match. This can be overridden by changing the DeathmatchGauntlet UseKillDelay property. While you can change this, I would not recommend it due to potential for exploits unless you are running a small non-pvp oriented shard where you dont really care about rankings.
- Note that the organizer of a Challenge game does not have to actually participate in it. This makes it easy for staff to organize matches.
- Players can only participate in one Challenge game or 1 on 1 challenge duel at a time.
- Players can only organize 1 challenge game at a time. Attempting to organize a second challenge game while one is still being set up will result in the first being cancelled.
- Note that changing game conditions after players have already accepted, such as adding/removing players, changing the entry fee, or arena size, will require that players must reaccept the new conditions.
- There is no limit to the number of players that can participate in a Deathmatch game by default. This can be changed with the DeathmatchGump constant MaxTeamSize.