SRL Archive - MSI Archives

Hey everyone,

I've been working on MSI_SetupMagic for the last couple days, and I haven't really been able to come up with a good way to handle staffs. In another thread, we talked about having the user set the staffs they'll be using, so a setup could look like:

with Scripts[0] do
begin
  Name := SCRIPT_MAGE_FIGHTER;
  Spells := [SPELL_EARTH_STRIKE, SPELL_FIRE_STRIKE];
  Staffs := [STAFF_EARTH, STAFF_FIRE];
  Monsters := [NPC_DEMON_LESSER];
end;

Where the staffs would correspond to the spells - STAFF_EARTH would go with SPELL_EARTH_STRIKE and STAFF_FIRE would go with SPELL_FIRE_STRIKE. The problem with that is the user may not want to use a staff for earth strike, in which case it would try to use a fire staff with earth strike. A solution I thought of - one I don't particularly like - is fill the empty indexes with -1:

with Scripts[0] do
begin
  Name := SCRIPT_MAGE_FIGHTER;
  Spells := [SPELL_EARTH_STRIKE, SPELL_FIRE_STRIKE];
  Staffs := [-1, STAFF_FIRE];
  Monsters := [NPC_DEMON_LESSER];
end;

I also thought that maybe I'm going about this the wrong way, and having only one staff would be enough, so the staff could be found and equipped automatically, rather than set in DeclarePlayers. I would, however, like the user to have the option of multiple staffs. Another example would be when enchanting: maybe there are 10 sapphire rings and 10 emerald necklaces. They both require cosmic runes, but need different additional runes/staffs.

I'm looking for comments, suggestions, anything really.

On another note: a little update on Magic.simba. For MSI_SetupMagic, it successfully counts the runes in the players inventory and calculates the amount of casts for each spell in the array. It also works if two spells require the same runes.

Cheers,
Coh3n

with Scripts[0] do
begin
  Name := SCRIPT_MAGE_FIGHTER;
  Spells := [SPELL_EARTH_STRIKE, SPELL_FIRE_STRIKE];
  Staffs := [STAFF_NULL, STAFF_FIRE];
  Monsters := [NPC_DEMON_LESSER];
end;

how about do something like STAFF_NONE

that way its not a -1 and when it sees that, it just doesn't equip a staff or just doesn't change the staff out.

E: i like STAFF_NULL better than mine.

I personally like staff_none. its a bit more "friendly", hahaha. Personally, I don't see too much of a point in having 2 spells to cast. But hey, more functionality is good.
Thanks for getting this along coh3n. Helps a ton.

EDIT: Oops, I neglected to mention that I also thing an automated system (with user over-ride of course) would be a bit nicer imho. (was supposed to roll that in with my comment about multipul spells :redface: meh)

I think an automatic system would work better. Use a detection system for the staff(s) in the inventory/equipped and use which ever one depending on the spell your casting and/or runes required.

From: Narcle
I think an automatic system would work better. Use a detection system for the staff(s) in the inventory/equipped and use which ever one depending on the spell your casting and/or runes required.

I like it. :) My original idea was something like that, but I think I was over-complicating it.

I think I'll do this - find which staffs are in the inventory/equipped. It will then calculate how many casts it can make for individual runes, then it will equip the staff associated with rune type that can cast the least amount. If the chosen rune doesn't have a staff, it will move on to the next rune. That may be unclear so here:

• A player has 150 air runes, 100 laws and 100 water runes.
• Using MSI_CalculateCasts, there are enough air runes to cast 30 Falador Teleports, and enough laws and water runes for 100 casts.
• Therefore, air runes have the lowest amount of casts and an air staff will be equipped.
• The final number of casts will be set to the lowest number of casts between water and law runes.

Hopefully that's understandable. :p

If there any logical flaws in that let me know.

I'd say do things in order.

If the first spell uses 3 airs, 2 waters and 1 law, use an air staff, you'll be saving the most amount of money.

If the next spell uses 4 fires and 2 earths, use a fire staff. If there isn't a fire staff, use an earth staff.

Go by amount of money saved I'd say :-)

~RM

From: Sir R. Magician
I'd say do things in order.

