Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » zMUD General Discussion
Scotty357990
Newbie


Joined: 21 Jul 2005
Posts: 4
PostPosted: Thu Jul 21, 2005 5:59 am   

Trigger for a DB, and advice on the whole concept
 
I apologise in advance - this is a rather long one. I've read the forums and help docs etc, but due to the complexity of things I'm not having much luck. The actual questions I've asked are in bold

I get a list of items in response to a command.

The list is dynamic - ie depending on what we have in stock, the list will change. If there are 0 of an item it doesn't show up. Therefore, in that there are 2 items per line (with padding) it is common for the lines to vary freqently.

Below is a excerpt of the output from the command:

Code:

------------------------------------------------------------------------------
         Part listing for Whatever - Bay One         
------------------------------------------------------------------------------
Ammo IS AC/10                       12 Ammo IS AC/2                        12
Ammo IS AC/20                       12 Ammo IS AC/5                        12
Ammo IS Anti-MissileSystem          11 Ammo IS GaussRifle                   7
Ammo SSRM                           13 Ammo IS UltraAC/10                   2
Ammo IS UltraAC/2                    2 Ammo IS UltraAC/20                   7
Ammo IS UltraAC/5                    2 Actuator                           154
Armor                               1K Axe                                  7
BeagleProbe                          1 Bical IS Anti-MissileSystem          1
Bical IS LRM-10                      1 Bical IS LRM-15                     12
Bical IS LRM-20                      7 Bical IS LRM-5                       1
Bical IS StreakSRM-4                 3 Bical IS StreakSRM-6                 1
C3Master                             1 C3Slave                              2
C3i                                  1 Cockpit                              7
Double HeatSink                     12 ES Internal                        892
Ecm                                  1 Electric                           118
Engine                              25 FF Armor                            1K
Firestorm IS Flamer                  1 Gyro                                21
HeatSink                            15 Holly IS LRM-10                      2
Holly IS LRM-5                       2 Holly IS SRM-2                       2
Holly IS SRM-4                       4 Holly IS SRM-6                       1
Oriente IS LB10-XAC                  1 Oriente IS LB20-XAC                  1
Oriente IS LB2-XAC                   1 Oriente IS LB5-XAC                   1
Oriente IS LightGaussRifle           1 Oriente IS MachineGun                1
Oriente IS RotaryAC/2                1 Oriente IS RotaryAC/5                1
Oriente IS UltraAC/10                1 Oriente IS UltraAC/2                 1
Oriente IS UltraAC/20                1 Oriente IS UltraAC/5                 1
Sensors                             11 Sword                                1
TAG                                  2 VTOL Fuel                          13K
XL Engine                           12
------------------------------------------------------------------------------

The list is pretty long, and it's a pain to have to work through it manually to ascertain those items which have insufficient stock.

Please note - it's all fixed width fonts etc and the space between the two parts is always at character 39 of the line and the last digit of the line is always character 77.


