SRL Archive - SRL Development and Help

What items do we want to include in our database, either for scripters to utilize and populate, or for SRL to utilize and populate.

I've made a list here, but feel free to suggest others:

• Locations (A TDynamicBox made from a TPointArray)
• Items (A TRSItem type)
• NPCs (A TRSNPC type)
• Objects (A TRSObject type)
• Interfaces (A TRSInterface type, which we already have)
• ????

We'll save using XML, the problem comes when we want to load our objects; we have to extract the information from the XML file and enter them into the object one variable at a time; resulting in at least one line for each variable. For arrays there will be at least 3 lines for each array.
One "extractFromXML()" function will be at best "n+5" lines long where 'n' is amount of variables to set.
Writing these functions will thus be very tedious and time consuming, unless we find out a clever hack plugin that can set variable names and variable values for us.
Maybe Lape can add some sort of dynamic object to it? @nielsie95;

Sounds good so far. Couple things:

What would be different from TRSObject and TRSNPC? An NPC is just another object on the screen; I can't think of what would make it different. Also, what kind of data would you store for TRSInterface? We already have a file in SRL for each interface. Would it be for interfaces we don't have in SRL? Or would it also store the records we already have?

Lastly, it sounds like you're wanting to load everything in the database into memory at once? Wouldn't it be better to have zero variables set, and have various "get" functions in SRL for scripters to utilize? So nothing is loaded into memory unless it's used.

// items.simba

// gets the item from the SRL database
function getItem(name: String {or ID: integer}): TRSItem;
begin
  // code that reads the XML file
end;

// SRL include file or external script
function equipHatchet(): boolean;
var
  it: TRSItem;
begin
  it := getRSItem('Rune hatchet');
  result := it.click(MOUSE_LEFT);
end;

That would keep the amount of code in SRL to a minimum, plus wouldn't waste memory storing a thousands of records that won't be used.

E: Thank-you for making this thread. :)

What, no: I have no intentions of loading everything into memory at once :P Hah, that would take up waaay to much memory..
How could you think that little of me? :(

@TNPC: The thing is, if Jagex ever do something to NPCs and make them different from objects, we want to be ready for it. It's own class will make this easier. TNPC will inherit TRSObject, and I'm thinking of making TRSActionGroup or something similar for i.e things that load new interfaces, such as clicking a NPC will open chat with that NPC or if the NPC / RSObject opens a bank screen.

Ideally, all interfaces we have use will be loaded through the database; this way we can easily update them or even make a program to update it for us.

A possible way to make it more efficient is to break things like the object category down even further into sub categories either by skill or type?

For example:

By skill
Herblore -> Herbs, Potions, Flaks, ingredients, etc
Cooking -> Sharks, lobster, pie, etc
Attack -> Weapons
Defence -> Armour
etc

By type
Combat -> weapons, armour, arrows/ammo, runes
Resources -> ore, logs, flax, seeds
etc

Then there are less items per area to load up.

Does Lape support dictionaries? Parsing this into a dictionary I think would be the best so that could be referenced by like SRLDatabase['Herblore']['Clean_Ranarr'].DTM; or w/e

Look into this if you want an example how to dynamically load and access dtms/bitmaps:
https://code.google.com/p/soulsplit-include/source/browse/#git%2FDTMs%253Fstate%253Dclosed

So you just have a single file per DTM?

Also, another random thought:
Why not make it an sqlite database since simba has sqlite capabilities built in?

From: Hobbit
So you just have a single file per DTM?

Very fast. The system memorize which dtms you used and it works similar to what you suggested.

getDTM('Clean_Ranarr')

instead of

['Clean_Ranarr'].DTM;

Biggest pro is that you don't have to free them, or load/store them.

You could simply do:

FindDTM(getDTM('Clean rannar'), otherParams);

From: Hobbit
Why not make it an sqlite database since simba has sqlite capabilities built in?

I don't like that, but only because I hate SQL ;) Might be possible.

Hmmmm your system does sound pretty great :)

Do we have any spec for what TRSItem and TRSNPC, etc will hold for data?

Could structure it as:
./database
…./NPCs/Bob.npc
…./Items/Clean_Ranarr.item
etc?