If the first spell uses 3 airs, 2 waters and 1 law, use an air staff, you'll be saving the most amount of money.

If the next spell uses 4 fires and 2 earths, use a fire staff. If there isn't a fire staff, use an earth staff.

Go by amount of money saved I'd say :-)

~RM

I was thinking of this as well, but it should also consider what runes the player has. Maybe they did some runecrafting so they have a bunch of runes left over from it etc.

If the player wants to save money leave that up to them no?

From: Narcle
I was thinking of this as well, but it should also consider what runes the player has. Maybe they did some runecrafting so they have a bunch of runes left over from it etc.

If the player wants to save money leave that up to them no?

I wanted to do exactly what RM said, but then nickrules explained exactly what you did.

You'll always want to leave it up to the user as to which staff to use.

Maybe have three settings - most money saved, most casts, then user set staff to use. The user sets which one, and if they don't set one, it defaults to most casts (more exp, no?). So if they set most money saved, it uses Sir R's idea, most casts uses Coh3n's second idea (or third, or whatever it was), and user set uses the staffs in the order it's set (like in the original post).

Also, I like STAFF_NULL or STAFF_NONE for no staff specified :).

From: Sandstorm
Maybe have three settings - most money saved, most casts, then user set staff to use. The user sets which one, and if they don't set one, it defaults to most casts (more exp, no?). So if they set most money saved, it uses Sir R's idea, most casts uses Coh3n's second idea (or third, or whatever it was), and user set uses the staffs in the order it's set (like in the original post).

Also, I like STAFF_NULL or STAFF_NONE for no staff specified :).

We could, but I that's over-complicating it. If the staff is automatically detected that means the user chooses which staffs to put in their inventory, so there's really no need to have them specify in DeclarePlayers.

It would just look for a staff and use the one based off what runes the player has in their inventory. Also, most money saved could change easily if, for example, water runes were to rise in price so that one water rune would be the same as 4 air runes.

From: Coh3n
We could, but I that's over-complicating it. If the staff is automatically detected that means the user chooses which staffs to put in their inventory, so there's really no need to have them specify in DeclarePlayers.

It would just look for a staff and use the one based off what runes the player has in their inventory. Also, most money saved could change easily if, for example, water runes were to rise in price so that one water rune would be the same as 4 air runes.

Yes, it would over-complicate it a lot, I was just offering a suggestion ^.^.

:norris:

From: Coh3n
I like it. :) My original idea was something like that, but I think I was over-complicating it.

I think I'll do this - find which staffs are in the inventory/equipped. It will then calculate how many casts it can make for individual runes, then it will equip the staff associated with rune type that can cast the least amount. If the chosen rune doesn't have a staff, it will move on to the next rune. That may be unclear so here:

• A player has 150 air runes, 100 laws and 100 water runes.
• Using MSI_CalculateCasts, there are enough air runes to cast 30 Falador Teleports, and enough laws and water runes for 100 casts.
• Therefore, air runes have the lowest amount of casts and an air staff will be equipped.
• The final number of casts will be set to the lowest number of casts between water and law runes.

Hopefully that's understandable. :p

If there any logical flaws in that let me know.

how would it calculate the bolded portion?

From: TomTuff
how would it calculate the bolded portion?

Spell to be cast, runes needed for the spell, runes in inventory, divide.

From: Sandstorm
Spell to be cast, runes needed for the spell, runes in inventory, divide.

so say you want to use varrock teleport, it calculates…
* spells with all 3 runes used
* spells with fire/air
* spells with fire/law
* spells with law/air

It's not all that complicated… :-)

// Prices.Simba

function getPrice(what: integer): integer;
begin
  case //...
end;

function getMostExpensive(which: TIntegerArray): integer;
begin
  //...
end;

//In Magic
{*
This still needs to have some thinking through.
But I was considering adding to the spell's record or something, the price of it,
 or the most expensive rune that can be replaced by a staff..
*}

TSpell
  StaffRune: integer;

//this can be figured out each run, before choosing what staff to use.

{*
StaffRune can also be used to just simply choose the staff. If the user has a prefference,
 we can set that rune as the StaffRune. :-)
*}

