Alright, I tried to write a simple (semi-formal) grammar for a state-based language. It still lacks some stuff like iteration, function definitions and variables...

Transition: State -> State {if Condition}

Condition: bool | bool or bool | bool and bool | not bool | bool xor bool

State: <identifier> \n Function {if Condition} | Interaction {if Condition} \n ...

Interaction: @{identifier} Entity

Entity: obj(identifier) | npc(identifier) | obj(identifierlist) etc

Array: [e_1, ... e_n]

Map: {k_1:v_1, ... k_n:v_n}

Function call: func(arg_1, ... arg_n) | func   ------ func := func()

------------------------------------------------------------------------------------------------

Example woodcutting script (assuming a working webwalking implementation):

Chop -> DoBank if inv_full
DoBank -> WalkTree if not inv_has(logs)
WalkTree -> Chop

<Chop>
@chop obj(tree) if not anim

<DoBank>
deposit_all(logs)

<WalkTree>
walk_obj(willow)


------------------------------------------------------------------------------------------------


API would include functions like:

inv_has
inv_amount
inv_size
inv_drop(item, amount)
inv_dropall(item)
inv_use(item1, item2)
inv_use(item, npc)
inv_use(item, obj)
inv_select(item)
inv_deselect(item)
inv_selected
inv_get(item)

withdraw(item, amount)
walk_pos(x,y{,z})
cast(spell,entity)
talk(npc, options)
...
...

Edited July 27, 201510 yr by Flamezzz

The idea is good and would help those who want to script but don't know how. In OmniPocket, I use my own minor script language (like OP highlights here) to create presets which allow more control for me (the script writer) within my own API without steering away from the AIO nature of the script. Now, of course, OP and I have different uses for this, but it's still a good idea.

Here's an example script that I am working on for a basic blackjacker:

#Pollinveach Blackjacking
#TODO: add positions, finalise
#also todo: work on luring -> house -> KO -> pickpocket twice

define HOUSE_POS {x, y, z}

walkto shantay_pass
tag SHANTAY "Shantay" NPC_TYPE
interact SHANTAY "Buy-pass"
tag PASS "Shantay Pass" OBJECT_TYPE
interact PASS "Go-through"
walkto pollninveach

#and so forth

It looks a bit complicated here, but everything is handled by the API:

• Walks to shantay_pass (internal var)
• Locates the nearest "Shantay" NPC and buys a pass
• Locates the nearest pass object and goes through it
• Walks to pollninveach (internal var)

 

I very much think that having a minor scripting language for OSBot will attract those who are looking for baby steps to create scripts. Of course, having java should still be an option, however.

 

I like the declarative style you got going on Are you using an interpreter or are you compiling to Java source code?

Alright, I tried to write a simple (semi-formal) grammar for a state-based language. It still lacks some stuff like iteration, function definitions and variables...

Transition: State -> State if Condition

Condition: bool Op Condition | bool

Op: or | not | and | xor

State: <identifier> \n Function if Condition | Interaction if Condition \n ...

Interaction: @{identifier} Entity

Entity: obj(identifier) | npc(identifier) | obj(identifierlist) etc

Array: [e_1, ... e_n]

Map: {k_1:v_1, ... k_n:v_n}

Function call: func(arg_1, ... arg_n) | func   ------ func := func()

------------------------------------------------------------------------------------------------

Example woodcutting script (assuming a working webwalking implementation):

Chop -> DoBank if inv_full
DoBank -> WalkTree if not inv_has(logs)
WalkTree -> Chop

<Chop>
@chop obj(tree) if not anim

<DoBank>
deposit_all(logs)

<WalkTree>
walk_obj(willow)


------------------------------------------------------------------------------------------------


API would include functions like:

inv_has
inv_amount
inv_size
inv_drop(item, amount)
inv_dropall(item)
inv_use(item1, item2)
inv_use(item, npc)
inv_use(item, obj)
inv_select(item)
inv_deselect(item)
inv_selected
inv_get(item)

withdraw(item, amount)
walk_pos(x,y{,z})
cast(spell,entity)
talk(npc, options)
...
...

 

 

Very nice The declarative style you use for the transitions is extremely appealing. I fixed up the grammar a bit (I might come back to this as a reference), just made Condition recursive to allow "if bool and bool or bool ..." instead of the kleene closure on the "if Condition".

 