So what I want to do is keep track of all the stores possible (I've compiled a list): The current amount in stock, a reserve amount, AND the variation since I last ran the command. Actually - I'd like a weeks worth of history for each item ... but I figure that's being greedy <g> and it's not really necessary and would complicate things beyond a joke.


This strikes me as the kind of problem that computers are brilliant at - but it seems that I'm not being brilliant lately <g>.

I would assume a DB is the best way to go with this. Yes?


I guess this problem boils down to 3 parts:

Creating the db (and entering reserve levels)

Making a trigger (or triggers) which will enter the new stock levels when I run the command

Running a calculation over the two figures (on hand and the required reserve) to show the variation since the last run AND notify me of any items which are below reserve.

----------

With regards the DB:
I created a partial DB (didn't enter all the items) with a field for each items name, it's current amount, it's reserve, and it's variation and a boolean field called Updated. Here's a sample record:

Part Name: Ammo IS AC/2
Reserve: 0
Current: 0
Variation: 0
Updated: 0 (more on this field later)

(Reserve, Current and variation are number type fields)

Is this the best way to set up the DB for this?

----------

With regards the trigger:
I have tried a number of approaches, but simply cannot seem to come up with a trigger which works.

I have this trigger which enables the Class 'Stores' when I run the command:

Pattern: Part listing for Whatever - Bay One
Value: #class {Stores} (1)

Within the Stores class I have a trigger which disables that class when the second of the lines full of dashes are parsed:

Pattern: ------------------------------------------------------------------------------
Value: #add $Lines 1
#if ($Lines < 1) {
#var Lines 0
#class Stores 0
}

(I note this is pretty ugly - is there a better approach?)

The above two triggers work - which leaves me with the trigger(s) to parse the part names and amounts:

It seems to me that, logically, a single trigger should do the job of parsing the name of the part, and it's amount - but I keep tripping up. Please note - as the above sample shows, items with more than 999 in stock show as nK ... this needs to be converted to n000, which is part of what keeps tripping me up.

Can someone suggest a trigger which will work? Do I need multiple triggers?

Also - once in a while an item which I do not have in the DB may appear. Ideally I'd like this to be brought to my attention so that I could manually enter the item into the DB.

----------

With regards to the calculation:

As a part with 0 in stock is not reported by the command, it seems to me that I need to identify those items which were not updated before I make my calculations. This is where the boolean field 'Updated' comes in. Before the trigger(s) gets run I plan on setting the updated field for ALL records to 0. If the trigger DOES update the current field, then the Updated field would be set to 1 at the same time. Then before the calculations are made, I check each record and IF the boolean field is still 0, then I set the Current amount to 0 because clearly there are no items of that part in store.

This will work - but can anyone suggest a better approach?


Thanks for reading all the way through this <g>
Reply with quote
Aarlot
Adept


Joined: 30 Dec 2003
Posts: 226
PostPosted: Thu Jul 21, 2005 8:21 am   
 
Hmmm... personally, I think i'd use 3 db variables rather than an actual db.

Don't have time to do the actual coding atm, but something where you have all the items listed in each db variable. One would be a static db, with keys being the names of the items, and values being the reserve amount. The second would be the numbers from the previous check. And the third would be the one you use to check against the other two.

Then you'd have an alias, checkstock or something, that set all the values in the working dbvar to 0, then did the command to check the stock in the mud. Triggers from that would set the values (Using #ADDK) of the working dbvar to whatever the stock is. Then you could do a loopdb to compare it to the previous dbvar and the static, reserve dbvar, adding changes to a normal var as stringlist items, which you could display. And finally, the change the previous dbvar to match the working dbvar, and you're done. I can see in my mind how this would be done, just don't have time to do it right now. I may come back tomorrow and work on it if someone else hasn't already.
_________________
Everyone is entitled to their beliefs - until they die. Then only the truth matters.		 Reply with quote
Scotty357990
Newbie


Joined: 21 Jul 2005
Posts: 4
PostPosted: Thu Jul 21, 2005 3:25 pm   
 
Aarlot wrote:
Hmmm... personally, I think i'd use 3 db variables rather than an actual db.



I think I follow - certainly I get your drift sufficiently so that I can experiment and probably get somewhere.

Once I figure out a suitable trigger(s) <g>.

One question though: What would be the benefit of this approach over my original concept?
Reply with quote
nexela
Wizard


Joined: 15 Jan 2002
Posts: 1644
Location: USA
PostPosted: Thu Jul 21, 2005 10:50 pm   
 
Couple of ways to do the triggering part it, Here is one (please not the $ end of line char may need to be moved over 1 spot on each per line trigger (SpaceTHEN$)), Sticks the values in a datarecord for now!

Code:
#TRIGGER "partlisting" {^         Part listing for (*) - (*)} {//code here}
#COND {^------------------------------------------------------------------------------$} {
 #T+ twoperline
 #T+ oneperline
 #PRIO {#LOOPDB @PartList {#ADDKEY PartList {%key} {0}}} //Loops through Var and sets all values to 0
} {within|param=1}
#COND {^------------------------------------------------------------------------------$} {
 #T- twoperline
 #T- oneperline
}
#TRIGGER "twoperline" {^(&33)(&5) (&33)(&5)$} {
 #ADDKEY PartList {%trim("%1")} {%trim(%replace("%2","K","000"))}
 #ADDKEY PartList {%trim("%3")} {%trim(%replace("%4","K","000"))}
}
#TRIGGER "oneperline" {^(&33)(&5)$} {
 #ADDKEY PartList {%trim("%1")} {%trim(%replace("%2","K","000"))}
}


and to take a glance at the Variable
#say %expanddb(@CurList)
_________________
Zmud Support Library
Zmud Knowledge Base

Last edited by nexela on Fri Jul 22, 2005 11:46 pm; edited 1 time in total		 Reply with quote
Scotty357990
Newbie


Joined: 21 Jul 2005
Posts: 4
PostPosted: Fri Jul 22, 2005 11:45 am   
 
Code:
#TRIGGER "partlisting" {^         Part listing for (*) - (*)} {//code here}
#COND {^------------------------------------------------------------------------------$} {
 #T+ twoperline
 #T+ oneperline
 #LOOPDB @PartList {#ADDKEY PartList {%key} {0}} //Loops through Var and sets all values to 0
} {within|param=1}
#COND {^------------------------------------------------------------------------------$} {
 #T- twoperline
 #T- oneperline
}
#TRIGGER "twoperline" {^(&33)(&5) (&33)(&5)$} {
 #ADDKEY PartList {%trim("%1")} {%trim(%replace("%2","K","000"))}
 #ADDKEY PartList {%trim("%3")} {%trim(%replace("%4","K","000"))}
}
#TRIGGER "oneperline" {^(&33)(&5)$} {
 #ADDKEY PartList {%trim("%1")} {%trim(%replace("%2","K","000"))}
}


