SRL Archive - MSI Archives

[INDENT]Hello :)

You may be confused about the title, but don't worry, I'll do my best to explain. Right now, MSI is based around the support of multiple skills, whereas I think it should be based around multiple scripts. This is a much bigger change then you may think. It involves changing some types, and a whole lot of code throughout the core, but I think it will make things much easier in the long run.

Currently, the user specifies the skills they want to macro, and since we only have woodcutting, that's all they can do. However, what if the user wants to chop and bank normal, oak and yew trees at Varrock East bank? They can, as long as all three tree types are in the same area and the script doesn't go off course due to clicking the different trees. The latter is very unlikely considering the surplus of normal trees around Runescape.

So, by replacing the skills with scripts we very easily add NextScript (which is what was planned for NextSkill), which can automatically change the skill. This whole process will involve a lot of work, and I'm more than happy to take on the challenge, but of course I would keep you guys in touch about everything.

Off the top of my head, what would need to be changed are:

• TPlayerSkillInfo –> TPlayerScriptInfo
[PHP] type TPlayerSkillInfo = record TotalTime : integer; TotalObj : integer; TotalLoads : integer; Level : integer; TotalEXP : integer; ObjQuants : array of integer; end; type TPlayerScriptInfo = record name : integer; // 'Varrock East Oaks' runtime : integer; // 02h, 25m, 33s tools : array of integer; // [ TOOL_HATCHET ] skill : integer; // SKILL_WOODCUTTING skillLevel : integer; // 99 exp : integer; // 1,486,564 loads : integer; // 500 item : integer; // LOGS_OAK itemAmount : integer; // 14,000 end; [/PHP] Along with this comes a lot of editing in the core (along with a re-organization of the progress report).
• DeclarePlayers would be much simpler, which is always good for the users:
[PHP] with Players[0] do begin Name := ''; Pass := ''; Nick := ''; Active := True; Pin := ''; PlayerSkills[0] := [SKILL_WOODCUTTING]; PlayerObjects[0] := [[OBJ_TREE_NORMAL]]; Integers[P_LOC] := LOC_VE_BANK; Booleans[P_BANK] := True; end; with Players[0] do begin Name := ''; Pass := ''; Nick := ''; Active := True; Pin := ''; Arrays[P_SCRIPTS] := [ SCRIPT_VE_TREES, SCRIPT_VE_OAKS ]; Integers[P_LOC] := LOC_VE_BANK; end; [/PHP]
• I think just overall it would make the core look more cleaner when we start adding multiple skills. Some procedures/functions that may need to be added:
• MSI_SetupScript(); -> To setup the individual script when it's time to switch
• We may need to add a Scripts.scar file to initially load all the scripts attributes, then the necessary ones can be updated during runtime.
• MSI_NextScript() -> To switch scripts after a certain amount of loads/materials.

What do you guys think? I think it will be much better for us. With what we currently have, it would be a nightmare to properly add script/skill switching. I just feel that in the direction MSI is going, this will benefit us the most.

The rest of the discussion for this topic can be found here.

Cheers,
Coh3n[/INDENT]

Interesting idea!
I agree with you. This would be better

From: Zyt3x
Interesting idea!
I agree with you. This would be better

Yeah, just makes sense to me. :) Thanks.

hummmm…

So if I'm in VE i'd have to make it

Arrays[P_SCRIPT] := [VE_Oaks, VE_Yews, VE_Normals] ?

I like it, but I think it needs a bit more thinking through. This does seem to make it very easy to add a new script. I definitely love that. Can't wait to be back in brussels on my own to spend some time on MSI :)

~RM

From: Rasta Magician
hummmm…

So if I'm in VE i'd have to make it

Arrays[P_SCRIPT] := [VE_Oaks, VE_Yews, VE_Normals] ?

I like it, but I think it needs a bit more thinking through. This does seem to make it very easy to add a new script. I definitely love that. Can't wait to be back in brussels on my own to spend some time on MSI :)

~RM

Yeah, that's how it would go. I haven't thought of a negative thing about this yet.

Moved to public, we'd like to hear what the rest of you have to say. :)

Well, there's something I think we need to add into the player setup with this way.

Script := [Varrock_VEM]
Objects := [ORE_IRON] // excludes tin & copper
(this would be extremely easy to setup if done from within the form anyway)

~RM

From: Rasta Magician
Well, there's something I think we need to add into the player setup with this way.

Script := [Varrock_VEM]
Objects := [[ORE_IRON]] // excludes tin & copper ===> Note: array of array of int
(this would be extremely easy to setup if done from within the form anyway)

~RM

The form could just include like.. a box, and if you check it, then it puts that ore in the "Objects" section. So the player can really customize what they want by picking which ores they want.

From: Rasta Magician
Well, there's something I think we need to add into the player setup with this way.

