SRL Archive - General

Function Planning


Sir R. M8gic1an

2009-09-09 22:04:03

Ok guys, this will possibly be the most complicated part.

We will need to plan all the functions which are needed, and their exact params. Why?

We won't be doing the script. The community will; (of course we can join in ;) )
And so, to be sure everything is compatible we have to give them somewhat strict guidelines.

The actual inside of any function/procedure is flexible, but we need to make sure the right params are used so it makes the job easier for us.

What do I want as an end result?

//function needs to find tree 'which' using the TTree type and returning the tree position to (x, y).
//Returns true if tree 'which' found.
Function FindTree(which: TTree; var x, y:integer):boolean;
//function needs to find rock 'which' using the TRock type and returning the rock position to (x, y).
//Returns true if tree 'which' found.
Function FindRock(which: TRock; var x, y:integer):boolean;
//needs to detect which is the best pick the player can wield,
//and then find the best pick available which the player can wield in bank.
//Returns which pick it is in the form of a TObj type to 'which' and returns true if pick withdrawn
Function WithDrawBestPick(var which: TObj): boolean;
//same as for WithDrawBestPick but for woodcutting axes
Functon WithDrawBestAxe(var which: TObj): boolean;

This way, we can then post a list in the MSI SVN forums and the other SRL Members can contribute.

Getting the list of needed functions will be complicated and hard work, or to say the least, a lot of thinking.

Here is how i go about it:
I want to woodcut
– I need an axe
—- I might need to withdraw my axe
—— I want to withdraw the best axe i can use
– I need to walk to the trees
– I need to find the tree
—- I need to not lose track of the tree
—— I have to wait until the tree is gone
– I need to bank my load

And therefore we need a set of functions for each of those. Even worse, we need an easy way to link them (for those that need to be linked).

I believe the best way to do this is to actually make the function headers. If you are doing this for a skill, perhaps looking at a good script for that skill can give you an idea of what function's you'll need.

Using passable variables and types will be helpful here.

This thread is not here for us to start planning the functions, it is here for us to discuss how to plan, if there are any questions or suggestions.

~RM

Cazax

2009-09-10 02:53:50

How will we sort the functions?
I think posting a single thread for every function will quickly fill the forum.
I suggest:
Title: [wc]Tree related functions.
Post:
Function FindTree(args);
///////////
Function WhileChopping(args);
///////////
Function IsChopping(args);
So we could sort it by skill or by stage.

Sir R. M8gic1an

2009-09-10 03:08:06

I'd think a sticky in MSI SVN, with a list of all the fuctions needed.

Walking Paths needed
- VEB to VEM
- VEB to Church Yew
- VWB to Anvil
- VWB to West Oaks

WC Functions needed:

//description
Function FindTree(args);
//description
Function WhileChopping(args);
//description
Function IsChopping(args);

Mining functions needed:

//description
function FindRock(args):boolean;
//description
function followRock(args):boolean;
//description
function WaitRock(args):boolean;


something like that i'd say.

~RM

Coh3n

2009-09-10 05:36:12

From: Rasta Magician
I'd think a sticky in MSI SVN, with a list of all the fuctions needed.

Do you plan on having a sticky for each city? I think that would be much more organized.

I also think that the functions list should be more spaced out. It was a pain to read the comments in the one you have. I wasn't sure which comments were for which function.
From: Rasta Magician


//function needs to find tree 'which' using the TTree type and returning the tree position to (x, y).
//Returns true if tree 'which' found.
Function FindTree(which: TTree; var x, y:integer):boolean;


//function needs to find rock 'which' using the TRock type and returning the rock position to (x, y).
//Returns true if tree 'which' found.
Function FindRock(which: TRock; var x, y:integer):boolean;


//needs to detect which is the best pick the player can wield,
//and then find the best pick available which the player can wield in bank.
//Returns which pick it is in the form of a TObj type to 'which' and returns true if pick withdrawn
Function WithDrawBestPick(var which: TObj): boolean;


//same as for WithDrawBestPick but for woodcutting axes
Functon WithDrawBestAxe(var which: TObj): boolean;

But it's up to you. :p

Coh3n

Blumblebee

2009-09-10 06:27:45