{*
Last but not least, the prices in Prices.Simba wouldn't be that hard to maintain.
Several priceGrabbers have been made,
and we could just use one of those to spit the prices out.

Also, we can debug our current info, so the user can see if the prices are up to date or not ;)

If they aren't, the user could run the price grabber and spit the new ones out, 
or the user could just grab the latest price for one object and post it,
or the user could just update it for his own script.
*}

This is what I've always pictured in MSI… a script that can actually have all the coolest features out there!

I'd also love to see things like gaussian mouse implemented!

I am to blame that I haven't been around that much, but the potential is all still here! :-)

~RM

I agree with RM :p
MSI is "super-duper-all-in-one-do-everything-there-ever-is-or-will-be mass compilation of scripts" + do it like a human :)

From: TomTuff
how would it calculate the bolded portion?

Here's the one I've tested. It works (assuming all the runes in the inventory were counted correctly).

{******************************************************************************}
{ function MSI_CalculateCasts: TIntegerArray;                                  }
{ By: nickrules & Coh3n                                                        }
{ Date: 09 November 2010                                                       }
{ Description: Returns the number of casts per spell the player can cast       }
{******************************************************************************}
function MSI_CalculateCasts: TIntegerArray;
var
  i, j, lo, spellMode, spellIndex: Integer;
  runeAmounts, casts: TIntegerArray;
begin
  MSI_AddHeader('MSI_CalculateCasts');

  with MSI_Players[CurrentPlayer].Scripts[CurrentScript] do
  begin
    SetLength(Result, Length(Spells));
    runeAmounts := MSI_GetRunesFound(); // All the runes found in the inventory

    // Debug the runes found in the inventory
    for i := 0 to High(runeAmounts) do
    begin
      if (runeAmounts[i] <= 0) then // Don't debug the runes that aren't found
        Continue;

      MSI_Debug(Capitalize(MSI_Items[runeAmounts[i] + MSI_RUNE_AIR].Name)+
                's found: '+IntToStr(runeAmounts[i]));
    end;

    for i := 0 to High(Spells) do
    begin
      spellMode := MSI_GetSpellMode(Spells[i], spellIndex);

      with SpellModes[spellMode][spellIndex] do
      begin
        SetLength(casts, Length(RequiredRunes));

        // Debug number of casts per individual rune type
        for j := 0 to High(RequiredRunes) do
        begin
          casts[j] := Floor(runeAmounts[RequiredRunes[j]] div RequiredRuneAmount[j]); // Rounds down
          MSI_Debug('Enough '+MSI_Items[RequiredRunes[j]+MSI_RUNE_AIR].Name+
                    's to cast '+ IntToStr(casts[j])+' '+Capitalize(Name)+'s');
        end;

        // Set the result to the maximum number of casts depending on the runes found
        for j := 0 to High(casts) do
        begin
          // Get the lowest number of calculated casts
          if (j = 0) then
            lo := casts[j]
          else
            if (casts[j] < lo) then
              lo := casts[j];

          if (j = High(casts)) then
          begin
            Result[i] := lo;
            MSI_Debug('Player can cast '+IntToStr(Result[i])+' '+Capitalize(Name)+'s');
          end;
        end;

        // Decrease the amount of runes found because they've been 'used' for another spell
        for j := 0 to High(RequiredRunes) do
        begin
          DecEx(runeAmounts[RequiredRunes[j]], (Result[i] * RequiredRuneAmount[j]));
          MSI_Debug('Rune ['+IntToStr(RequiredRunes[j])+'] left: '+IntToStr(runeAmounts[RequiredRunes[j]]));
        end;
      end;
    end;
  end;

  MSI_CloseHeader('MSI_CalculateCasts: ' + ToStr(Result));
end;                                  

From: Sir R. Magician
It's not all that complicated… :-)

// Prices.Simba

function getPrice(what: integer): integer;
begin
  case //...
end;

function getMostExpensive(which: TIntegerArray): integer;
begin
  //...
end;

//In Magic
{*
This still needs to have some thinking through.
But I was considering adding to the spell's record or something, the price of it, or the most expensive rune that can be replaced by a staff..
*}

TSpell
  StaffRune: integer;

//this can be figured out each run, before choosing what staff to use.

{*
StaffRune can also be used to just simply choose the staff. If the user has a prefference, we can set that rune as the StaffRune. :-)
*}

