P. P. S. While you guys were arguing, we added server-side triggers, giving power players one less reason to carry their MUSHclient around on a flash drive.
I briefly considered this years ago, but came to the conclusion it was a bad idea.
P. P. S. While you guys were arguing, we added server-side triggers, giving power players one less reason to carry their MUSHclient around on a flash drive.
I briefly considered this years ago, but came to the conclusion it was a bad idea.
After carefully reviewing the context and your reasoning, I absolutely agree with your conclusion! :biggrin:
Fair enough, I've talked to a few people about it recently and they had similar opinions. So I forked the thread so that perhaps we could get some pros and cons.
In my mind, it seems like a fundamental thing the client should be doing. One of the things that jumps out at me is that triggers would be more effective than actual input if there's no lag. I realize triggers are probably more effective anyways, but this kinda leaves a bad taste in my mouth as someone who is always weary of things being too triggerable from a design standpoint. I don't know if I want to give them the tools up front to do that even more effectively.
Then there's the security argument, I guess. What happens when a trigger sets off the trigger?
Fair enough, I've talked to a few people about it recently and they had similar opinions. So I forked the thread so that perhaps we could get some pros and cons.
In my mind, it seems like a fundamental thing the client should be doing. One of the things that jumps out at me is that triggers would be more effective than actual input if there's no lag. I realize triggers are probably more effective anyways, but this kinda leaves a bad taste in my mouth as someone who is always weary of things being too triggerable from a design standpoint. I don't know if I want to give them the tools up front to do that even more effectively.
Then there's the security argument, I guess. What happens when a trigger sets off the trigger?
The first item you've listed can be either a pro or a con, depending on the "design standpoint", as you said. AFAIC, I want to enable a laggy player using the web app to do the same stuff as a player close to the server who always plays on an advanced client they've configured. To me, server-side triggers are a logical continuation of a design goal to make many key useability features client-independent.
Your second concern has to do purely with implementation, it seems to me. I've added a small safety delay before a trigger is called. It is enough to make sure that a circular server-side trigger won't lag the game any more than a circular client-side one. It is also enough so that the user can type "stop" at any point to get out of the loop. AFAIK, this loop handling is just as good as the one top advanced clients offer, and most likely simpler than most (players already know to type "stop" to clear their action queue).
The first item you've listed can be either a pro or a con, depending on the "design standpoint", as you said. AFAIC, I want to enable a laggy player using the web app to do the same stuff as a player close to the server who always plays on an advanced client they've configured. To me, server-side triggers are a logical continuation of a design goal to make many key useability features client-independent.
Well, my point is that your triggers would be *better* than those advanced clients because there's no ping. It makes a situation potentially where a player might have to weigh no ping vs reusing triggers from mud to mud on their favorite client. I think you'd be surprised to find that some players are going to begrudge you as they are basically forced to use your triggers with no ping.
Quote
Your second concern has to do purely with implementation, it seems to me. I've added a small safety delay before a trigger is called. It is enough to make sure that a circular server-side trigger won't lag the game any more than a circular client-side one. It is also enough so that the user can type "stop" at any point to get out of the loop. AFAIK, this loop handling is just as good as the one top advanced clients offer, and most likely simpler than most (players already know to type "stop" to clear their action queue).
How much delay did you add?
Just to be clear, I'm not shooting the idea down. I just think it's worth discussion.
I agree with you that this is a topic worthy of discussion.
Well, so I think the delay can go a long way to ensure that noone feels forced to use server-side triggers. Currently, I've set it to 1 sec., which is probably longer than most people's roundtrips. Planning to tweak this and other stuff based on user feedback. The idea is not so much 0-ping as 100% reliability and mobility.
Also, we won't be shortchanging people in terms of features. The server-side triggers already support variables and variable macro triggering. Will support grouping and regex defs very soon. Also, tricky event triggers like 'health under 15%' and 'about to level up' can be made much simpler to define.
17 Oct, 2011, Rarva.Riendf wrote in the 7th comment:
Votes: 0
I would say server side triggers would at least allow anyone to play on the same level: As in a fps, if your ping is high you will suffer. But as Runter says, it means triggers may not be portable (you can still use LUA that is well supported by client though). One of the most common triggers would be to stand once bashed (I even considered making it automatic, but players disagreed)
Thinking about it, an 'easy' solution would be to prevent 'in game' triggers in fight, so players not using them will not be at a real disadvantage. But you still have the ping problem anway.
And for the looping problem ( I have a loop command), my solution is to limit the command queue buffer. (player can clear it with !! may they have screwed something) And to forbid chained aliases.
17 Oct, 2011, David Haley wrote in the 8th comment:
Votes: 0
Wait, isn't part of the whole point of server-side triggers that your latency doesn't matter, because things are processed as soon as they happen rather than by the time you get the message?
BTW, it's Lua, not LUA (not an acronym).
17 Oct, 2011, Rarva.Riendf wrote in the 9th comment:
Votes: 0
Quote
Wait, isn't part of the whole point of server-side triggers that your latency doesn't matter
Back in the days a long time ago when all you had was telnet, it was also the very possibility to have them :) It is also a way to share them easily among your players as whatever your client is, it does not matter since they are on the server. Also a way to detect the most used, see why, and change your game accordingly. I would say the no latency is just a byproduct.
With a little dirty hack you could even totally make it like if it was on the client, sending something in prompt the client need to react to. like [trigger] hp 2500 etc The player would need to send 'trigger' as a command to actually activate it.
17 Oct, 2011, David Haley wrote in the 10th comment:
Votes: 0
I see what you were saying now. You weren't saying that you suffer if you have high latency with server-side triggers. Your first post was confusing to me… clearer now.
It would be interested to see what server side triggers could do that client side could not. If they have access to an API not exposed to the client, that could be neat.
It also makes it a little more reasonable to say that you can't use client side triggers and any use of it would be considered botting, and have a rich server side triggering system that is allowed but has key restrictions baked in. Like not being able to trigger off of certain output (combat?, anti-idle warnings?). Yeah, it's always difficult to catch botters, but I don't know if that's a good reason to make botting legal. I also don't know if it's worth it to make it illegal. :p
17 Oct, 2011, David Haley wrote in the 12th comment:
Votes: 0
The server-side trigger knows the semantics of what's happening, not just the actual text being pasted. So it would be a lot easier to have control flow like: "if I'm at this much HP and am being attacked, drink a health potion". (This is like the notion of Tactics in Baldur's Gate, Icewind Dale, Dragon Age, etc.)
Pure-text triggers are nice and all but are missing the point of triggering logic based on the actual data rather than the string rendering.
E.g., a data-driven trigger will work even if you change the rendering text…
Pure-text triggers are nice and all but are missing the point of triggering logic based on the actual data rather than the string rendering.
E.g., a data-driven trigger will work even if you change the rendering text…
I think that's a good point, but as far as I can tell Plamzi is just doing text matching as it's output.
For starters, yes. But I'm planning to listen to specific requests and move in the direction of controlled event/state triggering, including multiple conditions like in DH's examples. Honestly, it's been years since I played mortal, and I never used triggers, so I have no idea what would be useful.
But I'm planning to listen to specific requests and move in the direction of controlled event/state triggering, including multiple conditions like in DH's examples. Honestly, it's been years since I played mortal, and I never used triggers, so I have no idea what would be useful.
You could allow players to set a mobile program on themselves. That way they could turn their PC into an NPC with a shopkeeper script, or something along those lines.
If you're going to sandbox your mprog engine other options become interesting, like pets with player written AI. Player written/controlled mini-areas make for an interesting end game as well.
18 Oct, 2011, David Haley wrote in the 17th comment:
Votes: 0
I don't play FF so I wouldn't know :smile:
IMO if you really need triggers to play your active character something is a little weird. It seems that if you have a pre-baked trigger that everybody will use, you might as well make it part of the gameplay to begin with. Triggers would be useful if you have alternatives, like customizing exactly when you want your character to start healing your groupmates (or whatever).
I think triggers (of this sort, the "smart" kind that knows of the data) are exceedingly useful for programming henchmen, alternate characters, etc. – basically allowing you to write your own mini-AI routines. (which is useful for everybody, and even fun for people who like that sort of thing)
I liked how DA:O made it part of leveling up characters; you can add "tactics slots" as they level up giving you more scripting options – in other words they actually become "smarter" in terms of the combat logic available to them.
A lot of final fantasy fans didn't like 12 because of the scripting system. It's actually one of my favorites though. .. because of the scripting system. :p
The real problem was apparent, though, when I tied a rubber band to my play station controller to make it continue to move (and get random encounters) over and over all night long while I slept using the AI I set up. Only to wake up to having gained double the levels that i started with. In single player games this thing is more acceptable.
This server side stuff is meat and potatoes for Mush and MOO.
18 Oct, 2011, Rarva.Riendf wrote in the 20th comment:
Votes: 0
Quote
IMO if you really need triggers to play your active character something is a little weird. It seems that if you have a pre-baked trigger that everybody will use, you might as well make it part of the gameplay to begin with.
One of the advantage of having them on the server. You can see what triggers your players use, and when its occurence is more than average, make it an ingame config or something like that (like autsac, autogold autosplit etc)
I briefly considered this years ago, but came to the conclusion it was a bad idea.