SRL Archive - MSI Suggestions

Okay guys, right now it's being a little bit of a pain in my ass to add constants because they weren't all added in at the time.

There's a simple solution for this, originally suggested by Nielsie for a completly different purpose.

This is what we have:
[php]
TREE_NORMAL = 0;
TREE_OAK = 1;
TREE_WILLOW = 2;
TREE_MAPLE = 3;
TREE_YEW = 4;
TREE_MAGIC = 5;

ROCK_TIN = 6;
ROCK_COPPER = 7;
ROCK_IRON = 8;

MSI_BANK_VE = 9; // Includes the 'MSI_' because there are bank constants in SRL's Bank.scar
MSI_BANK_DB = 10;
MSI_BANK_GE = 11;
MSI_BANK_FE = 12;

DBOX_PS = 13;

FISH_SPOT_NET = 14;
FISH_SPOT_BAIT = 15;
[/php]

This is what I'd rather have:
[php]
TREE_NORMAL = 10;
TREE_OAK = 11;
TREE_WILLOW = 12;
TREE_MAPLE = 13;
TREE_YEW = 14;
TREE_MAGIC = 15;

ROCK_TIN = 20;
ROCK_COPPER = 21;
ROCK_IRON = 22;

MSI_BANK_VE = 30; // Includes the 'MSI_' because there are bank constants in SRL's Bank.scar
MSI_BANK_DB = 31;
MSI_BANK_GE = 32;
MSI_BANK_FE = 33;

DBOX_PS = 40;

FISH_SPOT_NET = 51;
FISH_SPOT_BAIT = 52;
[/php]

Notice how there's 10 spaces between each?
Notice how it's still organized?
Is there any reason to NOT do this?

This way it is also easy to move them up and down if the needs arises.

'Oh shit, I need eleven spaces for rocks'
Problem solved:
[php]
TREE_NORMAL = 10;
TREE_OAK = 11;
TREE_WILLOW = 12;
TREE_MAPLE = 13;
TREE_YEW = 14;
TREE_MAGIC = 15;

ROCK_TIN = 20;
//…
ROCK_COPPER = 29;
ROCK_IRON = 30;
ROCK_COAL = 31;

//change these from 30 -> 60
MSI_BANK_VE = 60; // Includes the 'MSI_' because there are bank constants in SRL's Bank.scar
MSI_BANK_DB = 61;
MSI_BANK_GE = 62;
MSI_BANK_FE = 63;

DBOX_PS = 40;

FISH_SPOT_NET = 51;
FISH_SPOT_BAIT = 52;
[/php]


~RM

Approved.
:D
I like it.

[php]
{WoodCutters}
SCRIPT_POWER_CHOP = 10;
SCRIPT_VE_TREES = 11;
SCRIPT_VE_OAKS = 12;
SCRIPT_GE_YEWS = 13;
SCRIPT_DB_WILLOWS = 14;
SCRIPT_RM_YEWS = 15;
SCRIPT_PS_WILLOWS = 16;

{Miners}
SCRIPT_POWER_MINE = 20;
SCRIPT_VE_MINER = 21;
SCRIPT_VW_MINER = 22;
SCRIPT_LWS_MINER = 23;
SCRIPT_LES_MINER = 24;
SCRIPT_BBV_MINER = 25;
SCRIPT_PSRM_MINER = 26;
SCRIPT_RM_MINER = 27;
SCRIPT_AK_MINER = 28;


{locs}
{non-def}
LOC_POWER_SKILL = 0;
LOC_LOST = 1;

{Varrock}
{east}
LOC_VE_BANK = 10;
LOC_VE_TREES = 11;
LOC_VE_OAKS = 12;
LOC_VE_MINE = 13;

{west}
LOC_VW_BANK = 20;
LOC_VW_MINE = 21;

{GE}
LOC_GE_BANK = 30;
LOC_GE_YEWS = 31;