{*
Last but not least, the prices in Prices.Simba wouldn't be that hard to maintain.
Several priceGrabbers have been made, and we could just use one of those to spit the prices out.

Also, we can debug our current info, so the user can see if the prices are up to date or not ;)

If they aren't, the user could run the price grabber and spit the new ones out, 
or the user could just grab the latest price for one object and post it,
or the user could just update it for his own script.
*}

This is what I've always pictured in MSI… a script that can actually have all the coolest features out there!

I'd also love to see things like gaussian mouse implemented!

I am to blame that I haven't been around that much, but the potential is all still here! :-)

~RM

I was thinking about a function that returns all the possible staffs for a certain spell. It would return the array in an order from most money saved to the least.

function MSI_GetPossibleStaffs(Spell: Integer): TIntegerArray;
begin
end;

So that depending on the spell, it would first look for the the staff that saves the most money, then the next one. This would work very similar to how we have MSI_BestTool and MSI_WorstTool setup for woodcutting and mining, except it would be based off GE prices rather than skill levels.

E:

From: Zyt3x
I agree with RM :p
MSI is "super-duper-all-in-one-do-everything-there-ever-is-or-will-be mass compilation of scripts" + do it like a human :)

Right, but a human may not always go with the cheaper choice. They may want to get rid of a ton of fire runes. I remember when I played, I always seemed to have 1000 times more fire runes than any other. If we did was I said above, I think that would be the best of both worlds.

From: Coh3n

E:
Right, but a human may not always go with the cheaper choice. They may want to get rid of a ton of fire runes. I remember when I played, I always seemed to have 1000 times more fire runes than any other. If we did was I said above, I think that would be the best of both worlds.

I'd say just actually get the best of both worlds…

StaffToUse: (Most Casts, Cheapest, Specific)

~RM

I actually never do it like that, Coh3n :O I guess it differs from player to player. But anyways… more options = better!

From: Sir R. Magician
I'd say just actually get the best of both worlds…

StaffToUse: (Most Casts, Cheapest, Specific)

~RM

Yeah, that would work too, but I was trying to avoid having the user to have to set the staff in DeclarePlayers.

How about, by default, it does what I said. That is, if the user doesn't specify. I think having it do most casts would be the best for default. What do you guys think?

From: Zyt3x
I actually never do it like that, Coh3n :O I guess it differs from player to player. But anyways… more options = better!

That's why I said "may not". :p

From: Coh3n
That's why I said "may not". :p

right…:cartman:

alrighty, back from a long tournament.

Seems to me that we need a way of dumping the prices of a ton of items, correct?
Shouldn't be too hard - we would just need the item IDs

Then its a matter of just using things like Replace(), trim(), etc. If im not mistaken, I made one of these awhile ago…

Edit(not really?): :duh: Wth is a TReplaceFlag? because it seems that simba likes to add parameters that I don't know about, until I get to working on something :p

But other than that, making something to grab the prices wouldn't be hard.

From: nickrules
alrighty, back from a long tournament.

Seems to me that we need a way of dumping the prices of a ton of items, correct?
Shouldn't be too hard - we would just need the item IDs

Then its a matter of just using things like Replace(), trim(), etc. If im not mistaken, I made one of these awhile ago…

Edit(not really?): :duh: Wth is a TReplaceFlag? because it seems that simba likes to add parameters that I don't know about, until I get to working on something :p

But other than that, making something to grab the prices wouldn't be hard.

Da 0wner wrote this for me over a year ago. Still works in SCAR, but needs to be converted to Simba, and I'm not sure how. :o There aren't the same string functions in Simba as in SCAR.

program GESearcher;

type
  TItem = record
    Name : string;
    ID : integer;
    Mini, Mid, Maxi : variant;
  end;

var
  Item : TItem;

function Multiplicand(s : string) : integer;
begin
  result := integer(pos('k', s) > 0) * 1000;
  if result > 0 then
    exit;
  result := integer(pos('m', s) > 0) * 1000000;
end;

function GetItem(ID : integer) : TItem;
var
  s : string;
