UO Second Age

WiseOne wrote:

Blaise wrote:
Automated events give people shit to do other than grief and PK, but of course that would be a bad thing on UOSA, right?

It would be era-inaccurate

Know what else is inaccurate? Having a game that doesnt evolve at all.

kaivan kaivan kaivan .... smh

Kaivan wrote: There is still the significant reward of enjoying a particular playstyle without the concern for outside interference (the exact point of many of these events), unlike with the modifications seen for RP purposes that did not prevent player interactions that the RP players did not approve.

*cough* trammel *cough*

the bazookas wrote:Question 1:
Would the following automated event ever be implemented on UOSA, assuming coding / time were not an issue (i.e. would it not be disqualified as being in opposition to the goals of the shard, and, if time were not an issue, the staff would accept putting this into the shard):

Once per week the Britannia Games wagon wheels into town. At the wagon a player can say "host" and if they have 20k (which they lose), a message broadcasting a team FFA game hosted by X. Players have 2 minutes to run up and say "join" and if they have 5k (which they lose) they are randomly assigned teleported on a team somewhere in Felucca, where a 2 minute wall of magical energy separates them--the only difference is that their guild war noto is disabled, and replaced with other teams being enemy noto. While a game is hosted, no other game can be hosted. The NPC sticks around until either 3 games have been hosted or 24 hours has elapsed, and doesn't come back for another week and a day.

The winning team receives 75% of the buy-in in return (or possibly even NOTHING in return).

Something like this would not be out of the realm of possibility, however it would not be automated (automating this makes it no different than a permanent mechanic).