I've worked through this, and think I have grasped most of it thus far.

But I'm thrown by the triggers "twoperline" and "oneperline" - I can't follow them.

Doesn't the &33 (for example) mean that the value is stored in a variable called 33? Clearly not - or you wouldn't have suggested it - but I don't get it.

EDIT: I've played some more and see how this trigger works. Mind you - I still can't figure out why it works - unless it's a case of &x stores the value in a variable UNLESS x = number in which case it becomes a fixed width object for pattern matching?

I've experimented, and it seems to me that the triggers (oneperline and twoperline) match any line at all - and that the COND statements are there to enable and disable the triggers so that they are only active during that period when the data from the command is being output. Is this what is supposed to be happening? If so - it's a much better approach than I had and I thank you for it.

I figure I can get it on my own from here.

Thanks again
Reply with quote
demoneyoungblood
Apprentice


Joined: 16 Dec 2002
Posts: 114
Location: USA
PostPosted: Fri Jul 22, 2005 9:00 pm   
 
The &33 and &5 tell zmud that the data to be stored is a fixed width variable. Ie: store 33 characters for &33 and store 5 characters for &5
_________________
-Demone YoungBlood		 Reply with quote
nexela
Wizard


Joined: 15 Jan 2002
Posts: 1644
Location: USA
PostPosted: Fri Jul 22, 2005 11:45 pm   
 
Yes it looks for a *fixed width pattern* And the multistate #COND trigger keeps it from matching the wrong lines, This COULD be done with one less trigger but for readabilitys sake I used two.

And Actually there is a *minor* bug in my posted code I have edited the post above to reflect THIS change to reset all the Values to 0 BEFORE it starts changing them,
Looping statements are executed in the background unless inside a #PRIORITY statement

#PRIO {#LOOPDB @PartList {#ADDKEY PartList {%key} {0}}}
_________________
Zmud Support Library
Zmud Knowledge Base		 Reply with quote
Scotty357990
Newbie


Joined: 21 Jul 2005
Posts: 4
PostPosted: Mon Jul 25, 2005 4:13 am   
 
I seem to be having further difficulty (not surprising really <g>).

It seems to me that there may be some kind of limitation on the database module of which I was not aware.

This is a modified version of my code. I've boiled it down (removing a lot) for debugging - trying to find the problem.

Code:

#var item %concat( ~", {%trim( "%1")}, ~")
#say $item is the var
#say ... %query( &PartName = $item) ...
#say {%trim( %replace( "%2", "K", "000"))}
#var item %concat( ~", {%trim( "%3")}, ~")
#say $item is the var
#say ... %query( &PartName = $item) ...
#say {%trim( %replace( "%4", "K", "000"))}



Here's an excerpt of the list returned by the mux:

Code:

Ammo IS LightGaussRifle              1 Actuator                             1
Electric                             1 FF Armor                             1


Here's the result from the code above (running off a trigger)

Code:

Ammo IS LightGaussRifle              1 Actuator                             1
"Ammo IS LightGaussRifle" is the var
...  ...
1
"Actuator" is the var
...  ...
1
Electric                             1 FF Armor                             1
"Electric" is the var
...  ...
1
"FF Armor" is the var
...  ...
1



Yet when I manually run the command

#say ... %query( &PartName = $item) ...

and insert any of the actual part names in place of the variable $item then it get the appropriate result. Hence the DB is open and I can assure you - every one of them items I'm doing the %query on are in it.

Code chunks I've found on the forum indicate that you can use a variable within the expression for a %query, and that obviously it can be used within a script.

Out of desperation I replaced the $item variable with an actual part name:

Code:

#var item %concat( ~", {%trim( "%1")}, ~")
#say $item is the var
#say ... %query( &PartName = "Actuator") ...
#say {%trim( %replace( "%2", "K", "000"))}
#var item %concat( ~", {%trim( "%3")}, ~")
#say $item is the var
#say ... %query( &PartName = "Electric") ...
#say {%trim( %replace( "%4", "K", "000"))}


And got the same result.

It seems as if the DB simply isn't responding quickly enough for the script .

When something that works manually doesn't work in a script I figure I'm better off asking for advice. <g>

I should note - because the mux uses @ for it's own purposes - I have to use $ for variables.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » zMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net