We should keep the FindRock & FindTree Functions to the same parameters, thus allowing to do function pointers (I think thats what they're called) To allow easy organization and simple linkage.

ex:

Type
TSkill = Record
FindObj: Function(TP:TPoint; Index: Integer): Boolean;
FindEquipt: Function: Boolean;
end;

var Skill: TSkill;

Function FindRock(TP: Tpoint; Index: Integer): Boolean;
begin
end;

Function FindTree(TP: TPoint; Index: Integer): Boolean;
begin
end;


begin
case SetUp of
'Mining':
begin
FindObj := @FindRock;
FindEquipt := @FindPickaxe;
end;
'Woodcutting':
begin
FindObj := @FindTree;
FindEquipt := @FindHatchet;
end;
end;
end.

Coh3n

2009-09-10 06:57:13

From: Blumblebee
We should keep the FindRock & FindTree Functions to the same parameters, thus allowing to do function pointers (I think thats what they're called) To allow easy organization and simple linkage.

I like that idea. The same can be done for all similar functions like this.

Blumblebee

2009-09-10 07:23:10

From: Coh3n
I like that idea. The same can be done for all similar functions like this.


thanks and yeah if we can build the general form of the script [like this], it will make the mainloop alot cleaner/easier to do.

Coh3n

2009-09-10 07:34:03

From: Blumblebee
thanks and yeah if we can build the general form of the script [like this], it will make the mainloop alot cleaner/easier to do.


Yeah for sure, it'll all come together smoothly soon enough. ;)

Sir R. M8gic1an

2009-09-10 14:20:03

From: Blumblebee
thanks and yeah if we can build the general form of the script [like this], it will make the mainloop alot cleaner/easier to do.



I do like the idea, but i'd say TSkill either works for all skills or we don't use it. There'll be a lot of thinking needed to make it work for all skills as some are completly different. But it might work…


Mining:
-- Setup -> SetupMining
-- Walk -> WalkToMine
-- FindIt -> FindRock
-- Track -> FollowRock
-- WaitWhile -> WaitUntilMined
-- WalkBack -> MineToBank

Fighting:
-- Setup -> GetEquip&Food
-- Walk -> WalkToMonster
-- FindIt -> FindMonster
-- Track -> GetInFight
-- WaitWhile -> WhileFighting (Eating, prayer, etc)
-- WalkBack -> WalkToBank (More food / inv full of drops)

RuneCrafting:
-- Setup -> Tiara / ammy, Ess
-- Walk -> WalkToAltar
-- FindIt -> [ FindTheAltar (while outside) GetToAltar (inside) Craft (inside) GetOutofAltar ]
-- Track -> @Empty
-- WaitWhile -> @Empty
-- WalkBack -> WalkToBank

Fletching:
-- Setup -> Get Knife & Logs
-- Walk -> @Empty
-- FindIt -> Click Knife, Logs, And make all
-- Track -> @Empty
-- WaitWhile -> Waits until all logs fletched. If level up(stops fletching) goes back to Find it
-- WalkBak -> @Empty

We could do it. We probably should shove in a banking function between Setup and Walk, and all banking needs would be dealt by that function.

Which would mean that we should also add Banking.scar to our list :)

~RM

Blumblebee

2009-09-10 16:29:34

From: Rasta Magician
I do like the idea, but i'd say TSkill either works for all skills or we don't use it. There'll be a lot of thinking needed to make it work for all skills as some are completly different. But it might work…


Mining:
-- Setup -> SetupMining
-- Walk -> WalkToMine
-- FindIt -> FindRock
-- Track -> FollowRock
-- WaitWhile -> WaitUntilMined
-- WalkBack -> MineToBank

Fighting:
-- Setup -> GetEquip&Food
-- Walk -> WalkToMonster
-- FindIt -> FindMonster
-- Track -> GetInFight
-- WaitWhile -> WhileFighting (Eating, prayer, etc)
-- WalkBack -> WalkToBank (More food / inv full of drops)

RuneCrafting:
-- Setup -> Tiara / ammy, Ess
-- Walk -> WalkToAltar
-- FindIt -> [ FindTheAltar (while outside) GetToAltar (inside) Craft (inside) GetOutofAltar ]
-- Track -> @Empty
-- WaitWhile -> @Empty
-- WalkBack -> WalkToBank

Fletching:
-- Setup -> Get Knife & Logs
-- Walk -> @Empty
-- FindIt -> Click Knife, Logs, And make all
-- Track -> @Empty
-- WaitWhile -> Waits until all logs fletched. If level up(stops fletching) goes back to Find it
-- WalkBak -> @Empty

We could do it. We probably should shove in a banking function between Setup and Walk, and all banking needs would be dealt by that function.

Which would mean that we should also add Banking.scar to our list :)