The lexical analyzer I currently have does not account for whitespace. Would you find it preferable if it did? Wasn't sure if I should account for it or not, as most languages now-a-days (excluding python and a few others of course) don't account for it.

Edited July 27, 201510 yr by fixthissite

we nearly had something like this in the past... now what was it called again...

 

I heard, however mine is more for private internal use. Just gave an example on how you can really simplify scripting with something like that.

I like the declarative style you got going on Are you using an interpreter or are you compiling to Java source code?

 

Mine is simply an interpreter with it's own node system for running the scripts.

This is the best way for me (for internal use), however you're definitely not going to want to even consider this approach.

 

Reasons I see for not using this:

 

- Another spot bugs can come up, and since its not supported by the client devs it would be unknown timeframes for patches/fixes.

 

- Want the communities help? Good luck lol

 

- Building custom frameworks seems out of reach with this system, as it doesn't support those elements that you want to remove (such as classes, extending, etc). Look through the main API, it utilizes a lot of these features for good reason. Not everything extends "Script".

 

Most of your arguments seem silly. If its really about how much your typing, then your so lazy I can't even fathom it. If its about simplicity, just make a higher level API. If its about supporting new users who don't know how to program, this might benefit some.

 

I know I would never be caught dead using this system. Feels like MacroSuite but instead of a GUI its a language. I prefer to being able to gut/rewrite parts I need to, and I believe this system wouldn't support it or make it more difficult than its worth.

 

I hope not to discourage you, but just sharing my opinion. It would be a good learning experience for the people involved in the project, and probably a fun project to boot. Just don't expect it gaining mainstream attention (until you have something to show) :\

 

Sorry if I sound like an old, pessimistic asshole but that is what I am

Edited July 27, 201510 yr by dudeami

Reasons I see for not using this:

- Another spot bugs can come up, and since its not supported by the client devs it would be unknown timeframes for patches/fixes.

- Want the communities help? Good luck lol

- Building custom frameworks seems out of reach with this system, as it doesn't support those elements that you want to remove (such as classes, extending, etc). Look through the main API, it utilizes a lot of these features for good reason. Not everything extends "Script".

Most of your arguments seem silly. If its really about how much your typing, then your so lazy I can't even fathom it. If its about simplicity, just make a higher level API. If its about supporting new users who don't know how to program, this might benefit some.

I know I would never be caught dead using this system. Feels like MacroSuite but instead of a GUI its a language. I prefer to being able to gut/rewrite parts I need to, and I believe this system wouldn't support it or make it more difficult than its worth.

I hope not to discourage you, but just sharing my opinion. It would be a good learning experience for the people involved in the project, and probably a fun project to boot. Just don't expect it gaining mainstream attention (until you have something to show) :\

Sorry if I sound like an old, pessimistic asshole but that is what I am

Thats fine, everyone has their opinions. But what system are you referring to? Any new language in general?

Thats fine, everyone has their opinions. But what system are you referring to? Any new language in general?

 

Language/System = BotScript

Language/System = BotScript

So you're saying anything other than Java would be a bad idea? Even if it supports creating type hierarchies?

So you're saying anything other than Java would be a bad idea? Even if it supports creating type hierarchies?

 

No, saying the examples I've seen on of "BotScript" are not up to par with what I'd expect. If you used Javascript to run a bot that would be interesting, along with Python or any language that has been developed for a while and has a large developer base to keep it moving along.

No, saying the examples I've seen on of "BotScript" are not up to par with what I'd expect. If you used Javascript to run a bot that would be interesting, along with Python or any language that has been developed for a while and has a large developer base to keep it moving along.

I haven't shown any examples of BotScript. And keep in mind, this has to run on the JVM. I'm sure people have created subsets of the ECMA that compile to bytecode, but I don't think anyone in their right mind would write a compiler that targets the JVM which is fully compatable with the specification.

Bugs arise from complex specifications. It would be a lot easier for a beginner to create a bugged script using Java than they would using a language with very strict specifications, not to mention a compiler which can give script related warnings/errors.

Verbosity is a huge factor in programming. It's not about being lazy. It's about saving time.

I can understand if you don't feel it's worth it. You could just use a project template to do all the boilerplate typing for you. But a new language will allow us to do things other languages have not accounted for if we find something suitable.

Edited July 27, 201510 yr by fixthissite