SRL Archive - General

Recently, I've been using my army A LOT to make a bunch of RS cash, and I've made two private scripts because they would kind of be a pain to add to MSI. This is bad. We want ANY type of script to be very easy to add to MSI. So, I think we need to pool together ideas of how to maky adding new skill/types of scripts a lot easier.

1. A TSkill record to get rid of the several skill cases around MSI.
2. One record for each skill: http://villavu.com/forum/showthread.php?t=61120

Don't be afraid to throw anything out there! Also, if there are ideas floating around in the forum that may help this situation, add it to the list (with a link).

From: Coh3n
Recently, I've been using my army A LOT to make a bunch of RS cash, and I've made two private scripts because they would kind of be a pain to add to MSI. This is bad. We want ANY type of script to be very easy to add to MSI. So, I think we need to pool together ideas of how to maky adding new skill/types of scripts a lot easier.

1. A TSkill record to get rid of the several skill cases around MSI.

Don't be afraid to throw anything out there! Also, if there are ideas floating around in the forum that may help this situation, add it to the list (with a link).

If we were to make a TSkill record, it would require writing an entire new portion of the include to handle the most general types of everything.

The way I see it, it would just end up being pointers at the functions which are already made, but what happens when the function isn't made? A new one must be made anyway, so the point is gone then.. If you know what I mean?

From: 3Garrett3
If we were to make a TSkill record, it would require writing an entire new portion of the include to handle the most general types of everything.

The way I see it, it would just end up being pointers at the functions which are already made, but what happens when the function isn't made? A new one must be made anyway, so the point is gone then.. If you know what I mean?

Yeah I know what you mean. That was just an idea; I hadn't though about it much. Either way I think things can be made easier, it's just a matter of finding the right way to do it.

I honestly dont know what would work better, I was just throwing some input into the discussion. I don't think that TSkill records would help at all, because the functions still need to be made, it's not like there is a general function for each skill, each one has its own special functions, which aren't likely easily called from a single record.

From: 3Garrett3
I honestly dont know what would work better, I was just throwing some input into the discussion. I don't think that TSkill records would help at all, because the functions still need to be made, it's not like there is a general function for each skill, each one has its own special functions, which aren't likely easily called from a single record.

You're right. I just went through the include, and there's really no way to effectively do it. There's still ways I think we can make it easier, just not with a record.

Throw those ideas out here then ;)

From: 3Garrett3
Throw those ideas out here then ;)

Yeah, they kind of flopped. Good news, though. It turns out there really isn't much to adding a new skill (include-wise), so I gathered all that information so I'll be able to update the "how-to" scripting guide soon.

Hmmm.. TSkill might be the way to go here after all…

Think about it… TScript is for scripts, but there's much more to script than skills. There's scripts for quests, walking, collectors and so on…

The problem is that the skills all differ so much, so the real quiz here is to design the TSkill record so that it works with ALL of them…

But Garret has some good points there….

Could think about this also

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

From: Coh3n
Could think about this also

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

Yes, what happened to that thread anyways? It kinda just died :(
Added it to the first post

It's a lot of work, and other things came up.

Was just looking a TScriptSetup, and honestly, it's really not that bad. I mean, the way it is now, it can still work for every skill, except everything in in one type, rather than several. So I don't think splitting them up would make it any more organized/easier to follow.

(*
TScriptSetup
~~~~~~~~~~~~

Used to make it easier for users to setup and for scripters to follow the code
around the include.
*)
type
  TScriptSetup = record
    Name      : Integer;

    // Not working until multiple script support
    Loads    : Integer; // Total loads to do for a specific script
    Time     : Integer; // Total time for a specific script
    MaxLevel : Integer; // The maximus skill level for that script

    // Woodcutting, Mining, and Fishing
    Rocks       : TIntegerArray;
    Trees       : TIntegerArray;
    FishSpots   : TIntegerArray;
    Priority    : TIntegerArray;
    DontDrop    : TIntegerArray; // The items the user doesn't want dropped/banked
    Exceptions  : TIntegerArray; // The inventory slots the user doesn't want dropped/banked

    // Magic
    Spells    : TIntegerArray;
    Staffs    : TIntegerArray;
    StaffType : TStaffType;
    AlchSlots : TIntegerArray;

    // Fighting
    Monsters     : TIntegerArray;
    Loot         : TIntegerArray;
    RunDirection : String;

    // Cooking
    CookingSpot : TIntegerArray;
    Recipe      : Integer;

    // Not setup by the user
    Items     : array of TIntegerArray;
    MaxCasts  : TIntegerArray; // Maximum casts for each spell (calculated in MSI_SetupMagic)
  end;

But does it support walkers/collectors/questers?

From: Zyt3x
But does it support walkers/collectors/questers?

If it doesn't, we just add the attribute that's needed. I never thought about it like this before, but if you think about it, ANYTHING needed for that specific script/skill can be used in it's file. Look at TScript: we have PlayerSetup, AutoObjects, and BankMaterials. What else is there?

• Walker
PlayerSetup would involve getting the player's location, then simply walking the path in the TScript record. AutoObjects and BankMaterials would just be nil.
• Collectors - Clay Softener, or example:
PlayerSetup would involve checking the players location, and making sure there's clay in the inventory. AutoObjects would be to use the clay on the fountain until they're all made into soft clay. BankMaterials would be a banking function that deposits the soft clay, then withdraws clay.
• Questers
Questers would be a little more difficult, but I'm assuming each quest would have their own file, in which case you would just have a player setup procedure like normal, then you would set AutoObjects := @MSI_DoDemonSlayer; where DoDemonSlayer would do the entire quest.