~RM


Ok Banking.scar would be an easy addition, and I think we can make it work. I'm also a big fan of using Records for color finding, we could make a color.scar library for object finding? A simple Universal Object finding function (I got a few kicking around) and then just a massive color library that can be called via an Index). I think that would be the simpilest and timesaving/line saving thing we could do (If you want to add another object you simply add a array to the record in about 2 minutes and your set).

Coh3n

2009-09-10 17:45:38

From: Blumblebee
Ok Banking.scar would be an easy addition, and I think we can make it work. I'm also a big fan of using Records for color finding, we could make a color.scar library for object finding? A simple Universal Object finding function (I got a few kicking around) and then just a massive color library that can be called via an Index). I think that would be the simpilest and timesaving/line saving thing we could do (If you want to add another object you simply add a array to the record in about 2 minutes and your set).


Yeah I like that. Correct me if I'm wrong, but having a universal function would make it more efficient I would think.

NCDS

2009-09-10 20:00:17

From: Coh3n
Yeah I like that. Correct me if I'm wrong, but having a universal function would make it more efficient I would think.


And easier to read.

Sir R. M8gic1an

2009-09-10 21:16:35

Lovely. I'm glad you guys agree with the use of types.

I think that for the types we'll just make a Globals.scar (to keep the types in) and a colors.scar (with the necessary funcs to load the colors) which will keep the actual info.
I believe it's better to do it this way, otherwise it would get too crammed.

