SRL Archive - General

Pre-Release Organization


Coh3n

2010-02-26 11:26:44

Pre-Release Organization


Okay, I'm sorry to do this to everyone considering we're so close to releasing, but I needed to say something. Working on MSI a lot the last couple days let me get to know the include and see what's been done. I have seen a lack of consistency and a lot of things that could have been done differently/better.

Why does it matter, you may ask. Well, if we're unorganized and inconsistent, we may be giving other members the wrong idea about MSI. We need to let them know that we're serious about making this project a success. We need to have everything easy to understand and use if we want other people to contribute.

Also, the more organized we are, the easier errors can be found and fixed, along with the necessary tweaks to make a certain element work the way it should.

I have compiled a list of things I think should change. I don't mind doing all the organization, as long as everyone agrees on these issues.
  • Constants
    • Half of them are capitalized, half aren't. I say capitalize all. NCDS mentioned half capital half not (i.e. CITY_Varrock).
    • I also think that all constants should be kept in Globals.scar, as well as other general MSI functions.
    • More than half aren't used at all/won't be used for a long time. Therefore, unnecessary. I say, get rid of them.
      • Walking_Reflection. This won't even be used for a long time. I say exclude from the include. Can be saved on someone's computer. It's just unnecessary if it isn't being used.
  • Unnecessary Code
    • Anything we have setup for skills we don't support/will not support for a long time. I say get rid of it, or at least comment it.
      • Debug.scar
    • Objects.scar
      • I previously thought we should use SmartColors instead of what we currently have. However, working on the progress report/mainloop, I have come to the conclusion that it is much nicer having MSI_specific object finding.
    • Autocolor.scar
      • Is it even being used? If not, completely unnecessary and can be scrapped.
  • Script/Function Headers and Comments
    • There are SEVERAL functions that don't have headers.
    • Maybe one or two of the script headers are up to date.
    • We need good, clear descriptions for EVERY function/types/const/global vars.
    • Proposed headers:
    • [PHP] {==============================================================================\ | MSI Group Scripting Include | | Mainloop.scar | |==============================================================================| | For all the script Artificial Inteligence | | | | * function MSI_BestTool: Integer; * by Coh3n | | * function MSI_WorstTool: Integer; * by Coh3n | | * function MSI_SetupPlayer: Boolean; * by Coh3n | | * function MSI_GetObjectList: TIntegerArray; * by Coh3n | | * function MSI_WalkToLoc: Boolean; * by The MSI Team | | * function MSI_WalkToBank: Boolean; * by The MSI Team | | * function MSI_DoSkill: Boolean; * by The MSI Team | | * procedure MSI_CountMaterials: Boolean; * by Coh3n | | * function MSI_BankMaterials: Boolean; * by The MSI Team | | * function MSI_MainLoop: Boolean; * by The MSI Team | \_____________________________________________________________________________} {******************************************************************************} { Name: function MSI_BestTool: Integer; } { By: Coh3n } { Description: Determines the best tool for the job at hand } {******************************************************************************} //for types { Name: type TItem Description: To be used for handling Items in all situations } //For constants { Name: const Hatchet/Pickaze requirements Constants representing the requirements to use each pickaxe/hatchet } //For important global vars { Name: var ProgressReportArray; Description: To be used to store information for Players individually } ProgressReportArray: Array of TProggy; //For necessary local/less important vars var theItem: Integer; //The item to look for [/PHP]
    • I also think that we should have short (1 line max) comments in the functions that give a little explanation of what that part of the function does.
    • I would like the MSI include to be an awesome learning tool for anyone learning how to script.
  • White Spacing
    • I know it's not "Official" SRL standards, but I would love if we all used white spacing in our code. It makes it so much easier to read and understand.
    • A great example of awesome white spacing/commenting is FindMMLocation by marpis in Walking_Color.scar
  • MSI-Specific Functions
    • I think there are certain things that should be made MSI-specific. Maybe there is a function that does the same thing in SRL, but doesn't quite fit the proper needs for MSI.
  • Getting Ahead of Ourselves
    • This is something that CANNOT happen. We need to make sure one project is done with all the necessary elements, before we move on to the next project. Once released, we may be able to have more than one project going on at the same time, with SL's leading them, but there's no rush.
  • Inventory/Bank Item Finding
    • I say we scrap all bitmaps and use DTM's all the way. DTMs find 99.9 percent of the time and are fast. Having bitmap routines in the include is just pointless in my opinion.
  • Before Committing
    • ALWAYS remember to run CompileMSI before committing! You don't want to leave another person to fix an compiling mistakes you may have made when they're trying to fix something else.
