SRL Archive - MSI Suggestions

Examples:
MSI_LoadItems(ITEMS_ORES);
MSI_LoadItems(ITEMS_FISHES);
MSI_LoadItems(ITEMS_LOGS);

Used in Scripts.simba in the scripts that do powerskilling (So you don't have to type all the different ores / logs / fishes and so on). Also adds possibilities to add a cooker to MSI.

1 Cooking script without MSI_LoadItems:

Items         := [
[FOOD_SHRIMP], [FOOD_CRAYFISH], [FOOD_ANCHOVIES], [FOOD_SARDINE], [FOOD_KARAMBWANJI], [FOOD_KARAMBWAN], [FOOD_HERRING], [FOOD_MACKEREL], [FOOD_TROUT], [FOOD_COD], [FOOD_PIKE], [FOOD_SALMON], [FOOD_SLIMYEEL], [FOOD_TUNA], [FOOD_RAINBOWFISH], [FOOD_CAVEEEL], [FOOD_LOBSTER], [FOOD_BASS], [FOOD_SWORDFISH], [FOOD_LAVAEEL], [FOOD_MONKFISH], [FOOD_SHARK], [FOOD_SEATURTLE], [FOOD_CAVEFISH], [FOOD_MANTARAY], [FOOD_ROCKTAIL],

[FOOD_MEAT], [FOOD_CHICKEN], [FOOD_RABBIT], [FOOD_ROASTBIRD], [FOOD_THINSNAIL], [FOOD_SPIDER], [FOOD_ROASTRABBIT], [FOOD_LEANSNAIL], [FOOD_ROASTBEAST], [FOOD_CRABMEAT], [FOOD_FATSNAIL], [FOOD_ROASTCHOMPY], [FOOD_FISHCAKE], [FOOD_JUBBLY],

[FOOD_BREAD], [FOOD_PITTA], [FOOD_PIE],

[FOOD_REDBERRYPIE], [FOOD_MEATPIE], [FOOD_MUDPIE], [FOOD_APPLEPIE], [FOOD_GARDENPIE], [FOOD_FISHPIE], [FOOD_ADMIRALPIE], [FOOD_WILDPIE], [FOOD_SUMMERPIE],

[FOOD_CAKE], [FOOD_CHOCCAKE],

[FOOD_STEW], [FOOD_CURRY],

[FOOD_PLAINPIZZA], [FOOD_MEATPIZZA], [FOOD_ANCHOVYPIZZA], [FOOD_PINEAPPLEPIZZA]
];

1 Cooking script with MSI_LoadItems:

Items         := MSI_LoadItems(ITEMS_FOOD);

With this, you'd also need something like this to be added in Globals.Simba:

PICKAXES_LOW=10;
PICKAXES_HIGH=15;

HATCHETS_LOW=20;
HATCHETS_HIGH=25;

LOGS_LOW=30;
LOGS_HIGH=35;

and

ITEMS_PICKAXES = 0;
ITEMS_HATCHETS = 1;
ITEMS_LOGS = 2;
ITEMS_ORES = 3;
ITEMS_FISHES = 4;

MSI_LoadItems would look something like this:

{******************************************************************************}
{ function MSI_LoadItems(whichItems : Integer): T2DIntegerArray;               }
{ By: Zyt3x                                                                    }
{ Date: 10 September 2010                                                      }
{ Description: Loads all the items that is needed for one single script.       }
{                   Should only be called when setting up a script!            }
{******************************************************************************} 
function MSI_LoadItems(whichItems : Integer): T2DIntegerArray;
var
  i, j : Integer;
begin
  case whichItems of
    ITEMS_PICKAXES:
      begin
        SetArrayLength(Result, PICKAXES_HIGH-PICKAXES_LOW+1);
        for i := PICKAXES_LOW to PICKAXES_HIGH do
        begin
          Result[j] := [i];
          Inc(j);
        end;
      end;
    ITEMS_HATCHETS:
      begin
        SetArrayLength(Result, HATCHETS_HIGH-HATCHETS_LOW+1);
        for i := HATCHETS_LOW to HATCHETS_HIGH do
        begin
          Result[j] := [i];
          Inc(j);
        end;
      end;
    ITEMS_LOGS:
      begin
        SetArrayLength(Result, LOGS_HIGH-LOGS_LOW+1);
        for i := LOGS_LOW to LOGS_HIGH do
        begin
          Result[j] := [i];
          Inc(j);
        end;
      end;
    ITEMS_ORES:
      begin
        SetArrayLength(Result, ORE_HIGH-ORE_LOW+1);
        for i := ORE_LOW to ORE_HIGH do
        begin
          Result[j] := [i];
          Inc(j);
        end;
      end;
    ITEMS_FISHES:
      begin
        SetArrayLength(Result, FISH_HIGH-FISH_LOW+1);
        for i := FISH_LOW to FISH_HIGH do
        begin
          Result[j] := [i];
          Inc(j);
        end;
      end;
    ITEMS_ITEM:
      begin
        SetArrayLength(Result, ITEM_HIGH-ITEM_LOW+1);
        for i := ITEM_LOW to ITEM_HIGH do
        begin
          Result[j] := [i];
          Inc(j);
        end;
      end;
  else
    // Debug
  end;
end;

What do you think? I see no downsides at all.

EDIT: Globals.simba:

(**
 * All the different items used throughout the MSI scripts
 *)
const
  ITEMS_PICKAXES  = 0;
  ITEMS_HATCHETS  = 1;
  ITEMS_LOGS      = 2;
  ITEMS_ORE       = 3;
  ITEMS_FISHES    = 4;
  ITEMS_ITEM      = 5;

  PICKAXE_LOW     = 10;
  PICKAXE_BRONZE  = 10;
  PICKAXE_IRON    = 11;
  PICKAXE_STEEL   = 12;
  PICKAXE_MITHRIL = 13;
  PICKAXE_ADAMANT = 14;
  PICKAXE_RUNE    = 15;
  PICKAXE_HIGH    = 15;

  HATCHET_LOW     = 20;
  HATCHET_BRONZE  = 20;
  HATCHET_IRON    = 21;
  HATCHET_STEEL   = 22;
  HATCHET_MITHRIL = 23;
  HATCHET_ADAMANT = 24;
  HATCHET_RUNE    = 25;
  HATCHET_HIGH    = 25;

  LOGS_LOW        = 30;
  LOGS_NORMAL     = 30;
  LOGS_OAK        = 31;
  LOGS_WILLOW     = 32;
  LOGS_MAPLE      = 33;
  LOGS_YEW        = 34;
  LOGS_MAGIC      = 35;
  LOGS_HIGH       = 35;

  ORE_LOW         = 40;
  ORE_CLAY        = 40;
  ORE_COPPER      = 41;
  ORE_TIN         = 42;
  ORE_IRON        = 43;
  ORE_SILVER      = 44;
  ORE_COAL        = 45;
  ORE_GOLD        = 46;
  ORE_MITHRIL     = 47;
  ORE_ADAMANTITE  = 48;
  ORE_RUNITE      = 49;
  ORE_HIGH        = 49;

  FISH_LOW        = 50;
  FISH_SHRIMP     = 50;
  FISH_CRAYFISH   = 51;
  FISH_SARDINE    = 52;
  FISH_HERRING    = 53;
  FISH_ANCHOVIE   = 54;
  FISH_TROUT      = 55;
  FISH_PIKE       = 56;
  FISH_SALMON     = 57;
  FISH_TUNA       = 58;
  FISH_LOBSTER    = 59;
  FISH_SWORDFISH  = 60;

  FISH_SMALLNET   = 70;
  FISH_CRAYPOT    = 71;
  FISH_ROD        = 72;
  FISH_BAIT       = 73;
  FISH_FLY        = 74;
  FISH_FEATHER    = 75;
  FISH_HARPOON    = 76;
  FISH_CAGE       = 77;
  FISH_HIGH       = 77;

  ITEM_LOW        = 80;
  ITEM_BIRD_NEST  = 80;
  ITEM_HIGH       = 80;

  ITEM_ARRAY_LENGTH = 80; // Change to the highest item constant

EDIT2: http://villavu.com/forum/showthread.php?t=58886 for an updated version including cooking stuff

Sooo much repeated code in that function! It also wouldn't work the way you want it to because you have it set only one item per object where there can be multiple items per object (fishing for example).

function MSI_LoadItemRange(Start, Finish: Integer): TIntegerArray;
begin
  SetLength(Result, (Finish - Start));
  for i := Start to Finish do
    Result[i] := i;
end;

procedure MSI_LoadScript(WhichScript: Integer);
begin
  // Blah blah
  Objects := [ COOKSPOT_RANGE, COOKSPOT_FIRE ];
  Items   := [ MSI_LoadItemRange(FOOD_LOW, FOOD_HIGH),
               MSI_LoadItemRange(FOOD_LOW, FOOD_HIGH), ]; // Yes, I know they're the same, but they may differ b/c IIRC some good can't be cooked on a fire/range

end;

Also, you have to change the item naming for some of them. Like pizza for example should be FOOD_PIZZA_PLAIN, FOOD_PIZZA_MEAT. I do like the HIGH/LOW idea you have. Means we wouldn't have to update the script records every time a new item is added.

I think we also need to come to a conclusion for item naming. One that works for fishing/cooking/whatever. For fishing right now we have:

FISH_SHRIMP = 0;
FISH_CRAYFISH = 1;
// etc.

And we don't want to have duplicates anywhere, so here's my proposal:

FISH_RAW_SHRIMP    = 10;
FISH_RAW_CRAYFISH  = 11;
FISH_RAW_ANCHOVIES = 12;
// etc..

FISH_COOKED_SHRIMP    = 20;
FISH_COOKED_CRAYFISH  = 21;
FISH_COOKED_ANCHOVIES = 22;
// etc..

PIE_RAW_REDBERRY = 30;
PIE_RAW_MEAT     = 31;
PIE_RAW_MUD      = 32;
// etc..

PIE_COOKED_REDBERRY = 40;
PIE_COOKED_MEAT     = 41;
PIE_COOKED_MUD      = 42;
// etc..

// Same goes for pizza, cake, etc.

Kind of got a little off topic, but at least it still has something to do with items. :p

From: Coh3n
Sooo much repeated code in that function! It also wouldn't work the way you want it to because you have it set only one item per object where there can be multiple items per object (fishing for example).

function MSI_LoadItemRange(Start, Finish: Integer): TIntegerArray;
begin
  SetLength(Result, (Finish - Start));
  for i := Start to Finish do
    Result[i] := i;
end;

procedure MSI_LoadScript(WhichScript: Integer);
begin
  // Blah blah
  Objects := [ COOKSPOT_RANGE, COOKSPOT_FIRE ];
  Items   := [ MSI_LoadItemRange(FOOD_LOW, FOOD_HIGH),
               MSI_LoadItemRange(FOOD_LOW, FOOD_HIGH), ]; // Yes, I know they're the same, but they may differ b/c IIRC some food can't be cooked on a fire/range

end;

Also, you have to change the item naming for some of them. Like pizza for example should be FOOD_PIZZA_PLAIN, FOOD_PIZZA_MEAT. I do like the HIGH/LOW idea you have. Means we wouldn't have to update the script records every time a new item is added.

I think we also need to come to a conclusion for item naming. One that works for fishing/cooking/whatever. For fishing right now we have:

FISH_SHRIMP = 0;
FISH_CRAYFISH = 1;
// etc.

And we don't want to have duplicates anywhere, so here's my proposal:

FISH_RAW_SHRIMP    = 10;
FISH_RAW_CRAYFISH  = 11;
FISH_RAW_ANCHOVIES = 12;
// etc..

FISH_COOKED_SHRIMP    = 20;
FISH_COOKED_CRAYFISH  = 21;
FISH_COOKED_ANCHOVIES = 22;
// etc..

PIE_RAW_REDBERRY = 30;
PIE_RAW_MEAT     = 31;
PIE_RAW_MUD      = 32;
// etc..

PIE_COOKED_REDBERRY = 40;
PIE_COOKED_MEAT     = 41;
PIE_COOKED_MUD      = 42;
// etc..

// Same goes for pizza, cake, etc.

Kind of got a little off topic, but at least it still has something to do with items. :p

Yeah, lots of repeated code because at first I only put ITEMS_PICKAXES in it, and then I thought "I could just add the rest too…"…
What do you think about it though? Do you like the idea? and yeah, pies and pizzas and such can not be cooked on a fire.

The names were not intended to be for MSI, I just copied them from my other script :p Yeah, we will name them properly of course.
Yeah, and I see a lot of loops that's like this: "for i := HATCHET_BRONZE to HATCHET_RUNE do" that would also be a problem if i.e we/Jagex adds another hatchet

I like the FISH_RAW stuff :o

From: Zyt3x
Yeah, lots of repeated code because at first I only put ITEMS_PICKAXES in it, and then I thought "I could just add the rest too…"…
What do you think about it though? Do you like the idea? and yeah, pies and pizzas and such can not be cooked on a fire.

I'm all for the idea, that's why I wrote up LoadItemsRange. ;)