Script := [Varrock_VEM]
Objects := [ORE_IRON] // excludes tin & copper
(this would be extremely easy to setup if done from within the form anyway)

~RM

Yeah, I'm not sure why I left the objects part out. I don't think I was thinking about scripts other than VE Woodcutters. We could still do SCRIPT_VE_TIN, SCRIPT_VE_COPPER, SCRIPT_VE_IRON, but that would be less efficient. It also wouldn't really simplify DeclarePlayers from what it is now, but like you said, it should be easy with a form anyway.

The main point of this is the ease of adding new scripts. :)

I like this idea.
I'm just trying to make sense of how this would work xD

Each scripts should act like a 'plugin' of some sort. When you include it / select it from a list, then the main script (MSI Core) would load everything needed for the script to run + some information about what it does and who made it.
Location (also a location for the form, if we use ReadySteadyGo's location selection system), Levels needed, items needed and so on.

From: Zyt3x
Each scripts should act like a 'plugin' of some sort. When you include it / select it from a list, then the main script (MSI Core) would load everything needed for the script to run + some information about what it does and who made it.
Location (also a location for the form, if we use ReadySteadyGo's location selection system), Levels needed, items needed and so on.

That would all be included in a TScript type if that's the route we choose.

From: Coh3n
That would all be included in a TScript type if that's the route we choose.

Sounds like a good route to me.

~RM

From: Rasta Magician
Sounds like a good route to me.

~RM

Okay, we've got a lot of work to do.

At first I was against this, but now that I think of it I get that it will make some things easier. For example instead of having a magic skill, we can have a dummy curser, alcher, and a superheater separated which will ease the scripting progress a lot. :) Basically you can just write one of those in a day, test it, and move to another one without having to use or edit stuff you wrote before.

EDIT: Some ideas:

• Instead of having SCRIPT_VE_TREES and SCRIPT_VE_OAKS just have SCRIPT_VE_WC
and still have Arrays[P_OBJECTS] etc. but so that they will be filled in a way that fits in the script. In some scripts there are no objects and other things like that, so in those cases the arrays can be left empty. This should also be taken into concern when building the form, since we don't want unnecessary text fields, but I think I make a post about that later to the form-thread.
• Make separate scripts to things where people actually want separate scripts. VEM should support all rocks there, but a guildminer should be a separate script like it usually is. Alcher and Superheater could be put in the same script, but again people don't want that.
• Let's not focus on script switching before we have scripts between which we can change.

Full support ^

~RM

I agree with everything there (E: just realized what I'm about to disagree with was 2 of your 3 points :p) except the combining of the scripts (your VE example). If we did that, we would run in to the exact same problem I came across last week (which lead me to making this thread). It would work if all the tree types were in the same area, but even then the walking would probably mess up (it would get lost chopping normal trees).

I think each script should be separate. There will still be a PlayerObjects array so the script will chop all the trees if they're found. VE is a good example where choosing the script is more of choosing the location the player will walk to. I don't think combining some and separating some is the way to go. We should stay consistant, and separating everything will make adding new scripts 100% easier, trust me.

Relocate(where:integer) ftw ?

Especially with reflection ?

~RM

From: Coh3n
I agree with everything there (E: just realized what I'm about to disagree with was 2 of your 3 points :p) except the combining of the scripts (your VE example). If we did that, we would run in to the exact same problem I came across last week (which lead me to making this thread). It would work if all the tree types were in the same area, but even then the walking would probably mess up (it would get lost chopping normal trees).

I think each script should be separate. There will still be a PlayerObjects array so the script will chop all the trees if they're found. VE is a good example where choosing the script is more of choosing the location the player will walk to. I don't think combining some and separating some is the way to go. We should stay consistant, and separating everything will make adding new scripts 100% easier, trust me.

But if you have SCRIPT_VE_TREES and SCRIPT_VE_OAKS, will it first chop only normal trees and then when the "script" changes it starts chopping oaks?

From: Rasta Magician
Relocate(where:integer) ftw ?

Especially with reflection ?

~RM

That would just make it unnecessarily complicated. We would need to check somewhere if the script is multilocation, then call Relocate accordingly. Why would we have that when we can just call NextScript for everything?

From: marpis
But if you have SCRIPT_VE_TREES and SCRIPT_VE_OAKS, will it first chop only normal trees and then when the "script" changes it starts chopping oaks?

No. VE isn't a very good example as a banking script that would cut multiple types of trees in one run because the trees aren't close enough together to all be seen on the mainscreen. The user can still input multiple trees if they wish (just like now), and if the script finds them, it'll cut them.

If we were to combine them, we would run into the complications I was having that lead me to make this thread (I think I already said that :p).

Coh3n, I'm not sure what you got what I meant by Relocate, and I'm not sure I explained it properly.

Perhaps ReCenter() would be better. Basically, it just makes the player walk to a point in the map where you know the player should be able to perform his task well enough,

eg: You don't find any fishing spots on the water, therefore you ReCenter to the fishing symbol.

Makes more sense now? Avoids the player getting lost.

~RM

Yeah, we should have that feature no matter what. But combining the scripts just wouldn't work like you guys think it would. The trees are so far from each other we would need to make a separate path for each tree if we want it to work properly. It would require a lot more effort then needed. Just overall I think it would be much more neat and organized if we kept everything as individual scripts.

You could call relocate if a tree isn't found, but chances are that it would have two or three points to relocate to. It would just save a lot of hassle to keep them separate.

Keep them separate we shall then. Any other questions? :p

~RM

From: Rasta Magician
Keep them separate we shall then. Any other questions? :p

~RM

Nope. :p I'm going to be starting the work tonight, and I'm going to make a new thread soon.

E: http://villavu.com/forum/showthread.php?p=719674#post719674

I dont really know what TPlayerScriptInfo is, but if it is something defined at the top of a script to tell the overall program where, what, how, and whatnot, then i quite like that.

to me this seems like you're moving away from msi bein an include and msi being an aggregation of scripts.

From: Dan Cardin
I dont really know what TPlayerScriptInfo is, but if it is something defined at the top of a script to tell the overall program where, what, how, and whatnot, then i quite like that.

to me this seems like you're moving away from msi bein an include and msi being an aggregation of scripts.

TPlayerSkillInfo was a type that stored all the necessary information for each skill that each player performs. That type has been (will be when I'm finished) replaced with TScript which holds all the information for each script for each player.

Although MSI can be used as an include, it's not really. It's more of a AIO (literally) script.

oh, i thought the TScriptInfo would be something declared at the top of a script to tell msi which skills it could do, where, and such.

From: Dan Cardin
oh, i thought the TScriptInfo would be something declared at the top of a script to tell msi which skills it could do, where, and such.

Well there's going to be a Scripts.scar where all the script types are loaded. So that will be where MSI gets all the script information.

is it all hardcoded into scripts.scar? I mean, i think it would make more sense for the script to tell msi what's in it rather than a seperate file. Like if a script was updated and supported more places or something, just update the script rather than both.

From: Dan Cardin
is it all hardcoded into scripts.scar? I mean, i think it would make more sense for the script to tell msi what's in it rather than a seperate file. Like if a script was updated and supported more places or something, just update the script rather than both.

I don't really know what you're trying to say. The script will be loaded just like TItems and TMSObjects. They'll be very easily updateable as you would just update the script/object/item records.

I agree with Dan Cardin..
Have something like LoadScript() or some global variables to fill in

scriptVars: TScriptInfo;
begin
  with scriptVars do
  begin
    nameOfScript := 'Varrock East Oaks';
    toolsNeeded := [TOOL_HATCHET];
    skills := [SKILL_WOODCUTTING];
    item := [LOGS_OAK, LOGS_WILLOW];
  end;  
end;

declared at the top of the script?

That's what Script.scar will looks like. I think there was a misunderstanding somewhere. Take a look at this thread, and I think you'll know what I mean.

http://villavu.com/forum/showthread.php?t=57568

but why do that in a seperate file. The script is in one file, so the script info should be taken from the same file, no?

Heh, I think I know where the misunderstanding is.

A TScript (btw, rather TScript than TScriptInfo) would be for one single location, always.

A script that does several locations can actually be broken down into several scripts (obviously) and this is what MSI would do.

Coh3n:
I'm not fully aware of your plans, but tomorrow I'll be back home. If we can catch each other on msn it'd be great, otherwise Sunday ;)

This should be sorted out before we add any other scripts to MSI, and I'm looking forward to adding that fisher.

Btw, GJ on the form everyone.

~RM

From: Rasta Magician
Heh, I think I know where the misunderstanding is.

A TScript (btw, rather TScript than TScriptInfo) would be for one single location, always.

A script that does several locations can actually be broken down into several scripts (obviously) and this is what MSI would do.

Coh3n:
I'm not fully aware of your plans, but tomorrow I'll be back home. If we can catch each other on msn it'd be great, otherwise Sunday ;)

This should be sorted out before we add any other scripts to MSI, and I'm looking forward to adding that fisher.

Btw, GJ on the form everyone.

~RM

Alright, I should be able to talk to you before I leave for my cottage. I'm slowly getting this done (I think I'm almost there).

Actually now that I think about it, i hope your "scripts" are all just walking and such (such including banking, randoms, etc). rather than actual scripty scripts wherein you put all the skill specific stuff in the script directly.

From: Dan Cardin
Actually now that I think about it, i hope your "scripts" are all just walking and such (such including banking, randoms, etc). rather than actual scripty scripts wherein you put all the skill specific stuff in the script directly.

I've already committed this (if you've seen the other thread), and it seems to be working quite well. You can take a look at the script records in Scripts.scar if you wish. :)