{Draynor}
LOC_DB_BANK = 40;
LOC_DB_WILLOWS = 41;

{Rimmington}
LOC_RM_YEWS = 50;
LOC_RM_MINE = 51;

{Falador}
LOC_FE_BANK = 60;

{Port Sarim}
LOC_PS_WILLOWS = 70;
LOC_PS_DBOX = 71;

{Lumbridge}
LOC_LSW_MINE = 80;
LOC_LSE_MINE = 81;

{Barbarian Village}
LOC_BBV_MINE = 90;

{Al-Kharid}
LOC_AK_BANK = 100;
LOC_AK_MINE = 101;
[/php]

~RM

[php]
const
OBJ_COUNT = 16;

TREE_NORMAL = 10;
TREE_OAK = 11;
TREE_WILLOW = 12;
TREE_MAPLE = 13;
TREE_YEW = 14;
TREE_MAGIC = 15;

ROCK_CLAY = 20;
ROCK_TIN = 21;
ROCK_COPPER = 22;
ROCK_IRON = 23;
ROCK_SILVER = 24;
ROCK_COAL = 25;
ROCK_GOLD = 26;
ROCK_MITH = 27;
ROCK_ADDY = 28;
ROCK_RUNE = 29;

MSI_BANK_VE = 30; // Includes the 'MSI_' because there are bank constants in SRL's Bank.scar
MSI_BANK_DB = 31;
MSI_BANK_GE = 32;
MSI_BANK_FE = 33;

DBOX_PS = 40;

FISH_SPOT_NET = 50;
FISH_SPOT_BAIT = 51;
[/php]

[php]
const
ITEM_COUNT = 26;

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

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

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

ORE_CLAY = 40;
ORE_COPPER = 41;
ORE_TIN = 42;
ORE_IRON = 43;
ORE_SILVER = 44;
ORE_COAL = 45;
ORE_GOLD = 46;
ORE_MITH = 47;
ORE_ADDY = 48;
ORE_RUNE = 49;

FISH_SHRIMP = 60;
FISH_CRAYFISH = 61;
FISH_ANCHOVIES = 62;
FISH_SARDINES = 63;
FISH_HERRING = 64;

[/php]

~RM

Definitely like this idea :)

I talked to RM about this earlier. It is more organized and it makes sense, but our global arrays wouldn't work properly because the constant represents the index of the array. If we do it this way, the array would have to be HUGE and most of the indexes would be empty.

I like it, commit it :)

E: Cohen, have it skip empty arrays?

From: 3Garrett3
I like it, commit it :)

E: Cohen, have it skip empty arrays?

It would still work the exact same way as it does now, they would just be very large, empty arrays. And I don't know what you mean by "skip empty arrays". You mean not load the ones that are empty? Because that doesn't make sense. When you declare the array you are creating an array of however many indexes. It's up to you whether you give those indexes a value or not.

From: Coh3n
It would still work the exact same way as it does now, they would just be very large, empty arrays. And I don't know what you mean by "skip empty arrays". You mean not load the ones that are empty? Because that doesn't make sense. When you declare the array you are creating an array of however many indexes. It's up to you whether you give those indexes a value or not.

We could loop through the array on start up and get rid of the empty index's, essentially "restoring" the array to how it is now?

That wasn't very well thought through, just an idea that came to mind ;)

From: Coh3n
It would still work the exact same way as it does now, they would just be very large, empty arrays. And I don't know what you mean by "skip empty arrays". You mean not load the ones that are empty? Because that doesn't make sense. When you declare the array you are creating an array of however many indexes. It's up to you whether you give those indexes a value or not.

I mean like if there is no value for say… Object 53, then have it shorten the array length by 1 and not load 53. If that would work.