From: Zyt3x

I like the FISH_RAW stuff :o

As in you like the naming? :)

From: Coh3n
I'm all for the idea, that's why I wrote up LoadItemsRange. ;)

As in you like the naming? :)

Ah, I see…

Yep :p I didn't know what more to write, hence the ":redface:"


So we'll add MSI_LoadItemRange, HIGH & LOW and rename the constants that needs to be renamed… Anything else?

From: Zyt3x
Ah, I see…

Yep :p I didn't know what more to write, hence the ":redface:"


So we'll add MSI_LoadItemRange, HIGH & LOW and rename the constants that needs to be renamed… Anything else?

Nope, I think that's good. For this thread anyway. :)

Commited these changes and added support for cooking.simba

From: Zyt3x
Commited these changes and added support for cooking.simba

Looks good. :) Couple things:

• LOC_VE_COOK > LOC_VE_RANGE (more specific/descriptive)
• In MSI_GetDTMPoints, you forgot to change LOGS_NORMAL > LOGS_LOW and PICKAXE_BRONZE > PICKAXE_LOW. I also didn't see ORE_CLAY..ORE_RUNITE changed either.

Everything else looks wonderful. :p

From: Coh3n
Looks good. :) Couple things:

• LOC_VE_COOK > LOC_VE_RANGE (more specific/descriptive)
• In MSI_GetDTMPoints, you forgot to change LOGS_NORMAL > LOGS_LOW and PICKAXE_BRONZE > PICKAXE_LOW. I also didn't see ORE_CLAY..ORE_RUNITE changed either.