We will need several types:
- One for objects on MS (trees, rocks, etc)
- One for items in inv/bank (axes, logs, etc)
- Well need one for the progress report (I'll expand on this idea later)
- One will be used for the walking funcs (check the welking.scar thread)
- One for the skills n function pointers

any others? as you can see, there's a lot of them already, so we really are better off using two files.

~RM

Cazax

2009-09-11 01:43:35

From: Rasta Magician
Lovely. I'm glad you guys agree with the use of types.

I think that for the types we'll just make a Globals.scar (to keep the types in) and a colors.scar (with the necessary funcs to load the colors) which will keep the actual info.
I believe it's better to do it this way, otherwise it would get too crammed.

We will need several types:
- One for objects on MS (trees, rocks, etc)
- One for items in inv/bank (axes, logs, etc)
- Well need one for the progress report (I'll expand on this idea later)
- One will be used for the walking funcs (check the welking.scar thread)
- One for the skills n function pointers

any others? as you can see, there's a lot of them already, so we really are better off using two files.

~RM


  • MS Objects:
  • Type
    TMSObj = Record
    ObjP : TPoint;
    Colors : TIntegerArray;
    UpTexts : TStringArray;
    W, H : Integer; //For SplitTPAEx or TPAtoATPAEx
    End;
  • Inv/Bank items
  • Type
    TItem = Record; //Don't know if here is another type named TItem
    ItemP : TPoint;
    Stackable : Boolean;
    UpText, Name : String;
    End; //Anything more?
  • ProgressReport
  • - RM needs to expand
  • Walking
  • Type
    TWalk = Record;
    City : integer;
    Loc : integer;
    Path: TPointArray;
    End; //From Walking.scar thread
  • Skills and functions
  • - Don't know what could be here
Any comments? We can also take ideas from Reflection types.

NCDS

2009-09-11 04:02:40

From: Cazax
  • MS Objects:
  • Type
    TMSObj = Record
    TP : TPoint;
    Colors : TIntegerArray;
    UpTexts : TStringArray;
    W, H : Integer; //For SplitTPAEx or TPAtoATPAEx
    End;

Does taking a point from an array and setting it to a TPoint increase efficiency at all? I would think it would slow things down if anything. If so, I don't really see it necessary to include it in this. Why not just use tpa.x etc.? I guess it doesn't matter much either way.
From: Cazax

[*]Inv/Bank items
Type
TItem = Record; //Don't know if here is another type named TItem
TP : TPoint;
Stackable : Boolean;
UpText, Name : String;
End; //Anything more?

I understand the TPoint more on this one as many of SRL's Inv/Banking functions return TPoints.

The walking one seems fine too.

Coh3n

2009-09-11 07:21:40

From: NCDS
Does taking a point from an array and setting it to a TPoint increase efficiency at all? I would think it would slow things down if anything. If so, I don't really see it necessary to include it in this. Why not just use tpa.x etc.? I guess it doesn't matter much either way.

It's possible that it increases efficiency, but that's RM's expertise. ;) I think if we set it to a variable makes it more organized and easier to follow, but that's just me.

Ahhh Cazax, you are one of those people that capitalize bolded words, aren't you? And I think if you're going to use "TP" for TPoint, you should refrain from using it more than once. I think RM said something about that in another thread. It could be something like ObjTP, or ItemTP, know what I mean?

Cazax

2009-09-11 22:19:25

From: Coh3n
It's possible that it increases efficiency, but that's RM's expertise. ;) I think if we set it to a variable makes it more organized and easier to follow, but that's just me.

Ahhh Cazax, you are one of those people that capitalize bolded words, aren't you? And I think if you're going to use "TP" for TPoint, you should refrain from using it more than once. I think RM said something about that in another thread. It could be something like ObjTP, or ItemTP, know what I mean?

Yes I do capitalize bold words :p Ok I changed them to ObjP and ItemP. Now we need RM to say what's on progress report.

Sir R. M8gic1an

2009-09-11 23:03:59

From: Coh3n

Ahhh Cazax, you are one of those people that capitalize bolded words, aren't you? And I think if you're going to use "TP" for TPoint, you should refrain from using it more than once. I think RM said something about that in another thread. It could be something like ObjTP, or ItemTP, know what I mean?


Indeed i did say to avoid it, although here it would not be of major importance as it would be TObj.TP or with Tobj do TP.

For the progress report…
SRL's Report.scar has a small problem, or we do.
I would like to be able to keep ALL information of our autoers. That's a lot of information and variables, and SRL's proggies / player reports would just simply look huuuuuge and…. well huge. As in, wouldn't really fit in the screen.

That is why i wanted a type for the progress report, that would keep all that info and that it could then save all the details to a file or so.

Finally, i also wanted to have functions such as:

AddProggie(Activity_Mining, Ore_Iron, 26);
//this would add 26 iron ore to the player's report

~RM

Coh3n

2009-09-12 00:57:23

From: Cazax
Yes I do capitalize bold words :p Ok I changed them to ObjP and ItemP. Now we need RM to say what's on progress report.


Lol, I'll try to restrain myself from getting annoyed by that. :p

RM: A type as in something like this?

type
TReport = record
Lvls, Exp, Kills, Logs, Ores, Fish, Loads, Randoms, Antiban, Breaks: Integer;
Active, Loc, Nick: String;
end;
I'm sure I missed something… But is that the right idea? Or not even close?

Also, anyone know why "String" is bolded for me, but "Integer" isn't? Lol.

Blumblebee

2009-09-12 09:32:30

From: NCDS
Does taking a point from an array and setting it to a TPoint increase efficiency at all? I would think it would slow things down if anything. If so, I don't really see it necessary to include it in this. Why not just use tpa.x etc.? I guess it doesn't matter much either way.


it is needed. If you want to pixel follow/watch/want to keep an area of where you clicked. This can be used in woodcutting, mining, and fishing to see if you are still preforming an action. I use a method of object finding that is completely based on TPoints. and it would be used like "if FindUpText then TP := Point(TPA.x, TPA.y);"

Coh3n

2009-09-12 20:42:04

From: Blumblebee
it is needed. If you want to pixel follow/watch/want to keep an area of where you clicked. This can be used in woodcutting, mining, and fishing to see if you are still preforming an action. I use a method of object finding that is completely based on TPoints. and it would be used like "if FindUpText then TP := Point(TPA.x, TPA.y);"


That's basically the same idea I used in my woodcutters, and it seems to work pretty well.

Sir R. M8gic1an

2009-09-12 20:52:42

[php] __________________________________________________________________
| MSI Player Extreme Report |
|——————————————————————|
| PlayerName in PlayerCity at PlayerLoc |
| |
| PlayerName is at Fishing(skill1) level FishingLevel |
| PlayerName was Fishing for Time |
| PlayerName Fished a total amount of x fish |
| PlayerName Fished the following: x Fish1, y Fish2, z Fish3 |
| PlayerName earned a total of x Fishing exp |
| |
| PlayerName is at Mining(skill2) level MiningLevel |
| PlayerName was Mining for Time |
| PlayerName Mined a total of x ore |
| PlayerName Mined the following: x Ore1, y Ore2, z Ore3 |
| PlayerName earned a total of x Mining exp |
| |
| PlayerName is still good to go! (or) |
| PlayerName is no longer working for you. |
| Reason: PlayerName is in PlayerRand and is unable to keep on |
| playing. |
——————————————————————

[/php]

This is the sort of progress report I'd be hoping to see. As you can see, there are way too many vars for it to use SRL's Report.scar for a full report. I suggest that a proggy this big and in this style is saved to file, never pasted in the debug box. Then we can use SRL's Report.scar for a small proggy, like 'PlayerActive, CurrentActivity, InRandom, ActivityTime'.

For this proggie, it'd take a nice chunk of organization. What do you guys think?

~RM

Coh3n

2009-09-12 21:33:01

I think it looks awesome. Here's another look you can think about. Nothing against yours, RM, just adding some variety. :p

[PHP][==================================================================]
[ MSI Player Extreme Report ]
[==================================================================]
[ PlayerName in PlayerCity at PlayerLoc ]
[ ]
[ PlayerName is at Fishing(skill1) level FishingLevel ]
[ PlayerName was Fishing for Time ]
[ PlayerName Fished a total amount of x fish ]
[ PlayerName Fished the following: x Fish1, y Fish2, z Fish3 ]
[ PlayerName earned a total of x Fishing exp ]
[ ]
[ PlayerName is at Mining(skill2) level MiningLevel ]
[ PlayerName was Mining for Time ]
[ PlayerName Mined a total of x ore ]
[ PlayerName Mined the following: x Ore1, y Ore2, z Ore3 ]
[ PlayerName earned a total of x Mining exp ]
[ ]
[ PlayerName is still good to go! (or) ]
[ PlayerName is no longer working for you. ]
[ Reason: PlayerName is in PlayerRand and is unable to keep on ]
[ playing. ]
[ ]
[==================================================================][/PHP]

Sir R. M8gic1an

2009-09-12 21:36:30

From: Coh3n
I think it looks awesome. Here's another look you can think about. Nothing against yours, RM, just adding some variety. :p




Humm, i think you might have misunderstood me or I'm misunderstanding you :p My proggie was supposed to be for 1 player, and the divisions you put in yours seem to suggest several players?

Edit: About the actual looks, i don't mind much, i was just posting it so you guys have an idea for the type record that this would involve ;)

~RM

Coh3n

2009-09-12 22:26:33

From: Rasta Magician
Humm, i think you might have misunderstood me or I'm misunderstanding you :p My proggie was supposed to be for 1 player, and the divisions you put in yours seem to suggest several players?

Edit: About the actual looks, i don't mind much, i was just posting it so you guys have an idea for the type record that this would involve ;)

~RM


Oh okay, I thought that may be the case, but I wasn't sure, I'll change that post. So basically that would be an example of a player that fished a certain amount of fish, and then moved on to mining? I think that's pretty awesome to be quite honest. :)

EDIT: It ended up looking almost the exact same anyway. :p

Sir R. M8gic1an

2009-09-12 22:58:00


type
TPlayerSkillInfo = record
WhichSkill: integer;
SkillTime : integer;
TotalObj : integer;
TotalEXP : extended;
ObjQuants : array of integer; //TProggy.SkillInfo[Skill_Mining].ObjQuants[Ore_Iron]
end;


TProggy = record
PlayerName : string;
PlayerStatus: boolean;
PlayerRandom: string;
PlayerWhere : TWalk
SkillInfo : Array of TPlayerSkillInfo;
end;

var
PlayersReportArray: Array[0..HowManyPlayers] of TProggy;

That's what i'm thinking for the proggy. That should be able to store all info. Now let's all get our svn write access and start planning this file by file, function by function.

~RM