the bazookas wrote:Question 2:
What about Quests (I mentioned them when I referred to NPC's that players interact with)? I don't know if these quests existed on OSI or not http://wiki.uosecondage.com/Quests. If time and effort were not an object, would the staff be opposed to putting another quest into UOSA? Quests inherently require handling conditional situations involving mechanics that create spawn or other actions based on player actions. Are these sort of special mechanics also out of the question based on the goals of the shard?

These quests are designed to replicate the quest system seen on OSI servers, although there is debate whether this system was active during T2A. As for whether another quest might be added in, this is also not outside the realm of possibility.

the bazookas wrote:I think if we could get solid answers to those 2 questions, then we have somewhere to build from in terms of what staff considers acceptable new content on UOSA.

The purpose of anything like this is not to serve as new content, given the fact that interacting with the mechanics at large and each other is the content. Make no mistake: even in a best case scenario this would serve to provide a limited set of tools to do things that aren't possible without it (CTF namely) on rare non-scheduled occasions.

Populus wrote:

Light Shade wrote:So, the solution here might be that there's still the tracking of events, but let players interfere?

I understand that players can interfere and the "results" might not be all that fair or accurate, but it'd be simple to track the "interference" of other players. I'm not saying stop it, but just put a note next to whatever Duel, CTF, etc...where someone outside of the event interfered with damage or healing.

Basically, have the events and allow anyone to interfere as they see fit and give out NO rewards. Keep track of the results and it'll satiate the egos of these wannabe wizards.

Also, lets look for places in the normal world that we can set these events up in, instead of the proverbial "trammel".

I thought the issue was that it would be lots of work to set up an event. Now we are going to add work by keeping track off what deviated from a normal trammelduel by amount of x gheals in LEETPVPr #2's favor during the duel so that we then can create a 1v1 leaderboard. This is genius.
Lightshade should form forces with Eo so that they can make their eventdream come true.

First off, I'm not at all interested in having automated Trammel Events. I'm just seeing if there is some common ground here instead of the typical "you're dumb!" "No, you're dumb!" comments. Secondly, putting a flag in that said whether someone outside of the duel healed/harmed someone in the duel is not a lot of work at all...

I'm just actually discussing the issue and possibilities. Setting up completely player-ran events is quite time-consuming. Having a system in place that would aid the players of this shard in setting up events wouldn't hurt anything. That doesn't mean i'm suggesting a return to the former events in any way, shape, or form....

It just means that I think that, if the staff found the time to implement systems that would aid its players in hosting and conducting player-ran events, it would improve things.

Again, I am not at all interested in the Instanced Trammel Events. They were not accurate to the Era or the spirit of the Era. In era, however, staff were MUCH more hands on than is the case here. That is just simple logistics and time. Our staff doesn't do this as their full-time job. So, in lieu of full-time staff members I think it would be a good thing to have some kind of help in enriching the shard. I don't know what the best path for that is.

Perhaps it'll have nothing to do with events, but I think there's a real opportunity to do a lot without having to go to Trammel to do it.

I appreciate the direct answers here. I think it's important to finally establish once and for all that trammy automated events are never going to happen again--so that those who want them so bad and those that hate them so bad can just (like Light Shade said) find some common ground (and shut up about them) and we can all start figuring out constructive things that are actually going to be possible given the goals of the shard.

In that light, I think your answers are a good starting point. They certainly beg another big question, though:

Kaivan wrote:Something like [in Question 1] would not be out of the realm of possibility, however it would not be automated (automating this makes it no different than a permanent mechanic).

Question 3
What constitutes automated?
I think it's important to establish this. Every programmatic action (whether it be Orc's Krenbluk head chest or a quest or whatever) has some degree of automation in that players interacting with the game result in an action that does not require direct intervention from staff (but would otherwise not have happened under Core T2A mechanics).
So did you mean that my proposed event idea would fall under the umbrella of "automated" in that the NPC appears in the world on a regular schedule? As I see it, while the proposed event opportunity opens up on a regular basis, whether the event happens depends completely upon players paying for it and initiating it (and does not remove people from the world in any way). So, would this still constitute an automated event? If so, what if the NPC appears at a location randomly in the world and/or at random times (no schedule or predictability whatsoever)--would you still consider it automated (in that it does not require staff intervention to initiate and happens on it's own, as it was programmed)? ... I guess what I'm getting at is, if my proposed event would be considered automated as-is, then what level of programmatic initiation would be acceptable?

Kaivan wrote:The purpose of anything like this is not to serve as new content, given the fact that interacting with the mechanics at large and each other is the content. Make no mistake: even in a best case scenario this would serve to provide a limited set of tools to do things that aren't possible without it (CTF namely) on rare non-scheduled occasions.

I'd also like to comment on the practicality of non-automation (and by that, I mean that it has been programmed to happen without staff intervention). Without having in this sort of "automated" manner, there are only a few ways they could possibly happen at all on UOSA.
1) staff flipping the "on" switch (requires staff intervention, obviously, which, I suppose, falls under the umbrella of "rare and non-scheduled"--and I'm not being critical, I think it's a good position for administration to have--I'm just telling it how it is)
2) staff entrusts certain members of the community with the power to initiate events. This would be super easy to implement (and without giving those community members any more power than flipping the "on" switch) but obviously opens up the possibility of it being abused... The mechanism could be programmed to only allow these event hosts to run X events per time period, so they can't run them all the time too (and other fail-safes could be programmed in as well--but remember there is no reward for the proposed event here anyway).
3) create some sort of quest or in-game related trigger for each specific event such that it can only be initiated when something happens in the world (though would this be considered automated too?). This might be a one-time trigger (a small quest or something). Obviously this requires significant investment by the staff too.

There are simply no other alternatives.

BUT, honestly, I can't see the difference between a staff member (who "signed off" on the programmatic event that they built or otherwise integrated into UOSA) deciding that they must flip the switch personally: "All right, this event is going to happen this monday and friday, so I'll go push the 'on' button and broadcast the message that it's starting" (with or without informing players beforehand via the forums, etc.) and that same staff member deciding "all right, I want this event to run monday and friday this week" and programming it to automatically run itself at those times... and maybe again next month since it was such a freaking blast.
... Err, at least I can't see a difference in terms of what gets accomplished on Monday and Friday (and possibly next month). However, I see a vast difference in terms of how appealing the two options are... obviously the "automated" one requires infinitely less staff time and energy and therefore would allow for the possibility of a neat event happening more than, say, once per 2 or 3 months (or never, as in the current state of large scale group pvp events).

