Advanced In-game Scripting

[zanzibar]

Zanzidude did you even red all i wrote beffore being so offensive. The only thing you are trying to do is make me feel stupid!

I read your post.  Did you read mine?  And no, I'm not trying to make you feel stupid.  That's just a side-effect of someone else rightfully disagreeing with you.

Youre not a hero youre one of the bad guys.

Oh snap, you got me!

[Nividia Stormlance]

 
topic is Advanced In-game Scripting, not weapons.

[Peacer]

i like the idea of more advanced macros, although it shouldn't be like making your char a bot. This could be a possible script

------
/mine gold
if succesful = true then
/echo mininglevelpractisepointpercent (or somethign like that)
/echo weight able left to carry
/echo currentxp
if succesful = false then
/echo currentxp
(if there is /mine gold again you can't use if again in the same macro )
-------
also a possible script
-------
spellp = currentmana done some mathematcial stuff
/cast energy arrow "spellp"
-------

this will make one solve the mana left of one's char and use it to determine the spellpower used in a certain spell,

and when the game doesn't become one hit killable you oculd have this

-------
if self hp = 100 then
/atack 1
elseif hp > 80 then
/attack 2 (and so on.)
-------

this makes 5 macros to 1, and could be

[Rockhoof]

Frist Psot, so be relatively gentle!

IMO, there's a role for scripts even in a 3d MMO rpg.  I've been lurking here in the forums for a couple of weeks now, learning about the game (reading other's thoughts on something is a wholly different way of learning than experience, and couples nicely with it) and I have to say that I LOVE what is being done here.

Some thoughts on how scripting can enhance game-play:

1. Knowledge of the game mechanics enhances suspension of disbelief, a core to any role-playing game.  Once you know automatically what is and isn't possible, the impossible things are unconciously weeded out of your thought processes.  The prime example of this is that of a chess player considering moving a bishop.  Without thinking about it, only the diagonal directions are considered, because in the world of chess, bishops can only go diagonally.  Opening up scripting to players deepens their knowledge of the game.  This can only be a good thing.

2. Scripting encourages active development.  This is an open source project, and as such can use all the developers that it possibly can.  Being able to see the source code is great, but there are many people who would love to help, but don't think their knowledge of programming is sufficient.  Scripting does two things:

• Scripting allows people of lesser knowledge to help.  Scripting languages are invariably easier to code in than the parent executable.  There are strict limits on what actions can and cannot be performed and so on.
  
• Scripting teaches good programming practice.  Scripting allows an entry point into development.  By becoming familiar with scripting actions, when people DO eventually dive into the code and they see the function that was called when they executed an action, they have an inherent understanding of that function already.
• Scripting IS development.  Scripting is and always has been a mini-game within MMOs, from DiKU muds to the most modern incarnations like WoW and EQ2.  Allowing scripting enhances the game for everyone.  It shows exploitable holes in the code logic, it automates some of the boring, repetative tasks &ct.

3. Using the same scripting language for mobs and players makes for a more dynamic environment.  Players should not have the range of functions available to them that mobs have, of course; That is a given.  However, instead of having to recode (and then debug!) an entire executable, pulling mob actions out of the main program makes diagnosing and organising their actions and reactions MUCH easier.  Players familiar with the range of options available to them via scripting will be much better equipped to help create dynamic and interesting mobs than someone who just jumps in.

4. Scripting allows actions that would be possible in a 'real' world that are made difficult because of the game interface.  Attaching a /say command to a /cast command is a good thing, and enhances suspension of disbelief.  Script functions like /TargetLowestPlayerHealth() and /Assist(PlayerName) allow for things that would be automatic in a 'real' world environment.

These are all very good reasons for allowing scripting, and I understand that there are some people who are - justifiably - afraid of having an army of 'bots overwhelming what is meant to be individual players interacting.  There are some solutions to this issue, and some very good ones. 

1. Movement.  Movement should ALWAYS be under complete control of a PLAYER, never a script.  There should never be any movement functions available to a player.  You can't 'bot very well if you can't move.

2. Actions.  One hardware event, one action.  This one isn't has hard and fast as the above. Some functions available to scripts shouldn't be considered 'actions'.  For example: I like to play Wizardly types, and I love having incantations accompany my spells.  It is much more RP to have my 'toon shout 'Ignam belicosus, fiat LUX!' when casting a fireball than it is to just cast a regular old fireball.  Attaching a /say command to a /CastSpell("Fireball", 3) IS scripting, and is the type of scripting that should be encouraged.  Again, you're not 'botting if you have to keep pressing keys.

3. Initiation.  Scripts should ONLY be initiated by a hardware event.  This will stop the 'response' type script, which is NOT RP.  /away is enough for that, someone sending you a tell get's your /away message and you get a cute little /away flag on your 'toon so people don't think you're ignoring them - in some things, convienence SHOULD take precedence over immersion.  Again, you can't bot if you can't respond automatically to game input.

We've covered what scripts should not be able to do.  The next things give a vision of what they SHOULD be able to do:

1. Player and Mob Scope.  Scripts SHOULD be able to take into account the status of a player and that player's party and any actively engaged mobs.  An /assist script is a great example of this.  Bind a key or slot to /assist PlayerName.  You're making life EASIER for people with this script, because in a big fight, it can often be confusing as to which mob to attack.  Another good example is /target PlayerLowestHealth() followed by /CastSpell("Minor Heal", 2).  This is a Role-playing game and in real life there are many more stimuli available to people than within the confines of the game system.  Allowing someone to heal the person with the lowest health or keep one person /assist-ed is NOT a violation of a strict RP environment because the game mechanics are limited to what visual and audio details have been implemented.

2. GUI Scope.  Players are individuals and game designers are not omnipotent (so don't believe them when they say they are!  ).  Allowing scripts to manipulate the way the PLAYER interacts with her environment is a GOOD thing.  New artwork, extra buttons, better/more informative displays, &ct.  All of these things and more fall into the realm of scripting.  GUI changes are not violations of RP because they don't affect other players or the way the game is played.  In fact, they encourage RP.  A player who wants to play a dark, brooding, evil character can manipulate her GUI to reflect that by adding skulls and slime and shadowy figures to the artwork in and around her action buttons.  A player who wants to be the best, most efficient healer in the game, can manipulate her GUI for enhanced flexibility and efficency by moving healing buttons to where she can most easily reach them and place her simple, spare information displays directly in her line of sight.

Let's take a concrete example of this, using our Healer as an example.

Our healer, let's call her Grace, wishes to be as effective a healer as she can.  So, she creates - or downloads from someone else's creation - a GUI script that creates extra buttons joined to each party member's information display.  She doesn't go crazy with this, she just wants a few buttons on each one.  Then, she makes some simple scripts for each of her new buttons.  They look something like this:

Code: [Select]

/Target PartyPosition(1)
/say "Don't worry " + PartyPosition(1) + ", you've got a heal incoming!"
/CastSpell ("Minor Heal", 2) //Comment: Minor Heal, rank 2.
/TargetLastEnemy()She does this for PartyPosition(2) and PartyPosition(3) &ct.  Is this an RP violation?  Of course not!  All it does is simplify a rather repetive task that, in the real world would be a lot easier.  Grace WANTS to heal her party, but the interface can make that clunky sometimes.  By allowing Grace to attach buttons - and actions - to her party members, she simplifies the act of targetting the person she wants to heal, healing them and going back to the target she wants to destroy.  All of these things would be automatic in a 'real' world where these things are possible, but the interface will get in the way of that.

Continuing our example, let's say Grace has discovered a need for a 'Panic' button.  She puts a simple script in her main bar that looks something like this:

Code: [Select]

/TargetPlayerLowestHealth()
/CastSpell("Mega Heal", 5)
/say "The " + Assist() + " is attacking " + TargetPlayerLowestHealth() + " pull it off of them before they die!"
/TargetPlayerLowestHealth()
Again, in a 'real' world where this action was going on, all of these things would be automatic.  Scripts like these INCREASE versimilitude by allowing the player to designate oft repeated actions to a script that does exactly what they intend to do, but allows the interface to be shoved out of the way.  All of these things would be possible in a real world environment, but the interface prevents that.  People don't type as fast as they talk, and one can talk and DO something at the same time, can they not?

Anyhoo, taking a middle ground between no scripting and out and out 'botting is the best way to go in my opinion.  People LOVE to customize.  Look at the Hot Rod craze of the 50's and 60's, look at all the custom do-dads and gee-gaws available for customizing one's computer today...  As long as reasonable precautions are taken to prevent 'botting, scripting can, and should be encouraged.

[DaveG]

I think you're misunderstanding a few things here.  First of all, we already have a full scripting engine used for NPCs.  Secondly, we're already trying to do the sort of thing you're suggesting with shortcuts.  Shortcuts allow a batch of commands to be done at once, but they can't react to stuff or run autonomously as was suggested at the start of this thread.  They're there to remove some of the kludge of having to use a keyboard and a mouse to do these things by letting users map certain sets of things to buttons.  The only thing we're missing in your healing example is a way to target the nearest group member or one with lowest health.  (the former could be added, the later shouldn't really be automatic)  When it comes to automated chatting, that's a bad idea.  It's just annoying and stupid, and I'd rather people just type slowly than resort to automated text.  (actually, I'd rather people learned how to type... all too often I'm talking to someone in PS or on IRC and I think they're connection was lost, and it's just that it took them a minute to type one sentance...)  Oh, and by the way... we have an /assist command. 

When it comes to the GUI, skins are quite user-mod-able and the plan is to eventually get rid of most of the need for shortcuts.  We'll eventually have a much more flexable system with easily configurable icons for things, instead of having to restort to making shortcuts.  Example:  I'd like to be able to just right-click on a group member in the list, and click a glyph icon to quickly cast that spell on them.  (maybe even be able to right-click on that and set it to a button)  Essentially, shortcuts are largely a temporary solution until we make a much fancier GUI. 

(In the future, please be a little more consice.  :/  Long rambling posts are not a good idea on simple concepts.)

[Rockhoof]

I think you're misunderstanding a few things here.  First of all, we already have a full scripting engine used for NPCs.  Secondly, we're already trying to do the sort of thing you're suggesting with shortcuts...

Lol, I'm aware of this.  Maybe I should have made it clear.  The intent of the post wasn't to describe the mechanics of the current system, but to show how scripting is both useful and a role-playing aid.

...  The only thing we're missing in your healing example is a way to target the nearest group member or one with lowest health.  (the former could be added, the later shouldn't really be automatic) ...

Meh, personal preference.  Personally I would rather be able to negate my UI as much as possible, the only thing UI's are really excellent at in games is information display, otherwise they tend to slow down reactions to new situations (see your complaint re: typing speed for a prime example).  If I intend to heal the person with the lowest health, in a real world situation, this is pretty automatic[1].  In a game - where sensory input is severly limited - one can go too far into 'realism' and forget that the UI is supposed to allow the intentions of the player to be accomplished and scripting allows players to do this.  As long as it's not 'botting, IMHO let a creative player do as they wish.  Limiting people is just that... limiting.

When it comes to automated chatting, that's a bad idea.  It's just annoying and stupid, and I'd rather people just type slowly than resort to automated text.  (actually, I'd rather people learned how to type... all too often I'm talking to someone in PS or on IRC and I think they're connection was lost, and it's just that it took them a minute to type one sentance...)  Oh, and by the way... we have an /assist command. 

Sorry, I missed the part where I said that automated chatting was good.    Actually, I said "Scripts should ONLY be initiated by a hardware event.  This will stop the 'response' type script, which is NOT RP."  In the same vein, I said that /away should be enough, but there's a good argument for a /DND tag too.

When it comes to the GUI, ... Essentially, shortcuts are largely a temporary solution until we make a much fancier GUI. 

(In the future, please be a little more consice.  :/  Long rambling posts are not a good idea on simple concepts.)

Again, personal preference, I prefer precise to consice (oh, and I don't ramble!... present text excluded, of course! ).  You've misread what the purpose of my post was: In showing how scripting is a good thing, showing how it can and should be limited goes a long way towards alaying fears of 'botting, which is the most common problem people have with opening up some of the game commands to be unbound from key-presses.  After that, a concrete example to 'cement' the concepts and give a clear indication of what the heck I was talking about is, while not strictly necessary, certainly useful.  Acomplishing these three things is not simple or easy, and doing so in less than 5,000 words is even harder, I rather think I did a good job of accomplishing three complex goals in so little space.


[1]Since spells are, to a certain extent, abstracted away, there's no real reason why 'target lowest health' can't be an option when casting the spell.  If you feel the need for an RP reason:

"Instead of using the mystic symbol of a specific target, one can, if one has the knowledge and is willing to take the risk, allow the spell to direct itself to a greater or lesser extent."

[Vengeance]

I don't hate the thoughts of the original poster on this thread, subject to the limitations Rockhoof helpfully came up with.

1) No movement.  Player must move himself.
2) No looping.  Nothing gets fully automated for hours.
3) No real intelligence.  Very limited conditionals.
4) No presumption of tactics.  /target_lowest_health or whatever tells a healer how to heal.  He should determine who to heal on his own, or else we'll get demands for /target_fastest_declining_health, /target_most_hp, /target_lowest_mana, etc. too.  We have /target_nearest_player and /target_nearest_npc, /assist and other helpers like that, but the intent is to use these to map keys and reduce typing, not to mandate how the game is played.
5) No response to chatting (or other game player events).  Chat Bots are annoying even on irc.