Everything else looks wonderful. :p

Fixed those on my file already :)
And I wanted to add some more stuff, but where the heck is the SKILL_ constants located at?! >_<

From: Zyt3x
Fixed those on my file already :)
And I wanted to add some more stuff, but where the heck is the SKILL_ constants located at?! >_<

Players.scar in SRL. :p

From: Coh3n
Players.scar in SRL. :p

Oh lol, that's why I didn't find them :redface: :duh:

I even made a script to search my entire MSI for scripts that include the word "SKILL_"… http://pastebin.ws/2jknrs

I didn't change ORE_CLAY … ORE_RUNITE in MSI_GetDTMPoints because their'e points differ, and leaving them like it is makes it easier to understand what points are for what ore (You wouldn't guess that ORE_LOW was the same as ORE_CLAY without knowing about the change)

From: Zyt3x
Oh lol, that's why I didn't find them :redface: :duh:

I even made a script to search my entire MSI for scripts that include the word "SKILL_"… http://pastebin.ws/2jknrs

I didn't change ORE_CLAY … ORE_RUNITE in MSI_GetDTMPoints because their'e points differ, and leaving them like it is makes it easier to understand what points are for what ore (You wouldn't guess that ORE_LOW was the same as ORE_CLAY without knowing about the change)

Oh right, I didn't think about clay. You can still use ORE_HIGH though.

Not sure I got it right, but if you're suggesting using ORE_HIGH instead of ORE_RUNE to identify a rune ore, I find that to be a bad idea. Makes perfect clear sense to have a rune ore associated to ORE_RUNE.

~RM

From: Sir R. Magician
Not sure I got it right, but if you're suggesting using ORE_HIGH instead of ORE_RUNE to identify a rune ore, I find that to be a bad idea. Makes perfect clear sense to have a rune ore associated to ORE_RUNE.

~RM

No, that's not what I meant at all :p
We added ORE_LOW and ORE_HIGH so that you don't have to update the loops in loops where we used ORE_BRONZE and ORE_RUNITE.

It also gives the option to do MSI_LoadItemRange()

From: Sir R. Magician
Not sure I got it right, but if you're suggesting using ORE_HIGH instead of ORE_RUNE to identify a rune ore, I find that to be a bad idea. Makes perfect clear sense to have a rune ore associated to ORE_RUNE.

~RM

Yeah no, it's not indented to replace, but merely an alternative when all types of that object needs to be loaded. For example, when (if) we add dragon hatchet, we won't have to figure out which loops use HATCHET_BRONZE to HATCHET_RUNE as it'll be updated with the constants.

I basically just repeated what Zyt3x said. >.<

Added MSI_LoadItemRangeSingleItem for loading a group of items with only one item per object (For power-scripts)

Errr… A range would be the 'opposite' of single, so the naming of that function leaves me quite confused…

~RM

From: Sir R. Magician
Errr… A range would be the 'opposite' of single, so the naming of that function leaves me quite confused…

~RM

I don't know what to name it…
This is the way I thought: Load ItemRange SingleItem

I would think MSI_LoadItems would be just fine.

From: Zyt3x
Added MSI_LoadItemRangeSingleItem for loading a group of items with only one item per object (For power-scripts)

The point of LoadItemsRange was to avoid having to write out 30 objects for one script. If there's just one object, just do what we usually do. There's really no need for a function like that.

Objects := [[TREE_NORMAL]];

From: Coh3n
The point of LoadItemsRange was to avoid having to write out 30 objects for one script. If there's just one object, just do what we usually do. There's really no need for a function like that.

Objects := [[TREE_NORMAL]];

What do you mean?
Take a look at SCRIPT_POWER_MINER
You can replace Items := [[….]]; with Items := MSI_LoadItems(…);

From: Zyt3x
What do you mean?
Take a look at SCRIPT_POWER_MINER
You can replace Items := [[….]]; with Items := MSI_LoadItems(…);

I'm sorry, my mistake. I misinterpreted what it was meant for. It definitely needs a name change though (MSI_GetSingleSomething, idk). I also think MSI_LoadItemRange should be changed to GetItemRange because it's just getting the integers, not loading the record.

Also, since there's HIGH/LOW constants for items, we may as well have the same for objects and similar object functions can be made (MSI_GetObjRange, MSI_GetObjSingle). Oh, and remember to update the script header when you add a new function. ;)

E: I was just thinking, this whole HIGH/LOW business may cause us some problems. The objects and items attributes in the TScript records always have to be the same length, otherwise it won't work. The way it's laid out now, we can very easily determine if this is true. If we start using these new functions, we'd have to do more tests to be sure of this.

It is really worth having all the HIGH/LOW stuff?

From: Coh3n
E: I was just thinking, this whole HIGH/LOW business may cause us some problems. The objects and items attributes in the TScript records always have to be the same length, otherwise it won't work. The way it's laid out now, we can very easily determine if this is true. If we start using these new functions, we'd have to do more tests to be sure of this.

It is really worth having all the HIGH/LOW stuff?

I though about this too some hours ago.
For cooking (And other skills that include a lot of items + few objects), this is extremely helpful, but for the others like mining and woodcutting this is not useful at all.
The procedure MSI_LoadItemsSingleItem that I committed has to be removed, but MSI_LoadItemRange can either be removed or moved to the skill that needs it.

HIGH/LOW can be removed from ORES and LOGS, but I really want it in FOOD

Better stay consistent.

~RM

From: Sir R. Magician
Better stay consistent.

~RM

Yes.

I think all the HIGH/LOW constants should be removed. Since some food can be cooked on on a range or only on a fire, I think we should have cooking-specific functions in Cooking.simba to load the appropriate foods.

function MSI_LoadFoodRange(): TIntegerArray;
begin
end;

function MSI_LoadFoodFire(): TIntegerArray;
begin
end;

I also think we exclude all the foods except fish for now. I mean, let's be honest, what do the majority of people cook to train the skill? Raw fish. I'm sure there are several foods that no one makes and I honestly don't think it would be worth incorporating into a script (at least right now).

E: I notice this is all taken care of. Nice work Zyt3x. :)