I personally don't get why you guys are so set on using these silly consts, but if you really really want to, i dont see why you don't just give each skill its own number and then all the places/items/objects can just start at 0.

  WCING = 0
  TREE_NORMAL    = 0;
  TREE_OAK       = 1;
  TREE_WILLOW    = 2;
  TREE_MAPLE     = 3;
  TREE_YEW       = 4;
  TREE_MAGIC     = 5;

  MINING = 1
  ROCK_TIN       = 0;
  ROCK_COPPER    = 1;
  ROCK_IRON      = 2;

  BANK = 2
  MSI_BANK_VE    = 0;  // Includes the 'MSI_' because there are bank constants in SRL's Bank.scar
  MSI_BANK_DB    = 1;
  MSI_BANK_GE    = 2;
  MSI_BANK_FE    = 3;

  WHATEVERTHISIS = 3
  DBOX_PS        = 0;

  FISHING = 4
  FISH_SPOT_NET  = 0;
  FISH_SPOT_BAIT = 1;

YAY DONE!

NCDS will not
hgfh: array [ FISH_SPOT_NET..FISH_SPOT_BAIT];
work?

From: Dan Cardin
I personally don't get why you guys are so set on using these silly consts, but if you really really want to, i dont see why you don't just give each skill its own number and then all the places/items/objects can just start at 0.

  WCING = 0
  TREE_NORMAL    = 0;
  TREE_OAK       = 1;
  TREE_WILLOW    = 2;
  TREE_MAPLE     = 3;
  TREE_YEW       = 4;
  TREE_MAGIC     = 5;

  MINING = 1
  ROCK_TIN       = 0;
  ROCK_COPPER    = 1;
  ROCK_IRON      = 2;

  BANK = 2
  MSI_BANK_VE    = 0;  // Includes the 'MSI_' because there are bank constants in SRL's Bank.scar
  MSI_BANK_DB    = 1;
  MSI_BANK_GE    = 2;
  MSI_BANK_FE    = 3;

  WHATEVERTHISIS = 3
  DBOX_PS        = 0;

  FISHING = 4
  FISH_SPOT_NET  = 0;
  FISH_SPOT_BAIT = 1;

YAY DONE!

NCDS will not
hgfh: array [ FISH_SPOT_NET..FISH_SPOT_BAIT];
work?

First off..Constants FTW. way more convenient and readable. Don't forget a lot of different people input is used with this script so readability is a top priority ;)

If we did it like that, we would have to change a lot of the core as the const's are mostly used in case statements to distinguish what the user is trying to accomplish. So, having multiple const's representing the same integer wouldn't work currently.

And no, I don't see how that would work as it is a global array for everything. If we were to use the constants as you suggested, then this might work.

I was thinking along the lines of using CombineTPA to sort it, but I'm sure there is a better way if I had time right now to actually sit and think about it.

It would work as a 2D array at that point though, it seems doable.

From: 3Garrett3
It would work as a 2D array at that point though, it seems doable.

If we were to make the core changes, yes. I'm sure that will be avoided at all cost's though as it seem's to be a bit more work than it's worth.

There's a few different way's to go about this, I just don't have the time right now to sit down and work with it as I'm in the process of heading out for the weekend.

From: 3Garrett3
I mean like if there is no value for say… Object 53, then have it shorten the array length by 1 and not load 53. If that would work.

That wouldn't work because each constant represents an integer, and that integer represents the index of the array. If you were to shorten the array, the indexes would change and wouldn't work with constants.

I personally think this is more trouble than it's worth, but that's just me.

Coh3n is right on this, so far.

The part that was problematic was the loading of the objects, from MSI_LoadAllItems / Objects

But here is the conclusion I came to:
How is a record ever 'badly' loaded?
Because our comment was "Then we wouldn't know what objects we didn't load"

But as we can't ever fail to load, and as we load all of them anyway, we can just change the consts, remove the debug, and everything should work just fine.

@Dan : That was the way we had it originally set up. We'd have to do double the amount of cases. Why we didn't do it? Not sure. But kinda late to change the whole core now, for the same functionality.

~RM