The first thing to add is the delay command though, so a shortcut script can pause a bit while a spell is casting, imho.

- Venge

[Rockhoof]

I don't hate the thoughts of the original poster on this thread, subject to the limitations Rockhoof helpfully came up with.


4) No presumption of tactics.  /target_lowest_health or whatever tells a healer how to heal.  He should determine who to heal on his own, or else we'll get demands for /target_fastest_declining_health, /target_most_hp, /target_lowest_mana, etc. too.  We have /target_nearest_player and /target_nearest_npc, /assist and other helpers like that, but the intent is to use these to map keys and reduce typing, not to mandate how the game is played.

The first thing to add is the delay command though, so a shortcut script can pause a bit while a spell is casting, imho.

- Venge

Thanks for the endorsement!  However, I'm not at all sure how you see /targetLowestHealth() is a presumption of tactics. http://dictionary.reference.com/search?q=presume.  For the link-following challenged, here's the relevant definition:
v. intr
...
2. To take unwarranted advantage of something; go beyond the proper limits: Don't presume on their hospitality.

I'm completely at a loss to understand how /targetLowestHealth() is substantially different from /targetParty1() or /targetParty2() or /targetPlayerByName("Foo").  The mechanics involved are exactly the same, merely the decision factor is different.  Using /targetParty1(), I'm shortcutting the mouse movements to target the first person in my party display, something easily determined by looking at the UI..  My decision is to target player 1.  Using /targetPlayerByName("Foo"), I'm shortcutting the mouse movements to target the person named in the function again, something easily determined by looking at the UI.  My decision is to target the player named Foo, provided he's within rage of the /target function.  Using /targetLowestHealth(), I'm shortcutting the mouse movements to target the person with lowest health, something easily determined by looking at the UI. My decision is to target the player with the health value closest to 0.0.  This is exactly the same as targeting a player by name or any other attribute.[1]

