Commission Poll: Automated PvP

[Vorspire]

The system works based on team setup, so I would only need to create one scenario class to handle tournaments, another class for CTF's, etc.
When you create a new battle from the scenario selection, you will then be able to change every aspect of the battle's config options from how many teams are available an the minimum/maximum capacities per team. -In effect, you can easily create XvY (where X and Y are *any* number) - this can allow for handicapped matches too. It's also possible to ally one or more teams, so you can have a 1(40) v 1(40), really the combinations of options are plentiful and every feature works nicely with each other so there are no real bad or wrong configurations

Think of it like this;
A free for all scenario would use 1 team with a max capacity of 40 participants. (it's harder to set up 40 teams of 1 capacity, unless you hard-code it into the scenario class constructor)
In the game's rules, you would enable friendly fire so that players can attack their own team.
The free for all's hard code would cater for notoriety making everyone an enemy no matter the situation or what team they are in.

Other mentions:

There are existing controls and gumps that allow you to set restrictions for:
Items
Mounts/Pets
Spells
Skills

There is also a set of cofig options available called "Game Rules" which pretty much govern the basic rules (most commonly found in Custom Regions In A Box, but none of CRIAB's code has been used) of the entire battle region; Everything from CanDie to CanMount and AllowPets, even basic region rules like AllowHousing, AllowBeneficial and AllowHarmful can be accessed using this config.

Each team must have a designated home-base and spawn-point.
The home-base is usually an area outside of the main battle floor, but still within the bounds of the battle region.
The spawn point is the place at which a team's members are spawned at the start of the battle, it is typically an area within the bounds of the main battle floor.

*** I'm in the final stages of the gumps; I had to rewrite the entire region manager gump to use the SuperGumps framework, but the original Region Manager had a unique layout to all the other gumps which required a new SuperGumps template to be written.
I'm still waiting for work from Pandora, hope to get some testing done tonight (within the next 8 hours) and I'll see if there's any screen-shots worth posting and update etc. Looking hopeful for release next week unless something goes horribly wrong somewhere, which I doubt

 

[jack-0]

dude i can't wait for this, i've been learning c# and building a server for the last 3 months and as soon as i saw this thread i've been excited about the prospects of it

 

[Iraq-]

Yea, the 2v2 was just my way of saying "team vs team"

 

[Vorspire]

Just a quick update, the project is not dead and I know a lot of you may be wondering what's going on, the jist of it is;

This system is in a state of quality control, it's going to be split up into a few dependencies; systems that will be released separately that the Auto-PvP system relies on to function.
Each of these dependencies will be released separately so that they can be used to build other powerful systems.

Everything in the Auto-PvP system is done, the mainframe is done, the battle scenarios are completed, everything is good to go, except the user-interface.
I decided to add to the Super-Gumps framework in order to provide a basic GUI system with pre-built gumps and templates.
The Super-Gumps-UI extension will give you direct access to gumps with specific designs towards Lists and Pagination, there is also a selection of pre-designed dialog boxes (with full modal support) ranging from a standard notification to a simple text-input.
Remember, ALL gumps in the Super-Gumps framework, including the UI gumps, support delegates making things like confirmation dialog-boxes as simple as possible, for example:
[syntax]
Removed the code 23 Feb 2012 because it's obsolete.
[/syntax]
The UI framework also comes with a Context-Menu style gump, enabling faster and more effective gump navigation.
All gumps in the framework are capable of remembering their parents and even interacting with each other in complex ways using delegates, as seen in the above example.
Using delegates also allows the user to track which exact button (object reference) was clicked, as in the above example, can provide a good means for finding the base X and Y for a sub-gump's (Context Menus) position.
The SuperGump_Args is quite possibly THE most important class of the framework, it provides a means to store as much data within any gump as needed, by the use of string-keys and object-values, the base SuperGumps have unique Refresh handlers and the SuperGump_Args are always passed to the constructor, properties can be added to gumps to reference the object in the Args, basically meaning that there is now a simple way to "serialize and deserialize" data between button clicks.
The Refresh feature also digs into the RunUO distro gumps to detect whether the gump is open or closed, before performing an action based on the user-supplied "openIfClosed" argument.

There are so many more features, I'm already finding it hard to tie this all together, jumping from one thing to the next, so I'll just post up this example of a SuperGumps inheritance chain, where features are progressively introduced... Not much longer to wait, have fun in the mean-time!

Inheriting from the SuperGump class, we have a Template, this helps us set up specific variables that we don't really want or need to repeat in every new gump we create.
This template will serve as a default base class from which most other gumps should be derived from.
Take special attention to the details of how the SuperGump_Args are used here in order to store arbitrary data between actions.
There is even a reference to a DialogBoxNotice, which is a special gump, the reference shows how one may construct a new SuperGump.
[syntax]
Removed the code 23 Feb 2012 because it's obsolete.
[/syntax]

Inheriting from SuperGumpsUI_Template, we have SuperGumpsUI_DialogBox, which adds even more functionality and provides a standard "template" and design for the gump.
It can be used by itself or can be derived to add even more features.
[syntax]
Removed the code 23 Feb 2012 because it's obsolete.
[/syntax]

Inheriting from SuperGumpsUI_DialogBox, we have SuperGumpsUI_DialogBoxInput which adds a text entry (standard or limited) to the design and compensates for the input with delegates.
[syntax]
Removed the code 23 Feb 2012 because it's obsolete.
[/syntax]

Another example of inheritance from the DialogBox, the Notice dialog, which is extremely simple, the only change made was to prevent the Cancel button from showing.
[syntax]

Removed the code 23 Feb 2012 because it's obsolete.
[/syntax]

 

[Pure Insanity]

The syntax tags really suck, wish everyone would stop using them completely. They add numbers to the beginning of every line that make it impossible to copy code from the forums. Plus they add a line break every other line for some idiot reason...and even remove all tabs.

Anyways, I can see why this system is taking you so long. Seems you're making a few major systems into one. Sounds like too much work for one system. Your supergump class sounds pretty nice. I've considered doing my own gump class to inherit from to make building my own gumps easier (I swear doing gumps takes the longest when it comes to making any system...anyone care to make a plugin for Visual Studio to work like Gump Studio? Or a new IDE, something like the WOW UI designer app.)

Btw, about your signature...Wtf is an Ouroboros Scheduler? Also why bother with this bit "Projects On List Appear Green When Publicly Available:" if you didn't bother listing any of your finished projects? You have a few good ole ones that you could list on there that are still widely used among the community. And Generic Databases...storage system of sorts I'm guessing?

As for the Language Packs thing, has anyone ever tried doing anything with the Google Translator API with RunUO? The API is extremely easy to use. Just would need a decent connection on the server, if it's gonna be translating a lot pretty often. Could replace the whole cliloc crap with Google Translator, to support even more languages than UO already supports.

 

[Iraq-]

I wish at least the in-game Help Page system was tied to some translator.. for both player to GM and GM to player...

This system still looks pretty nice, I just wish something usable would get released instead of these teasers...

 

[Vorspire]

The syntax tags really suck, wish everyone would stop using them completely. They add numbers to the beginning of every line that make it impossible to copy code from the forums. Plus they add a line break every other line for some idiot reason...and even remove all tabs.

It doesn't remove the formatting if you post using the basic editor instead of the WYSIWYG editor (same with code, but you need the rich argument), besides, the code above is sampled and wasn't intended for copying.

Anyways, I can see why this system is taking you so long. Seems you're making a few major systems into one. Sounds like too much work for one system. Your supergump class sounds pretty nice. I've considered doing my own gump class to inherit from to make building my own gumps easier (I swear doing gumps takes the longest when it comes to making any system...anyone care to make a plugin for Visual Studio to work like Gump Studio? Or a new IDE, something like the WOW UI designer app.)

The SuperGumps framework makes everything easier, it will probably be the first section of my listed systems to be released.
Jeff started writing a new XNA based Gump Editor back in 2009, it was capable of loading gump templates straight from XML files, which the application could generate; I don't think he ever finished it though, I can ask him about it next time we talk.

Btw, about your signature...Wtf is an Ouroboros Scheduler? Also why bother with this bit "Projects On List Appear Green When Publicly Available:" if you didn't bother listing any of your finished projects? You have a few good ole ones that you could list on there that are still widely used among the community. And Generic Databases...storage system of sorts I'm guessing?

Ouroboros - The endless loop of infinity, most commonly associated with the concept of time.
Scheduler - A time-based scheduling system that allows you set up individual schedules and attach them to any custom class. It allows you to set the year, month, day, hour, minute and second that an event should happen and has the option to loop indefinitely if you want to do something like schedule a backup every day at a certain time. It's no different to a typical anti-virus schedule when you tell it when to perform a scan.

Generic Databases, you may have seen me discussing using an ICollection<T1, T2> to dynamically save and load data, I won't go through that again here, so yeah, it's that.

I don't list my old projects because they are already known and they are not new paradigms, the projects advertised in my signature are all base systems which will become dependants for other major systems and will most likely replace any standard systems of their type. For example, the Region Manager will be a newly designed replacement for CRIAB.
The reason I state that the projects will highlight green when available is to offer a base guide-line on what is to be expected in the very near future.
I'm not even sure which of my older projects are actually widely used as a standard, I don't think any of them have achieved the same kind of dependency as Nerun's Distro, for example, so I'd like to focus on the projects in my signature list, because when that list is fully greened out, I'm skipping the next train out of town, so it would be nice to leave some sort of legacy

As for the Language Packs thing, has anyone ever tried doing anything with the Google Translator API with RunUO? The API is extremely easy to use. Just would need a decent connection on the server, if it's gonna be translating a lot pretty often. Could replace the whole cliloc crap with Google Translator, to support even more languages than UO already supports.

I'm not prepared to trade up a sure thing for a hit-and-miss translator, I don't want to be talking about pvp and have the other person think I'm discussing what time I'm going to the moon to eat my dinner with god.
Translators are good, but not good enough and my Language Packs are a very simple solution, given that developers have the ability or contacts to get their English packs translated.
The PVP system Language PAck contains about 500 strings, separated into blocks.

This system still looks pretty nice, I just wish something usable would get released instead of these teasers...

Updates... Teasers... all the same thing

 

[Pure Insanity]

Google translator is pretty good, and imagine it would handle all the cliloc entries rather well when it comes to translating it. As for translating other stuff, such as custom item names...may come out silly once in a while. But you could have it translate typed text by players too, as google translator is pretty decent with that stuff. Just a thought, they have an api for it in C# too...so adding something using it would be rather easy.

 

[Vorspire]

Yeah, if it's so easy and you want it so bad, feel free to work on it, but I don't use 3rd party API access frameworks, I write my own that uses the API directly, I just don't see the massive need for a translation service; Blizzard never did it with WoW (I always take my influence from successful, proven games and companies when it comes to feature design, development and implementation)

On another note, didn't EA already try (and fail) to implement a translation service? I remember a whole lot of client crashes back in the days of 3.0.2 to do with that

There is one API I might seriously consider using, but that's only because Jeff made it sound more awesome than it is, that is a speech-to-text engine.
"Target Insanity"
"Cast Explosion"
"Target Corpse"
"Teabag"

 

[_Epila_]

Any news about the project ?

 

[Vorspire]

Will be included in the next CodePlex commit (check my sig)

 

[_Epila_]

Cool, ill be waiting for it

thanks

 

[Vorspire]

Don't worry I haven't forgotten about this, Pandora currently has more important issues that need addressed before I can continue with the Auto PvP, it's only 2 gump interfaces away from completion which isn't much work, but I work on priorities.

 

[Two Wolves]

Question: Would Auto-PvP be able to handle Yew style Rules of Engagement like the ones used for Red vs Black, described here?
http://www.runuo.com/community/threads/red-vs-blck-battles-and-results.488394/

Current rules of Battle:
No looting, Mounts, Artifacts, Jewelry, Runics, Monster Loot *
No modded spellbooks equipped or aggressive mage summons
Only store-bought potions and lesser poison on weapons

Deathrobes:
- Wearing the deathrobe will prevent you from being attacked.
- On picking up your corpse, you will remain safe if you remain standing on your bones.
- Step off your bones without a deathrobe, attack an enemy, or perform a beneficial act and you are again fair game.

Disallowed Skills:
Taming, Ninjitsu, Bushido, Necromancy, Chivalry, Stealth, Spellweaving

Another Question: Would Auto-PvP be able to display the states of the battle to the participants?

One problem we are running into, using the existing Guild War system, for a fixed number of kills type battle, the only way to find out who is in the lead at any particular moment, one has to stop fighting and dig into the Guild menus to view the current state of the war. That is not so bad, except when the score is very close, then you have to rely on the system message to determine the winner. That message can flake-out.

A display of some kind that keeps the score up to date as the kills occur would be much more handy.

 

[Vorspire]

Question: Would Auto-PvP be able to handle Yew style Rules of Engagement like the ones used for Red vs Black, described here?
http://www.runuo.com/community/threads/red-vs-blck-battles-and-results.488394/

Current rules of Battle:
No looting, Mounts, Artifacts, Jewelry, Runics, Monster Loot *
No modded spellbooks equipped or aggressive mage summons
Only store-bought potions and lesser poison on weapons

There are basic rules and restrictions that cover everything that Region restrictions provide, plus more.
If you create your own custom Battle class, you can also create your own custom options classes that derive the standard ones provided, meaning you can add endless restrictions to your rule set.
Battles have fully configurable Pet and Item restriction lists.

Deathrobes:
- Wearing the deathrobe will prevent you from being attacked.
- On picking up your corpse, you will remain safe if you remain standing on your bones.
- Step off your bones without a deathrobe, attack an enemy, or perform a beneficial act and you are again fair game.

Battles provide an amazing amount of overridable properties and methods, some of which are related to Item Usage, it would be entirely possible to attach an event to a player who just so happens to be using a DeathShroud. This also means you wouldn't have to code the logic into the DeathShroud eiter, maintaining the 100% drag-drop compatibility rating

Disallowed Skills:
Taming, Ninjitsu, Bushido, Necromancy, Chivalry, Stealth, Spellweaving

Each battle has a fully configurable skill and spell restriction list, the lists will support whatever your server currently supports, in cases were compatibility is a must, you can add skills and spells to this list by named-Type-string - this is to allow the Module to be portd between servers supporting different spells and skills.

Another Question: Would Auto-PvP be able to display the states of the battle to the participants?

One problem we are running into, using the existing Guild War system, for a fixed number of kills type battle, the only way to find out who is in the lead at any particular moment, one has to stop fighting and dig into the Guild menus to view the current state of the war. That is not so bad, except when the score is very close, then you have to rely on the system message to determine the winner. That message can flake-out.

A display of some kind that keeps the score up to date as the kills occur would be much more handy.

The PvP system comes with a comprehensive statistics structure and interface which tracks and saves all battles' statistics in real-time.
You can hard-code a battle's goals, how it works, what players need to achieve, etc, simply by overriding one of the hundreds of methods exposed by the base PvPBattle class.
The base concpt of a Free For All battle is all players fight till the last man standing, in which case the battle is simply coded to end itself when there is only one participant left. - The same can be applied to "the first with X kills" - There are methods available to control rewards, who wins and why and what you should do with the winner, same for losers and there is a fully configurable PvPReward opton for winners and loserson eac battle, which supports Items and Mobiles as rewards.

Players also have a PvP Profile of their own, which stores all statistics for their participation in te PvP system andallows players to view a global list of other play profles, ordered by 3 different modes of rank: Kills, Points or Wins.
PvP profiles come with a standard collection of statistics that are tracked by the main system, ranging from Total Damage Done and Total Damage Received to Total Kills, Wins, Deaths.
When creating a custom Battle class, it is entirely possible to store your own custom statistics in a Player's PvP Profile, simply by accessing the Profile with a string-key.
PvP Profiles also support history, when you view a profile, you only see the most current, grand total of all statistics, but the underlying system actually stores statistics for a daily basis,which I may use at a later date to enable graphing and charts.

Just to add some weight to the comprehension of the size of this system, it has as much code in the base PvPBattle class as the RunUO core Mobile.cs and the PvPBattle class is just one simple object of 30+ other scripts included in the system.

 

[Iraq-]

Download Button ?

 

[Vorspire]

-linked thread has been deleted-

 

[Vorspire]

This system is finally completed and in a stable working order, despite being overdue somewhat, I hope it was worth the wait!

Get it now in VitaNexCore BC 3.0!
http://vncore.codeplex.com/releases/view/85591

 

[Vorspire]

BC 3.1 was released with some major upgrades to the AutoPvP module, now supporting battle seasons!
Battle seasons allow your players to gather points, wins, kills (however you rank profiles in the system options) to get a spot in the top 10 before the season ends.
Any players in the top 10 at the end of the season receive a reward (which you can specify) and everyone else gets a loser" reward (which can also be specified) - You can also change the amount of the top 10, to the top 3, 5, or whatever you want.

I also took out the complex saving algorithms used for the AutoPvP system, the system will no longer perform it's own backups and will no longer restore corrupt battle and profile saves, it will merely ignore them.
The reason for this major change is due to the fact that with 1000 profiles in the system, it can increase save times by a few seconds - no one wants that.
Thanks to PandoraUO for running the system live for the past couple of weeks, the shard had in excess of 1000 PvP profiles which brought this matter to my attention.

...Enjoy

 

[Vorspire]

AutoPvP modle now supports "seasons" - this allows you to set a period of time after which all profiles will be reset, having their totals saved into history.
You can browse seasons, ranks and scores by the season number - this adds in a whole new concept to the battles, allowing you to also specify rewards for winners and losers for each season.

The seasons feature is currently in the module, but there is a major upgrade comming for it that will ensure the system's stability as there have been a couple of minor bug reports with the seasons not advancing after the period, rest assured it's all cush now

Keep an eye out for the next commit, it's gonna be a doozy, lots of new features added to VitaNexCore...

The next release of VNc will also include a SkillCodex, which is a book capable of performing all of the tasks of any given Skill Ball (there's too many to choose from out there, none are perfect - this uses the SuperGumps UI to make life much easier)

I have also written an extension for Skills, primarily used by the SkillCodex - this extension class will extend the Skill class with a few new methods that make it easier to manage skills.

Also, for those who wish to start imbuing systems, there will be an extensive AosAttributes extension class that extends the various Attributes classes and enums with new methods to help calculate property Weights and Intensities - this might be followed up with a full imbuing system so keep an eye out for that