From: Rasta Magician

But as we can't ever fail to load, and as we load all of them anyway, we can just change the consts, remove the debug, and everything should work just fine.

Yeah, the ITEM_COUNT would just have to be the integer of the last constant. So it wouldn't really represent the actual item count.

From: Coh3n
Yeah, the ITEM_COUNT would just have to be the integer of the last constant. So it wouldn't really represent the actual item count.

So……… we're in for this?

Just to state it out there for everyone, this came up because I was adding a few constants in, and I had to edit all the next ones. If next year a new rock comes by, and we have 100 objects / consts after the mining ones, we'll have to edit all of them one by one.

~RM

I have just written a program to do it :p.
You just paste the constants you want to change like this: (after adding the one you want to add)

  ORE_COPPER      = 18;
  ORE_TIN         = 19;
  ORE_IRON        = 20;
  ORE_NEW         = 21;

  FISH_SHRIMP     = 21;
  FISH_CRAYFISH   = 22;
  FISH_SARDINE    = 23;
  FISH_HERRING    = 24;
  FISH_ANCHOVIE   = 25;
  FISH_TROUT      = 26;
  FISH_PIKE       = 27;
  FISH_SALMON     = 28;
  FISH_TUNA       = 29;
  FISH_LOBSTER    = 30;
  FISH_SWORDFISH  = 31;

  ITEM_BIRD_NEST  = 32; 

and you get back what you want (all the others increased) so you only have to copy/paste it back.
It's not finished(a bit ugly, a bit buggy) but I was only testing myself. If needed I can finish it :p.

EDIT: Btw, only reason I haven't done this in simba because I can't make forms …
I hear your thoughts, I should look into it and it's not hard, I know.

Do it and forget the const ITEM_COUNT, we don't need it.

From: marpis
Do it and forget the const ITEM_COUNT, we don't need it.

We need it just to know where to stop loading items ;)

~RM

From: Rasta Magician
So……… we're in for this?

Just to state it out there for everyone, this came up because I was adding a few constants in, and I had to edit all the next ones. If next year a new rock comes by, and we have 100 objects / consts after the mining ones, we'll have to edit all of them one by one.

~RM

Yeah I'm down. We have a comment beside ITEM_COUNT saying that technically it's not the item count. Either that or we rename it. ITEM_LAST, maybe?

From: Rasta Magician
@Dan : That was the way we had it originally set up. We'd have to do double the amount of cases. Why we didn't do it? Not sure. But kinda late to change the whole core now, for the same functionality

I'm sure there is a way around having double the cases, but without code in front of me, i can't suggest how. To me it would make it more readable in response to NCDS because its all structured and such, rather than what I assume is just one large case when you're trying to compare between all of the consts. It would also save future annoyance when you're trying to add new things which to me is a plus in productivity or functionality of the code itself rather than the script. Fear to change things to make them better will eventually make working with any project suck because you have to make compromises to avoid doing the change.

From: Rasta Magician
We need it just to know where to stop loading items ;)

~RM

Why not make the array looong and load empty objects as well?
It won't take up much memory. We will anyways have empty indexes when we change the constant numbering.

RM or Coh3n, please do this now!
I was adding object constants and damn that was a pain in the ass. I don't want to do it myself because I'm not sure enough of how the arrays currently work. Will need to look more into it later, but now I gotta go to work.

From: marpis
Why not make the array looong and load empty objects as well?
It won't take up much memory. We will anyways have empty indexes when we change the constant numbering.

RM or Coh3n, please do this now!
I was adding object constants and damn that was a pain in the ass. I don't want to do it myself because I'm not sure enough of how the arrays currently work. Will need to look more into it later, but now I gotta go to work.

I can later today, but all you have to do is change ITEM_COUNT to the value of the last constant. Or you can just make ITEM_COUNT = 100 for now. Doesn't really matter to me.

Guys, why not use bitwise constants?

