PDA

View Full Version : objects.simba (smartcolors.simba)



Coh3n
02-14-2013, 01:34 AM
So, Zyt3x convinced me to be in favor of a database, I'll address that a little here, as well as what I think should happen with objects/smartcolors.simba.


Completely replace the current objects.simba with a combination of MSI's object finding and smartcolors.simba. Will keep the name objects.simba, though.


Have a global type, TRSObject, that can be imported to scripts/SRL files if needed (i.e. bank.simba could utilize object functions).


Since SmartColors updates a global SC array during runtime, the final array can be uploaded to a database periodically throughout a script, or at the end. This would ensure everyone is using the most up to date object records. I'm not going to get into details about a database, but I just want you guys to think about it.


For bank.simba, TRSObject could be used something like this:

// any file that requires object finding; will use bank.simba or this example

{$include_once objects.simba}

const
BANK_VARROCK_EAST = 0;

function __getBankObject(bank: integer): TObject; // TObject will be in the object.simba file
begin
case bank of
BANK_VARROCK_EAST:
with result do
begin
// attributes here
end;

end;
end;

function openBank(bank: integer): boolean;
begin
clickObject(__getBankObject(bank));
end;

// whatever other bank functions here

begin
end.



Basically the new objects.simba will just be an intelligent object finding library. Scripters can choose whether or not to use it, of course.

Thoughts?

Flight
02-14-2013, 01:39 AM
I've never seen MSI's previous object-finding routines because I've never used it. I'm definitely for this idea though.

Zyt3x
02-14-2013, 06:25 PM
Nice thread, I'll start coding and planning something tonight

Coh3n
02-15-2013, 05:28 AM
For objects.simba? Or a database? Zyt3x;

Zyt3x
02-15-2013, 07:10 PM
Yes

Flight
02-16-2013, 12:18 AM
If we have a standard format for TObject then I'd surely like to help with the database.

Coh3n
02-18-2013, 01:10 AM
YesSooo, both?


If we have a standard format for TObject then I'd surely like to help with the database.That's the plan. It can likely be done with items as well as I know WT-Fakawi; and BraK; have an idea for an items.simba include.

BraK
02-18-2013, 06:06 AM
An Items include isn't really going to do any good. what needed is going to be self updating object handling procedures. I'm sure WT-Fakawi; could talk on this process for a long time to come. Basically reading an object that's there and having it update it's own file that would be specific on the users computer.

This system wouldn't really be in any relative order and it would only load specific object for each script. WT has used this system several times in the past in his script for object handling.

Coh3n
02-18-2013, 02:00 PM
An Items include isn't really going to do any good. what needed is going to be self updating object handling procedures. I'm sure WT-Fakawi; could talk on this process for a long time to come. Basically reading an object that's there and having it update it's own file that would be specific on the users computer.

This system wouldn't really be in any relative order and it would only load specific object for each script. WT has used this system several times in the past in his script for object handling.
I know, that's what I meant. Instead of a local file, though, it would be better to upload items to an online database so everyone can take advantage of it. But yes, it would be self generated, like objects.simba.
WT-Fakawi; I know you've mentioned it many times; but I still don't understand how this could be more human-like. Care to elaborate?

Zyt3x
02-18-2013, 05:50 PM
Remember that we create the database as smart as we want it to be. If we want to store "similar" items/objects together, then we could do that; it's all just a matter of how much time we want to spend on it. I'd be willing to spend quite some time on it, myself.

I think this is worth a go. :)

Coh3n
02-18-2013, 08:08 PM
Zyt3x; you can work on a database if you wish; you seem to have thought about it a lot more. I'm going to work on getting SRL-6 to a beta stage. A database can really be added at any time, assuming it'll utilize SRL's object/item types.

Are you going to write code for objects.simba as well? I don't mind doing it since I likely know MSI's object routines better than you do (since I wrote a lot of it). I think I might look at text.simba first, though since a lot of things require uptext and chooseOption. I'll probably make a thread about it soon.

Coh3n
09-26-2013, 12:20 AM
Moving this to the public -- do you think it's a good idea to have such a objects library in SRL? Or should that be left up to the scripter? Are the mainscreen object finding functions enough?

Zyt3x
09-26-2013, 04:57 PM
Ooooooh, Coh3n leaking WT-Fawki's scripts to the public ;O That doesn't happen often.

@ Public :
What we're talking about here is a smart database over objects and possibly items, locations, npcs and locations that will maintain it's integrity by automatically adjusting to color updates much like MSI did with Rasta Magician's smartcolors.simba code.

Benefits of having such a database:
- Scripters will have more time creating the actual script, rather than collecting colors and making DTMs and so forth
- The database can more easily be linked to the SRL Stats system, meaning more accurate data collection for the stats
- The database can (possibly) eventually (maybe) become a RuneScape Wiki (mayhaps) of some sorts, meaning not only botters will benefit from it, but also the greater public (?)

Coh3n
09-26-2013, 05:46 PM
That was totally by accident. :duh:

Kevin
09-26-2013, 05:50 PM
That was totally by accident. :duh:

Don't worry. Already copied it ;)

(jk, I read it and left it)