begin
  s := GetPage('http://itemdb-rs.runescape.com/viewitem.ws?obj=' + IntToStr(ID));
  if s = '' then
    exit;
  with Result do
  begin
    Mini := TrimEx(#10, Between('<b>Minimum price:</b> ', '</span>', s));
    Mini := StrToFloat(Trim(TrimLetters(Mini))) * Multiplicand(Mini);
    Mid := TrimEx(#10, Between('<b>Market price:</b> ', '</span>', s));
    Mid :=StrToFloat(Trim(TrimLetters(Mid))) * Multiplicand(Mid);
    Maxi := TrimEx(#10, Between('<b>Maximum price:</b> ', '</span>', s));
    Maxi := StrToFloat(Trim(TrimLetters(Maxi))) * Multiplicand(Maxi);
    Name := TrimEx(#10, Between('<div class="subsectionHeader">', '</div>', Copy(s, 13000, length(s))));
  end;
  Result.ID := ID;
end;

function GetID(Name : string) : integer;
var
  s : string;
begin
  s := GetPage('http://itemdb-rs.runescape.com/results.ws?query=' + Name + '&price=all&members=');
  Result := StrToIntDef(Between('sprite.gif?id=', '" alt', s), -1);
end;

procedure DebugItem(Item : TItem);
begin
  with Item do
  begin
    Writeln('Name: ' + Name);
    Writeln('ID: ' + IntToStr(ID));
    Writeln('Minimum Price: ' + IntToStr(Mini));
    Writeln('Market Price: ' + IntToStr(Mid));
    Writeln('Maximum Price: ' + IntToStr(Maxi));
  end;
end;

begin
  Item := GetItem(GetID('Rake'));
  DebugItem(Item);
end.

E: A little update: It now finds and equips the staff for the current spell. Of course, it's a lot more complicated and accurate than that, so you can take a look if you need to. ;) I also changed the attribute in TScriptSetup from AlchItems to AlchSlots, that way the user just says the slot the item is in so it can alch any item rather than just the ones we have records for, make sense?

Here's a present:

program GESearcher;

type
  TItem = record
    Name : string;
    ID : integer;
    Mini, Mid, Maxi : variant;
  end;

var
  Item : TItem;

function Multiplicand(s : string) : integer;
begin
  result := integer(pos('k', s) > 0) * 1000;
  if result > 0 then
    exit;
  result := integer(pos('m', s) > 0) * 1000000;
  if (result = 0) then
    result := 1;
end;

function TrimLetters(s : string) : string;
var
  LetterArray: TStringArray;
  i: Integer;
begin
  LetterArray := ['a','b','c','d','e','f','g','h','i','j','k','l','m','n','o',
    'p','q','r','s','t','u','v','w','x','y','z'];
  result := s;
  for i := 0 to Length(LetterArray) - 1 do
    result := Replace(result, LetterArray[i], '', [rfReplaceAll, rfIgnoreCase]);
end;

function GetItem(ID : integer) : TItem;
var
  s : string;
begin
  s := GetPage('http://itemdb-rs.runescape.com/viewitem.ws?obj=' + IntToStr(ID));
  if s = '' then
    exit;
  with Result do
  begin
    Mini := Replace(Between('<b>Minimum price:</b> ', '</span>', s),
      #10, '', [rfReplaceAll]);
    Mini := StrToFloat(Trim(TrimLetters(Mini))) * Multiplicand(Mini);
    Mid := Replace(Between('<b>Market price:</b> ', '</span>', s),
      #10, '', [rfReplaceAll]);
    Mid :=StrToFloat(Trim(TrimLetters(Mid))) * Multiplicand(Mid);
    Maxi := Replace(Between('<b>Maximum price:</b> ', '</span>', s),
      #10, '', [rfReplaceAll]);
    Maxi := StrToFloat(Trim(TrimLetters(Maxi))) * Multiplicand(Maxi);
    Name := Replace(Between('<div class="subsectionHeader">', '</div>',
      Copy(s, 13000, length(s))) , #10, '', [rfReplaceAll, rfIgnoreCase]);
    Name := Between('<h2>', '</h2>', Name);
  end;
  Result.ID := ID;
end;

function GetID(Name : string) : integer;
var
  s : string;
begin
  s := GetPage('http://itemdb-rs.runescape.com/results.ws?query=' + Name + '&price=all&members=');
  Result := StrToIntDef(Between('sprite.gif?id=', '" alt', s), -1);
end;

procedure DebugItem(Item : TItem);
begin
  with Item do
  begin
    Writeln('Name: ' + Name);
    Writeln('ID: ' + IntToStr(ID));
    Writeln('Minimum Price: ' + IntToStr(Mini));
    Writeln('Market Price: ' + IntToStr(Mid));
    Writeln('Maximum Price: ' + IntToStr(Maxi));
  end;
end;

begin
  Item := GetItem(GetID('Rake'));
  DebugItem(Item);
end.

Very nice, thanks! :D

From: Coh3n
Very nice, thanks! :D

Make sure you use the edited version, I accidentally had 'r,' in the letter array.

From: mormonman
Make sure you use the edited version, I accidentally had 'r,' in the letter array.

Okay. Also, it takes a few seconds to actually get the information. I'm assuming that's not really avoidable? Will just have to warn the users when choosing to use that method.

From: Coh3n
Okay. Also, it takes a few seconds to actually get the information. I'm assuming that's not really avoidable? Will just have to warn the users when choosing to use that method.

Ya, because it has to open a connection to the internet and then download the page. Every bot that doesn't store prices has to do this. You could always just store the prices in a file in the msi include and update it like once a week. It could be a global prices file for all items, and then for collecting scripts you could add cash gained per hour to the proggy. Just an idea.

From: mormonman
Ya, because it has to open a connection to the internet and then download the page. Every bot that doesn't store prices has to do this. You could always just store the prices in a file in the msi include and update it like once a week. It could be a global prices file for all items, and then for collecting scripts you could add cash gained per hour to the proggy. Just an idea.

I actually really like that idea. Definitely something I'd like to add in the future once I can knock the rest of the stuff of my to-do list. :)

From: Coh3n
I actually really like that idea. Definitely something I'd like to add in the future once I can knock the rest of the stuff of my to-do list. :)

It doesn't seem like a hard thing to do…pawn it off on somebody haha!

From: Coh3n

E: A little update: It now finds and equips the staff for the current spell. Of course, it's a lot more complicated and accurate than that, so you can take a look if you need to. ;) I also changed the attribute in TScriptSetup from AlchItems to AlchSlots, that way the user just says the slot the item is in so it can alch any item rather than just the ones we have records for, make sense?

I would imagine in any alch script that we have, we'll drag the item so the mouse doesn't need to be moved between clicking the spell and item. With that being said, Slot numbers may not be the best way to go about it. People are going to be alching noted items anyways so item records wouldn't work right, unless perhaps we add a 'NoteBmp' attribute to each item record? Not sure your feelings on that, but it's the simplest thing that comes to mind right now (only 6 am).

From: mormonman
Ya, because it has to open a connection to the internet and then download the page. Every bot that doesn't store prices has to do this. You could always just store the prices in a file in the msi include and update it like once a week. It could be a global prices file for all items, and then for collecting scripts you could add cash gained per hour to the proggy. Just an idea.

From: Coh3n
I actually really like that idea. Definitely something I'd like to add in the future once I can knock the rest of the stuff of my to-do list. :)

Perhaps on script start up we could save all the prices to an INI? That way no one would have to manually update and it should be more accurate than a once a week update.

Note bmps of every object would be a pain in the ass..

you could use the bank's search box to find the right item. Take it out as a note, and just keep track of the note's x n y or something.

You can also just make a bmp of it, during runtime..

~RM

From: NCDS
Perhaps on script start up we could save all the prices to an INI? That way no one would have to manually update and it should be more accurate than a once a week update.

That would lag the startup really badly.

Edit: You could just date the ini and when it is however many days old, update it.

From: mormonman

Edit: You could just date the ini and when it is however many days old, update it.

Sounds cool. The amount of days can be a constant. People set it to whatever they want.

I guess there could also be one on whether to update or not.

:)

~RM

From: NCDS
I would imagine in any alch script that we have, we'll drag the item so the mouse doesn't need to be moved between clicking the spell and item. With that being said, Slot numbers may not be the best way to go about it. People are going to be alching noted items anyways so item records wouldn't work right, unless perhaps we add a 'NoteBmp' attribute to each item record? Not sure your feelings on that, but it's the simplest thing that comes to mind right now (only 6 am).

We would still drag the item to the right slot, but instead of looking for an item, it just drags from one slot to another.

With that, though, we wouldn't be able to withdraw items from the bank because we don't know what to look for.

From: Coh3n
We would still drag the item to the right slot, but instead of looking for an item, it just drags from one slot to another.

With that, though, we wouldn't be able to withdraw items from the bank because we don't know what to look for.

Type in the exact name of it in the search bar, withdraw the first item, find the last inventory spot full, that's your item.

Alright, seems great. these small problems have been solved.

As for updating:
* what if someone who knew a smidge about php made webpage

* said webpage then grabbed the Item-DB price of every item (or a specific list of items, seeing as there are a TON of items), every day (every other day? week? whatever)

* Then, the bot would just connect to that site when it turns on and figures out what the user is using, post the values (using postdata or w/e it is). Then the website spits out the result.

With work, this could even hold information on things other than price. It could store things like name, price, uptext, etc.

Or perhaps im not completely understanding the problem with laggy updating, etc. But it would go faster, as the client wouldn't need to download all the images and other junk. just a few words. But it would be pretty nifty. Sadly I dont know any php >_>
Just a thought.
But I'll look into it. :rolleyes:

From: nickrules
Alright, seems great. these small problems have been solved.

As for updating:
* what if someone who knew a smidge about php made webpage

* said webpage then grabbed the Item-DB price of every item (or a specific list of items, seeing as there are a TON of items), every day (every other day? week? whatever)

* Then, the bot would just connect to that site when it turns on and figures out what the user is using, post the values (using postdata or w/e it is). Then the website spits out the result.

With work, this could even hold information on things other than price. It could store things like name, price, uptext, etc.

Or perhaps im not completely understanding the problem with laggy updating, etc. But it would go faster, as the client wouldn't need to download all the images and other junk. just a few words. But it would be pretty nifty. Sadly I dont know any php >_>

But I'll look into it.

Storing the prices in the msi include is still the best idea imho. No reason to do more work than is needed for something that will be just fine without it.

I guess, it just seems that it would take awhile to download all the information it would need. several seconds for each item, unless I was mislead by coh3ns post.

From: nickrules
I guess, it just seems that it would take awhile to download all the information it would need. several seconds for each item, unless I was mislead by coh3ns post.

Yeah, but it the prices were updated every couple weeks, then there'd only be the lag once in a while.

From: nickrules
I guess, it just seems that it would take awhile to download all the information it would need. several seconds for each item, unless I was mislead by coh3ns post.

But that is easily handled once a week. Its going to take time no matter what.

Since when are prices only updated once a week though?

I would thin in order to be accurate it would need to be done daily?

From: NCDS
Since when are prices only updated once a week though?

I would thin in order to be accurate it would need to be done daily?

Depends on what items we're talking about, and what we'll be using the prices for. If we use just items we have records for such as logs, ores, and fish, the prices aren't going to change that much and if we're using the prices to get a rough "money gained" feature, I don't think the difference of a few GP would make much of a difference.

RS updates their database every day (last time I checked). this does NOT mean that a particular items price changed, but any item which did change will have been updated. For example, rune prices barely change (for the elementals at least), meanwhile, some items can go up 10% (or more) in a week.

From: NCDS
Since when are prices only updated once a week though?

I would thin in order to be accurate it would need to be done daily?

They are updated like every 12 hours or something. But that would be way too much work. The prices used by nexus and all the resellers are something like 2 months old…so ours would be an upgrade from that doing it once a week. As RM said, we could just make it the user's choice when to update the prices.

If we only updated the prices of items the player would be using, BEFORE the log in, it wouldn't look suspicious at all, and wouldn't/shouldn't take that long.

From: mormonman
As RM said, we could just make it the user's choice when to update the prices.

Yeah, that's a definite.

From: nickrules
If we only updated the prices of items the player would be using, BEFORE the log in, it wouldn't look suspicious at all, and wouldn't/shouldn't take that long.

That's kind of what I was originally thinking, but just giving the option of how often to update seems reasonable to me.