None of these functions make any decisions for the player.  The player has already made the decision, in advance, just like in every single script ever invented. 

Also, without being offensive (seriously!) I'd like to point out that the rest of your argument is a type of non causa pro causa fallacy known as the Slippery Slope.  Each and every function should be evaluated on it's own merits and a discussion of /targetLowestHealth() has no bearing on /targetFastestDecliningHealth() or any others.  Unless there is a casual relationship between another function and /targetPlayerLowestHealth(), additions really aren't germane to the discussion at hand.  I'm the son of a diplomat, I can't help seeing these things.

Consider:  The object of any and all functions should be to reduce keystrokes and allow for commonly made decisions to have a small level of (user initiated) automation.  In effect, you are compensating for the inherent clunkiness of the UI (inescapable for any game, no matter how well designed) and for the depradations inflicted upon all of us by that horrible monster (shhh!) Laaaag by allowing such things.



[1] Provided that the scripting system includes access to player attributes like Name, Mana and Health (a good thing) and provides conditionals like '<', '==' or '=<' (a very good thing), functions like /targetLowestHealth() are, in essence, aliases for more wordy strings of commands.  It's a trivial matter to compare the health attributes of all players in a party and simply select the player with the lowest value.  A student in his first day of a programming course could do the same.

[DaveG]