Hence, I think it's important to answer the question: what constitutes "automation" such that it would disqualify an event from happening on UOSA?

the bazookas wrote: Question 3
What constitutes automated?

Your own discussion on this contains most of the answer:

the bazookas wrote:I think it's important to establish this. Every programmatic action (whether it be Orc's Krenbluk head chest or a quest or whatever) has some degree of automation in that players interacting with the game result in an action that does not require direct intervention from staff (but would otherwise not have happened under Core T2A mechanics).
So did you mean that my proposed event idea would fall under the umbrella of "automated" in that the NPC appears in the world on a regular schedule? (this also includes the appearance without intervention by a GM) As I see it, while the proposed event opportunity opens up on a regular basis, whether the event happens depends completely upon players paying for it and initiating it (and does not remove people from the world in any way). So, would this still constitute an automated event? If so, what if the NPC appears at a location randomly in the world and/or at random times (no schedule or predictability whatsoever)--would you still consider it automated (in that it does not require staff intervention to initiate and happens on it's own, as it was programmed)? ... I guess what I'm getting at is, if my proposed event would be considered automated as-is, then what level of programmatic initiation would be acceptable?

Functionally speaking, an automated event schedule is no different than, say, the housing timer or the cast timer, simply on a different time scale and with different triggers. Automating events would make its existence a permanent mechanic on UOSA, and not only violates mechanical accuracy, but ignores the concept of being rare and unscheduled.

the bazookas wrote:

Kaivan wrote:The purpose of anything like this is not to serve as new content, given the fact that interacting with the mechanics at large and each other is the content. Make no mistake: even in a best case scenario this would serve to provide a limited set of tools to do things that aren't possible without it (CTF namely) on rare non-scheduled occasions.

I'd also like to comment on the practicality of non-automation (and by that, I mean that it has been programmed to happen without staff intervention). Without having in this sort of "automated" manner, there are only a few ways they could possibly happen at all on UOSA.
1) staff flipping the "on" switch (requires staff intervention, obviously, which, I suppose, falls under the umbrella of "rare and non-scheduled"--and I'm not being critical, I think it's a good position for administration to have--I'm just telling it how it is)
2) staff entrusts certain members of the community with the power to initiate events. This would be super easy to implement (and without giving those community members any more power than flipping the "on" switch) but obviously opens up the possibility of it being abused... The mechanism could be programmed to only allow these event hosts to run X events per time period, so they can't run them all the time too (and other fail-safes could be programmed in as well--but remember there is no reward for the proposed event here anyway).
3) create some sort of quest or in-game related trigger for each specific event such that it can only be initiated when something happens in the world (though would this be considered automated too?). This might be a one-time trigger (a small quest or something). Obviously this requires significant investment by the staff too.

I pretty much addressed this above. Mechanics can be modified on a limited and in a non interfering way (that is, they do not prevent certain mechanics from operating such as attacking participants) for the purposes of supporting a particular event. They cannot, however, be modified on happen on a regular and automated basis. The rest of what you discuss in your post should be addressed by these two points.

Item bless deeds plx, I R new

Flea wrote:Item bless deeds plx, I R new

I have no idea about item bless deeds and their era accuracy etc, but I presume this is one of those "you aren't accurate in this way, why are you accurate in that way" jabs. I think those jabs have been dealt with in many ways and in many places, and I hope that we can give this topic a more mature look. For me personally (and I think for many on the shard), I think this topic is more important in terms of potential enjoyment on UOSA than any other topic.

Kaivan wrote:Functionally speaking, an automated event schedule is no different than, say, the housing timer or the cast timer, simply on a different time scale and with different triggers. Automating events would make its existence a permanent mechanic on UOSA, and not only violates mechanical accuracy, but ignores the concept of being rare and unscheduled.