From: Nava2
Guys, why not use bitwise constants?

I don't know bitwise that much (by that much I mean virtually nothing), so you care to write up an example? :rolleyes:

Nava linked to this in another thread:
http://compsci.ca/v3/viewtopic.php?t=9893

From: NCDS
Nava linked to this in another thread:
http://compsci.ca/v3/viewtopic.php?t=9893

Okay, then let me rephrase his question.

Why would you use bitwise constants? I'd say it just adds a whole lot of confusion…

I must agree. Enough people have problems following our code already, and it's not even difficult :/

To maintain user readability and our main goal of having a community based project I think we have to keep thing's how they are.

Edit: Yes, That's what I meant ;)

From: NCDS
I must agree. Enough people have problems following our code already, and it's not even difficult :/

To maintain user readability and our main goal of having a community based project I think we have to keep thing's how they are.

Or at least how RM suggested (but I think that's what you meant). :p

//declare players
    with Player[0] do
    begin
        Ores := ORE_COAL or ORE_MITH;
        OresToDrop := ORE_COAL or ORE_MITH;
    end;
//...


//Mining Procedure:
    if (currPlayer.ores and (ORES_COAL or ORES_MITH) > 0) then
        Writeln('Mining both Coal and Mith!');

See what I'm saying? Its just better looking :D

Also, bitwise operations are the fastest operations possible.. (I think..)

What you really need to know is this:

  X  Y  | X and Y   |  X or Y  | not X  |  not Y  |  X xor Y 
  1  1  |    1      |    1     |   0    |    0    |     0 
  1  0  |    0      |    1     |   0    |    1    |     1 
  0  1  |    0      |    1     |   1    |    0    |     1 
  0  0  |    0      |    0     |   1    |    1    |     0

Ohh haha I thought you were talking about something like:

HATCHET_BRONZE = 101011;
HATCHET_IRON   = 1001110;

That's why I was like, wth?

From: Coh3n
Ohh haha I thought you were talking about something like:

HATCHET_BRONZE = 101011;
HATCHET_IRON   = 1001110;

That's why I was like, wth?

Teeeccchnically I am.

But much nicer written as:

HATCHET_BRONZE = 2 shl 1;
HATCHET_IRON = 2 shl 2;
//...

Except I don't see how/why that would be better.

so you can do what I said before haha

//declare players
    with Player[0] do
    begin
        Ores := ORE_COAL or ORE_MITH;
        OresToDrop := ORE_COAL or ORE_MITH;
    end;
//...

That? Why wouldn't you be able to do it with what we have now?

"1 or 2" is different from "2 shl 1 or 2 shl 2"? :p

From: i luffs yeww
"1 or 2" is different from "2 shl 1 or 2 shl 2"? :p

I never said they weren't…

Using bitwise constants would be easier to keep track of I think.

Also, I wasn't trying to say that you didn't know that. :) I phrased it poorly is all. What I meant was that it makes more sense (to me, at least) to have bitwise constants.

From: i luffs yeww
Using bitwise constants would be easier to keep track of I think.

Also, I wasn't trying to say that you didn't know that. :) I phrased it poorly is all. What I meant was that it makes more sense (to me, at least) to have bitwise constants.

See that's the thing.. I don't understand why it would make more sense. Probably doesn't help that I don't know them that well, but still.

In my opinion it looks better and neater. N2 probably has more practical reasons, though. :)

Speed, ease of use, you can find out what they are using quickly without comparing strings or things in arrays.

I never got around to bitwise too much, and none of us SLs has, as far as I can tell.

From what I was seeing from your code, there seem to be many great advantages. But I'd have to agree with NCDS.

The speed difference doesn't really matter, and while bitwise would be better code management, it would be too 'far fetched' for the majority of scripters & users to actually understand and therefore make it harder to contribute.

(Do feel free to make a new thread elaborating how you'd go about it, and shine some lights on us ;) )

~RM

Committed.