The main reservation of Venge and I is that we don't want scripts making any decisions.  Even with the lowest health example, that person has to be found.  It'd be better for the player to have to look around, find them, and then execute the command.  The player may have already made the decision, but it requires a subsequent decision to actually decide who has the lowest health.  We want these things to make things easier/faster but not fully automatic.

When it comes to conditionals, you and Venge like the idea however I'm really not convinced it's needed.  We'd also have to have functions reporting information to be analysed, which opens up a whole other pile and risks users creating their own rather exploitive scripts.  I think this sort of thing should be handled by the commands themselves.  Ex: "/target prev player" runs some logic to figure out who that is.  In my opinion, we should keep the actual programing things away from the shortcuts.

[Vengeance]

I agree with DaveG on his points.

The only conditionals I was thinking of were to allow messaging to your group automatically if your spell succeeded or fizzled.  This is pretty important in chain healing and other timing-intensive group tactics.

It wouldn't take too much to implement a ?: type operator in the macro language, I don't think.

- Venge

[DaveG]

Which would also mean commands would need return values.  I'm not sure all of the info needed for that is available client side.  Would take a fair bit of work, I think.

Allowing just boolean logic might be good.  I'm not really sure.  I agree that it probably could be done right, but I'm not convinced we really need it.  At least, not anytime soon.