First, I must strongly disagree with the necessity of "rare" when it comes to events. I think this is without doubt an administrative decision on the part of OSI staff, and is completely outside of the realm of era-accuracy. If we were trying to replicate the administrative policies and actions of OSI, there would without doubt be infinitely more perma bans due to exploiting (indeed, I would probably be banned for my chicken bomb, for example). I see no reason event frequency should be a matter of era accuracy. I think there's tons of room for discussion and agreement regarding what is too frequent (certainly there could be a situation where events are too frequent), but certainly "rare" is not what I, or most people, would find the correct medium in that regard (assuming the resources were available to run the events).

As for "unscheduled", I must also point to the fact that we are trying to emulate a particular era. Events programmed specifically to occur at random times (though they may be similar in nature) can do this . You strongly implied in your response that if an event "runs itself" it is automatically inaccurate. Emulation does not require that the mechanism is the same--as long as the results are "similar enough", therefore, given that the results are the same whether a staff member randomly decides (and his life randomly gives him the free time) to run the event personally or whether a staff member programs an event to run itself in an unpredictable way and on an unpredictable schedule, are you certain of your conclusion that the second approach would not be appropriate on UOSA?

I would also like to revisit the possibility of players granted the power to run an event--kind of like a "pseudoseer" model; certainly the small number of staff on here relative to OSI is such that invovling the community in such a way seems reasonable (not giving them any GM powers or anything). What say you?

the bazookas wrote:

Kaivan wrote:Functionally speaking, an automated event schedule is no different than, say, the housing timer or the cast timer, simply on a different time scale and with different triggers. Automating events would make its existence a permanent mechanic on UOSA, and not only violates mechanical accuracy, but ignores the concept of being rare and unscheduled.

First, I must strongly disagree with the necessity of "rare" when it comes to events. I think this is without doubt an administrative decision on the part of OSI staff, and is completely outside of the realm of era-accuracy. If we were trying to replicate the administrative policies and actions of OSI, there would without doubt be infinitely more perma bans due to exploiting (indeed, I would probably be banned for my chicken bomb, for example). I see no reason event frequency should be a matter of era accuracy. I think there's tons of room for discussion and agreement regarding what is too frequent (certainly there could be a situation where events are too frequent), but certainly "rare" is not what I, or most people, would find the correct medium in that regard (assuming the resources were available to run the events).

While it is relatively easy to show that the intervention in the game from GMs or other authority figures was specifically limited in order to preserve the game environment, I have never made the argument that we are following OSI policy. However, it is certainly pragmatic to recognize that the game environment was designed to facilitate a world where players interacted with each other without outside interference (asee the GM handbook for confirmation of this), and we recognize this and follow it, regardless of the fact that it mimics OSI policy.

the bazookas wrote:As for "unscheduled", I must also point to the fact that we are trying to emulate a particular era. Events programmed specifically to occur at random times (though they may be similar in nature) can do this . You strongly implied in your response that if an event "runs itself" it is automatically inaccurate. Emulation does not require that the mechanism is the same--as long as the results are "similar enough", therefore, given that the results are the same whether a staff member randomly decides (and his life randomly gives him the free time) to run the event personally or whether a staff member programs an event to run itself in an unpredictable way and on an unpredictable schedule, are you certain of your conclusion that the second approach would not be appropriate on UOSA?

The act of causing an event to happen in an automated fashion, by definition, makes it a mechanic (see creature respawn times as an example - randomized yet on a timer, or escorts which were considered quests on OSI servers).

the bazookas wrote:I would also like to revisit the possibility of players granted the power to run an event--kind of like a "pseudoseer" model; certainly the small number of staff on here relative to OSI is such that invovling the community in such a way seems reasonable (not giving them any GM powers or anything). What say you?

It is extremely unlikely that we would give any players direct access to these types of commands at all. While it would be possible to code a particular level of access that only had access to these commands, this is not the type of power that we would place into the hands of the players.

I absolutely didn't read any of these posts in this entire thread, but how about we just put back all the events (except that gay monster trap in a corner thing) like it was 2 years ago and then be quiet.