Assuming the records will hold more than the DTM it might be good to change the extension to what they are?

From: Zyt3x
What, no: I have no intentions of loading everything into memory at once :P Hah, that would take up waaay to much memory..
How could you think that little of me? :(

That's why I was confused. :p

From: Zyt3x

@TNPC: The thing is, if Jagex ever do something to NPCs and make them different from objects, we want to be ready for it. It's own class will make this easier. TNPC will inherit TRSObject, and I'm thinking of making TRSActionGroup or something similar for i.e things that load new interfaces, such as clicking a NPC will open chat with that NPC or if the NPC / RSObject opens a bank screen.

TNPC sounds good. I don't really understand what TRSActionGroup would be used for, though. Just knowing what i.e. interface is opened when interacting with said object/NPC?

From: Zyt3x

Ideally, all interfaces we have use will be loaded through the database; this way we can easily update them or even make a program to update it for us.

But what about dynamic attributes like an interface's position? If one script/user moves the interface, the TRSInterface will update, but we don't want the new coords to be uploaded to the database because no one else's interface will be in that position. Maybe we only have the database update when certain attributes are updated?

From: Coh3n
That's why I was confused. :p

TNPC sounds good. I don't really understand what TRSActionGroup would be used for, though. Just knowing what i.e. interface is opened when interacting with said object/NPC?

But what about dynamic attributes like an interface's position? If one script/user moves the interface, the TRSInterface will update, but we don't want the new coords to be uploaded to the database because no one else's interface will be in that position. Maybe we only have the database update when certain attributes are updated?

Could we possibly add in a check to the player login function that checks the current positions of the interface objects with those in the database and either resets the interface to that of the database or updates their local database record to how they have their interface setup and each time login happens it will perform this check incase a database update overrides their local settings?

From: Hobbit
Could we possibly add in a check to the player login function that checks the current positions of the interface objects with those in the database and either resets the interface to that of the database or updates their local database record to how they have their interface setup and each time login happens it will perform this check incase a database update overrides their local settings?

That wouldn't work for popup interfaces. We'd have to open every interface and check it's position. Nice idea, though.

From: Coh3n
TNPC sounds good. I don't really understand what TRSActionGroup would be used for, though. Just knowing what i.e. interface is opened when interacting with said object/NPC?

But what about dynamic attributes like an interface's position? If one script/user moves the interface, the TRSInterface will update, but we don't want the new coords to be uploaded to the database because no one else's interface will be in that position. Maybe we only have the database update when certain attributes are updated?

What if the interface varies or an interface doesn't open? Do I really have to spell these things out? :(

And why would we want to set X,Y positions of dynamic interfaces…? That defeats the whole purpose of calling them "dynamic": SRL is supposed to find these interfaces itself, and output the X and Y to the scripter when asked to do so.

I'm so confused… again. I never know what you're talking about. :( I just don't see what TRSActionGroup is supposed to accomplish.

I'll just respond to the dynamic loading part; why would it be needed? You say yourself that they'll be of a specific type? What do you have in mind?

From: Coh3n
I'm so confused… again. I never know what you're talking about. :( I just don't see what TRSActionGroup is supposed to accomplish.

TRSActionGroup will tell the script what's supposed to happen when action X is performed. I.e open interface "bankscreen" or close interface "bankscreen" or open gametab "inventory" and open interface "bankscreen".

From: nielsie95
I'll just respond to the dynamic loading part; why would it be needed? You say yourself that they'll be of a specific type? What do you have in mind?

Not needed, but would save time. I'm thinking of something like Python's json.load() function

Okay that's what I originally thought. Do you think it's necessary though? I'd rather see it just open the bank screen and make it up to the scripter to check if something else happened. Maybe multiple things happen, but the scripter only needs to check one thing. There's no point in checking for everything if it doesn't matter anyway. Do you know what I mean?

Lets first get something up and running. I am still at school but will be home in a bit more then hour and a half. (I hate the train and coming home in the end of the evening) I got some amazing ideas I am 100% sure you would like!

Sounds great. :)

Me and masterBB had a brainstorming session on Skype the other night. We agreed on start making something individually and then post our results and findings here for input and to implement a system containing the best of both worlds :)

Great. :)