Author Topic: (advanced) script in EasyUO as an Object-oriented language  (Read 3711 times)

0 Members and 1 Guest are viewing this topic.

Offline b@nditoTopic starter

  • Jr. Member
  • **
  • Posts: 48
  • Activity:
    0%
  • Reputation Power: 0
  • b@ndito has no influence.
  • Respect: +5
  • Referrals: 0
    • View Profile
first of all i want to say that much of what i'm writing is not my work, mainly i'm translating documentation and parts of a really powerful script a user published on my freeshard forum.
this script is able to fill bods, swap it at vendors, choose what are good for rewards, what to fill again and what to trash and do it all until any bod is left (and you book is full of BoDs), also i've been able to insert a sub for bod gathering so basically this scripts goes over until the end of the world (up to now i've been able to run this non-stop for about 70hs).

but that's not much important, what's really interesting is how the author has been able to define reliable rules to script in euo as an OO language.

first of all it relies on creating a defined namespace for every sub called...

since i've not much time left let me translate the first part of the script's documentation, next time i'll describe it more in-deep.
Quote
HOW'S ORGANIZED THE SCRIPT

Since this is a rather complex script, a precise design of subs is necessary.
The script moves on various levels. The upper levels know and use the lower ones, but not vice-versa.
Each function is identified by a prefix, which indicates the level of membership.
You can pretend that they are like packages in Java.

LEVELS:
1 - Elementary functions (prefix: Std)
There are subs who are carrying out tasks simple and basic, with no dependencies on other subs.
It is generally "low level", "reusable", "reentrant" (do not depend on global variables)

2 - logic functions (prefix: Model)
Implement the logic of the script, regardless of configuration problems or the like.
Obeys a "design by contract" logic: claiming pre-conditions guaranteeing post-conditions.
Generally depend on some global variables.
They are the "model" in Model-View-Controller architecture.

3 - GRAPHIC FUNCTIONS (prefix: View)
Create the menu and run the loop.
[...]

4 - executive function (prefix: Ctrl)
They are the link between the GUI and the functions of logic level.
They often have similar names corresponding to the functions of the logic level, but they are on a higher level.
In fact, they require certain parameters from the user if needed, and are involved in the loop start process.
You can think of them as "Whatever that happens when you press a button."
This represents the "controller" in Model-View-Controller architecture.

making a quick example on how it works, before going:

when creating a menu in this way he first sets the variables, then call the pre-designed menu passing those variables as parameters, when menu is shown a sub is able to cycle every variable given before and store it.

in all this process the scripter just need to draw the menu and call it properly, other part is all done by the script/library i'll show you.
i repeat that way of scripting through this library is very pwerful and reliable, hope you can understand what i  mean and can be useful for much expert scripters.