If everyone can stick do these things, then we'll have no issues, everything will be organized, look good, and will be easy to navigate through the include and understand the code. Again, I don't mind going thought the include and making it release-ready, as long as the majority agrees.

Since we haven't released yet, we need everyone who can to test. All you need is five minutes to setup a player, then hit run. Come back later, and looks through the debug info. and post the necessary information for everyone to review.

Thoughts or comments on anything I said? Or additions? Or you can yell at me if you wish. :p

NCDS

2010-02-26 11:39:17

We talked on MSN about a few detailed things, other than that though I agree 100%

Coh3n

2010-02-26 11:52:19

From: NCDS
We talked on MSN about a few detailed things, other than that though I agree 100%

Oh yeah, I'll add you constant thing to the first post.

Blumblebee

2010-02-26 11:56:18

I refuse to use white spaces, I'm sorry haha but your not converting me.

Also, I say we use color more than we should use DTM's or bitmaps. But your right, DTMS > Bitmaps for sure.

other than that, love it :) good points.

Coh3n

2010-02-26 11:59:03

From: Blumblebee
I refuse to use white spaces, I'm sorry haha but your not converting me.

Also, I say we use color more than we should use DTM's or bitmaps. But your right, DTMS > Bitmaps for sure.

other than that, love it :) good points.

Lol, not even white spaces with large cases? I was more or less talking about that then anything. It's just easier to read cases if there's a space between them.

Color can be good for some things, but there are a lot of items that have similar colors as where DTM are unique and work every time.

Naum

2010-02-26 12:01:41

Also, please add that before committing REMEMBER TO COMPILE!!!!
It's pretty time-consuming, as when I'm trying to fix Bank functions; I have to spend my time fixing tedious compiling errors :/

Coh3n

2010-02-26 12:02:32

From: Naum
Also, please add that before committing REMEMBER TO COMPILE!!!!
It's pretty time-consuming, as when I'm trying to fix Bank functions; I have to spend my time fixing tedious compiling errors :/

Added.

NCDS

2010-02-26 15:00:44

From: Blumblebee

Also, I say we use color more than we should use DTM's or bitmaps. But your right, DTMS > Bitmaps for sure.


From: Coh3n

Color can be good for some things, but there are a lot of items that have similar colors as where DTM are unique and work every time.


I agree, I just think .bmp's should be used as a "last resort" fail safe as with so many updates they tend to become outdated fairly quickly, in my experience at least.

Coh3n

2010-02-26 15:29:06

From: NCDS
I agree, I just think .bmp's should be used as a "last resort" fail safe as with so many updates they tend to become outdated fairly quickly, in my experience at least.

I don't even think it's that necessary. I don't even see a point in having them. Chances are if the DTM isn't found, it probably means that that item isn't there.

EDIT: I added a poll for the constant types.

Blumblebee

2010-02-26 16:13:04

From: Coh3n
I don't even think it's that necessary. I don't even see a point in having them. Chances are if the DTM isn't found, it probably means that that item isn't there.

EDIT: I added a poll for the constant types.


all items have a unique color/pixel orientation. Find the black pixel, then look to the left or right for a certain color. Although that requires more work I suppose, I dunno haha I hate dtm's for some odd reason.

And white spaces suck haha, in big cases maybe but other than that no way.

Also I like constants that are like:

WALK_BANK_area

instead of

WALK_BANK_AREA

tbh.

NCDS

2010-02-26 16:13:29

From: Coh3n
I don't even think it's that necessary. I don't even see a point in having them. Chances are if the DTM isn't found, it probably means that that item isn't there.

EDIT: I added a poll for the constant types.


I thought that too but I didn't know if anyone else felt the same. So they can be taken out of ItemInfo.scar then, right?

Coh3n

2010-02-26 16:16:42

From: Blumblebee
all items have a unique color/pixel orientation. Find the black pixel, then look to the left or right for a certain color. Although that requires more work I suppose, I dunno haha I hate dtm's for some odd reason.