[ThomPhoenix]

I see no need for scripting. Some commands are good but entire code inside a shortcut? I don't think so.
Besides, something even as simple as a pause command can allow for massive cheating:
/mine for gold
/pause
/mine for gold
/pause
/mine for gold
/pause
etc

The player would only need to position his character somewhere else when he succesfully mined an ore. But even simple logic could take this need away.

/mine for gold
If succesfull [/pause 120 seconds]
if unsuccesfull [/pause 3 seconds]
/mine for gold

etc

[Nividia Stormlance]

Something REALLY needed is a

/sticktarget

it keeps selected target until duel is finished or target is dead

It is wery unrealistic and annoying when I get killed in pvp because my taget dissapers.. suddently I have to click/target the player again.. how realistic is it that you cannot attack your target just because of some red thingy thing is not surrounding him?? The thing should at least stick on him..

[ThomPhoenix]

No. If you select the target and out of nothing it's deselected, it's either your mistake or maybe a bug.

To put it more clearly:
If you don't do anything strange like deselecting the target or activate some function that deselects the target, the target shouldn't be deselected.

[Balonik]

/mine for gold
If succesfull [/pause 120 seconds]
if unsuccesfull [/pause 3 seconds]
/mine for gold

How can it help? You can't mine at the same place no matter how long you wait.

And one more thing about mining: games are supposed to be funny and addictive. If you think it's funny or addictive to press one or two keys each 12 seconds for hours you must have autism.
Just make this game interesting not boring. This will prevent players from thinking about scripts.
BTW look at the way you learn skills: how many times you have to click to buy all needed knowledge between level 25 and 26 in any magic way? It's not RP, it's not fun... it just destroys mouse button.
I agree there shouldn't be any automatic chat, except already existing /away command.
I agree there shouldn't be a need for any scripts. Need for scripts indicates some boring and annoying aspects of game.

From PlaneShift main site:

The objective of the PlaneShift is to create a virtual fantasy world in which a player can start as a peasant in search of fame and become a hero.

Sometimes (especialy while mining and reading posts about too fast character advance) I'm afraid that the objective is to make us stay at that start point, just dreaming about fame and heroic life... actually digging coal all our lives. I hope I'm wrong...

Edited to add:

ThomPhoenix wrote:
Besides, something even as simple as a pause command can allow for massive cheating:
/mine for gold
/pause
/mine for gold
/pause

Cheating? Can you dig faster that way? Can you get more using such a script? No. You are even slower because you have to set longer pauses due to lag. Digging manually you can dig again as soon as you see message "you were not successful" what is faster than script. And using such a script you have to be in front of your computer all the time anyway. So where is the "cheating"? Or maybe you just love to press one key, wait, press one key, wait, press one key, wait... Is it a role playing maybe?