Or at least we put in the Saturday afternoon DOCK CTF event that was fun as shit. No silver, just CTF for fun automated. Thanks.

Kaivan wrote:However, it is certainly pragmatic to recognize that the game environment was designed to facilitate a world where players interacted with each other without outside interference (asee the GM handbook for confirmation of this), and we recognize this and follow it, regardless of the fact that it mimics OSI policy.

Hello Kaivan, thanks for your time and effort in this thread.

For clarification, can you provide a definition of outside interference? In addition to that, can you provide limitations and provisions pertaining to outside interference? Finally, is the GM handbook something easily accessible on this website, or is there a link you can provide?

Thanks.

HardCore wrote:Or at least we put in the Saturday afternoon DOCK CTF event that was fun as shit. No silver, just CTF for fun automated. Thanks

That was my favorite event and by far the most entertaining.

Jason- wrote:

Kaivan wrote:However, it is certainly pragmatic to recognize that the game environment was designed to facilitate a world where players interacted with each other without outside interference (asee the GM handbook for confirmation of this), and we recognize this and follow it, regardless of the fact that it mimics OSI policy.

Hello Kaivan, thanks for your time and effort in this thread.

For clarification, can you provide a definition of outside interference? In addition to that, can you provide limitations and provisions pertaining to outside interference? Finally, is the GM handbook something easily accessible on this website, or is there a link you can provide?

Thanks.

Outside interference would be something such as modifying the mechanics for some special occasion. One such example might be moving a player from a small island after they were stuck there. This interferes with the movement mechanics in some way, and would be something that might only happen on a special occasion (although we practice a hands off policy for this example). Another example might be a town invasion, which is a modification to the spawning mechanics in a town for a period of time. A third type of interference, which is relevant to UOSA, is the creation of a moongate that goes to a location that cannot be reached any other way, where the rules of player interactions (stealing, attacking, etc.) are restricted or heavily modified. Interference that severely restrict the interactions between players are certainly the type of interactions that need to be avoided. Of course, this does not necessarily mean that there aren't times where such interference would be pragmatic (i.e. blocking access to the bank with 500 pets), and that there are times where interference would not be pragmatic (i.e. preventing players from being attacked in a GM assisted player event), but that is the general guiding rule.

As for where the GM handbook can be obtained, this should be a working link.

Kaivan wrote:Outside interference would be something such as modifying the mechanics for some special occasion. One such example might be moving a player from a small island after they were stuck there. This interferes with the movement mechanics in some way, and would be something that might only happen on a special occasion (although we practice a hands off policy for this example). Another example might be a town invasion, which is a modification to the spawning mechanics in a town for a period of time. A third type of interference, which is relevant to UOSA, is the creation of a moongate that goes to a location that cannot be reached any other way, where the rules of player interactions (stealing, attacking, etc.) are restricted or heavily modified. Interference that severely restrict the interactions between players are certainly the type of interactions that need to be avoided. Of course, this does not necessarily mean that there aren't times where such interference would be pragmatic (i.e. blocking access to the bank with 500 pets), and that there are times where interference would not be pragmatic (i.e. preventing players from being attacked in a GM assisted player event), but that is the general guiding rule.

As for where the GM handbook can be obtained, this should be a working link.

Thanks for the prompt response.

I'm going to raise a question that regards your personal opinion. How would you feel if a gate opened up, at the normal location where gates use to open up for tournaments, to the Bucs Den Bath House and gave an option for individuals to join an event via double clicking a book. A similiar way to how bag ball was executed, except this location is outside the guard zone and is easily accessible for thieves and the like.

This eliminates the safe room that was available in regards to prior events.

If the opposing parties can get over this first hurdle, then hope may be restored for the pro-event environment.

Thanks

The issue has as much to do with the act of signing up for an event as it does for those participating in the event. An example would be our old 1 vs 1 events that not only protected the spectators but the participants from harm. There are many other issues with the mechanics that are also problematic (teleporting players from out of the world, resurrecting players to participate in the event, etc.), but these are some but not all of the issues that made events problematic, and they would need to be dealt with.