And white spaces suck haha, in big cases maybe but other than that no way.

Also I like constants that are like:

WALK_BANK_area

instead of

WALK_BANK_AREA

tbh.

Well you're just raining on everyone's parade aren't you? You hate DTM's, you hate white spacing… :p

But I guess I'm the one who doesn't like the constants you like. Idk why, I just don't like the way it looks, but it does make sense in a way.

From: NCDS
I thought that too but I didn't know if anyone else felt the same. So they can be taken out of ItemInfo.scar then, right?

May as well. There may be some functions that need to be edited if they use bitmaps.

Blumblebee

2010-02-26 16:18:58

From: Coh3n
Well you're just raining on everyone's parade aren't you? You hate DTM's, you hate white spacing… :p

But I guess I'm the one who doesn't like the constants you like. Idk why, I just don't like the way it looks, but it does make sense in a way.


ALL_CAPS_CONSTANTS_MAKE_IT_LOOK_LIKE_YOUR_ALWAYS_YELLING_AT STUFF_IN_THE_SCRIPT. Haha, and yes. I do like to rain on everyone's parades :p

MSI would be a fully functioning, agreeing group if it wasn't for me haha.

Coh3n

2010-02-26 16:20:47

From: Blumblebee
ALL_CAPS_CONSTANTS_MAKE_IT_LOOK_LIKE_YOUR_ALWAYS_YELLING_AT STUFF_IN_THE_SCRIPT. Haha, and yes. I do like to rain on everyone's parades :p

MSI would be a fully functioning, agreeing group if it wasn't for me haha.

I lol'd. There always has to be someone that has a different opinion then everyone else. ;)

If it weren't for you I'd still want to use SmartColors.

Sir R. M8gic1an

2010-02-26 17:14:39

GJ on thread.

I wouldn't say scrap the code. Worst case scenario just comment it out. It's better to have it in the include than on someone's computer. Also, comented code does not hurt.

ALL_CAPS_LOOKS_BETTER than NOT_ALL_caps (imo :p )

For the function headers, i think the 'Status' line is useless. We'll never have a status line that'll say anything besides 'working', cus we'd just fix it if it wasn't working.

~RM

Coh3n

2010-02-26 22:31:54

From: Rasta Magician
GJ on thread.

I wouldn't say scrap the code. Worst case scenario just comment it out. It's better to have it in the include than on someone's computer. Also, comented code does not hurt.

ALL_CAPS_LOOKS_BETTER than NOT_ALL_caps (imo :p )

For the function headers, i think the 'Status' line is useless. We'll never have a status line that'll say anything besides 'working', cus we'd just fix it if it wasn't working.

~RM

Thanks and good point. I think my intention of the status part was if someone doesn't have the time to actually fix it, they can just mark it as not working. But I guess that wouldn't happen often, so it would be useless. I'll change that and the commented code thing.

marpis

2010-02-28 09:13:07

HALF_caps looks just stupid.
I like "City_Varrock" the best, but SRL is sticking with "CITY_VARROCK", therefore we should have ALL_CAPS_TOO.

Coh3n

2010-03-01 16:45:46

From: marpis
HALF_caps looks just stupid.
I like "City_Varrock" the best, but SRL is sticking with "CITY_VARROCK", therefore we should have ALL_CAPS_TOO.

Yeah, that was my thinking also.

EDIT: If no one objects to anything, I can start doing all this stuff within the next couple days.

Naum

2010-03-12 16:00:23

I tried to make myself helpful, and based on what Coh3n said, I capitalized all the constants. Pretty tedious :p. Tell me how it looks..

08:58:45 PM: CompileMSI: MSI has compiled :)

Coh3n

2010-03-12 17:18:57

From: Naum
I tried to make myself helpful, and based on what Coh3n said, I capitalized all the constants. Pretty tedious :p. Tell me how it looks..

08:58:45 PM: CompileMSI: MSI has compiled :)

Good job. We should probably change the autocolor constants to something like this:

ROAD_COLOUR = 6579821;
VARROCK_ROAD_COLOUR = 8291719;
FALLY_ROAD_COLOUR = 7831173;
LUMBY_ROAD_COLOUR = 8225677;
DIRT_ROAD_COLOUR = 1853272;
WATER_COLOUR = 10850700;
ROCK_COLOUR = 5789528;
SAND_COLOUR = 0;
BANKER_COLOUR = 1179390;
TREE_COLOUR = 1532978;
Anyone disagree?

EDIT: Same thing with the location constants in Walking_Reflection. The words should all be separated with an underscore. Does anyone object to having all the constants in Globals.scar? (pretty sure that's what I said in the first post) Or do you think it'd be better to have them in the specific script?

EDIT2: Does anyone object to having MSI_Antiban in Globals.scar?

NCDS

2010-03-12 17:28:37

From: Coh3n
Good job. We should probably change the autocolor constants to something like this:

ROAD_COLOUR = 6579821;
VARROCK_ROAD_COLOUR = 8291719;
FALLY_ROAD_COLOUR = 7831173;
LUMBY_ROAD_COLOUR = 8225677;
DIRT_ROAD_COLOUR = 1853272;
WATER_COLOUR = 10850700;
ROCK_COLOUR = 5789528;
SAND_COLOUR = 0;
BANKER_COLOUR = 1179390;
TREE_COLOUR = 1532978;
Anyone disagree?

EDIT: Same thing with the location constants in Walking_Reflection. The words should all be separated with an underscore. Does anyone object to having all the constants in Globals.scar? (pretty sure that's what I said in the first post) Or do you think it'd be better to have them in the specific script?

EDIT2: Does anyone object to having MSI_Antiban in Globals.scar?


Definitely put all the constants in Globals.scar. I hate having to look for them.

Antiban may as well be included in globals. I don't see why not at least.

Coh3n

2010-03-12 17:30:32

From: NCDS
Definitely put all the constants in Globals.scar. I hate having to look for them.

Antiban may as well be included in globals. I don't see why not at least.

Okay thanks, it's just much easier having them all in the same script. It also avoids any unknown identifiers that may arise. And yeah, the antiban doesn't really fit into any other categories.

Naum

2010-03-12 18:00:41

From: Coh3n
Okay thanks, it's just much easier having them all in the same script. It also avoids any unknown identifiers that may arise. And yeah, the antiban doesn't really fit into any other categories.


However, you have to make sure that the file you put it in is included before others, else you will have to have a lot of unnecessary forwards.
Furthermore, you can change the AutoColor constants if you want. However, I think it looks fine as it is. Changing it will be tedious and, I think, it will not reap significant benefits. :spongebob:

Also, is MainLoopDraft still needed? I don't think it serves a purpose (apart from archival purposes), correct me if I'm wrong though.

Coh3n

2010-03-12 21:21:56

From: Naum
However, you have to make sure that the file you put it in is included before others, else you will have to have a lot of unnecessary forwards.
Furthermore, you can change the AutoColor constants if you want. However, I think it looks fine as it is. Changing it will be tedious and, I think, it will not reap significant benefits. :spongebob:

Also, is MainLoopDraft still needed? I don't think it serves a purpose (apart from archival purposes), correct me if I'm wrong though.

No, mainloop draft is not needed.

The autocolor constants now are stupidly hard to read, so that's how we'd benefit. ;) Also, I'm pretty sure Globals.scar is included first (makes sense), so there's no worries about unknown identifier errors.

Sir R. M8gic1an

2010-03-13 06:16:50

Guys, Antiban.scar…..

~RM

Naum

2010-03-13 07:35:30

From: Rasta Magician
Guys, Antiban.scar…..

~RM


That's what I thought at first, however there may be a slight chance of conflict between this and the one in SRL already.
Secondly, it seems inappropriate for one function to be in one file. Maybe MSI_AntiBan should be moved to SRL's AntiBan.Scar, that way it can be with all the other functions? Furthermore, people will also be able to use it in their scripts.
Downsides to this is the fact that MSI functions should stay in the MSI include, however could MSI_AntiBan be in SRLs AntiBan.scar. Or are they completely separate things?

(This is only the case that I've interpreted what you meant in your post: MSI has its own AntiBan.scar(?), if not then I've utterly misunderstood).

Coh3n

2010-03-13 09:18:44

From: Rasta Magician
Guys, Antiban.scar…..

~RM

Yeah, but for only one function?