WiseOne wrote:It would be era-inaccurateBlaise 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?
Know what else is inaccurate? Having a game that doesnt evolve at all.
WiseOne wrote:It would be era-inaccurateBlaise 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?
*cough* trammel *cough*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.
Budner wrote:Your sig lets everyone know what an arrogant prick you are.
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 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).
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: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?
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.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.
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...Populus wrote: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.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".
Lightshade should form forces with Eo so that they can make their eventdream come true.
Question 3Kaivan 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).
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.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.
Your own discussion on this contains most of the answer:the bazookas wrote: Question 3
What constitutes automated?
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: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?
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.the bazookas wrote: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.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.
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 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.Flea wrote:Item bless deeds plx, I R new
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).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.
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: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).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.
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: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?
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.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?
Hello Kaivan, thanks for your time and effort in this thread.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.
That was my favorite event and by far the most entertaining.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
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.Jason- wrote:Hello Kaivan, thanks for your time and effort in this thread.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.
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.
Thanks for the prompt response.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.