JESS: Ignore slots when matching lhs of rules

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

JESS: Ignore slots when matching lhs of rules

Hunter Mcmillen
Hi everyone, 

 I am trying to match the lhs of a rule using a template that has 112 slots that is defined from a Java class. 

 Here is the template definition (from show-deftemplates):

 (deftemplate MAIN::unit
            "$JAVA-OBJECT$ eisbot.proxy.model.Unit"
            (declare (from-class eisbot.proxy.model.Unit)))

Now every time that I encounter a unit object in my application I define an instance of the unit to Jess from Java:

engine.defclass("unit", "eisbot.proxy.model.Unit", null, true); (I only do this the first time)

Unit unit = //retrieve a unit
engine.definstance("unit", unit, false);

All of this above is working as it should be, but now when I try to match a unit in a rule I am having trouble:

String unitSeen = "(defrule unitSeen " + 
                          "(unit (ID ?id) (typeID ?typeID)) " + 
                          "=> " + 
                          "(printout t \"Unit seen with ID: \" ?id crlf))";

engine.executeCommand(unitSeen);

The problem is that the Unit class has 112 attributes, I am only listing two ID and typeID, and there are probably only another handful that I care about and need to use. Is there any way to ignore the rest of the slots in the template, matching only on a few slots? 

Goal: 

The main goal of what I am trying to is that when I encounter a Unit in my game application, I want to assert that unit object to Jess as a fact, then match rules on the existence of a Unit. Right now I only want to match on the existence of ANY unit, but later on the matches will be more specific.

Any help would be most appreciated.

Thanks.
Hunter McMillen
Reply | Threaded
Open this post in threaded view
|

[EXTERNAL] Re: JESS: Ignore slots when matching lhs of rules

Wolfgang Laun-2
You need not worry about the object fields you don't care about when matching the "unit" fact in a rule. By definition, only slots used in the pattern matter; all others are literally "don't care".

-W

On 11 November 2011 04:57, Hunter McMillen <[hidden email]> wrote:
Hi everyone, 

 I am trying to match the lhs of a rule using a template that has 112 slots that is defined from a Java class. 

 Here is the template definition (from show-deftemplates):

 (deftemplate MAIN::unit
            "$JAVA-OBJECT$ eisbot.proxy.model.Unit"
            (declare (from-class eisbot.proxy.model.Unit)))

Now every time that I encounter a unit object in my application I define an instance of the unit to Jess from Java:

engine.defclass("unit", "eisbot.proxy.model.Unit", null, true); (I only do this the first time)

Unit unit = //retrieve a unit
engine.definstance("unit", unit, false);

All of this above is working as it should be, but now when I try to match a unit in a rule I am having trouble:

String unitSeen = "(defrule unitSeen " + 
                          "(unit (ID ?id) (typeID ?typeID)) " + 
                          "=> " + 
                          "(printout t \"Unit seen with ID: \" ?id crlf))";

engine.executeCommand(unitSeen);

The problem is that the Unit class has 112 attributes, I am only listing two ID and typeID, and there are probably only another handful that I care about and need to use. Is there any way to ignore the rest of the slots in the template, matching only on a few slots? 

Goal: 

The main goal of what I am trying to is that when I encounter a Unit in my game application, I want to assert that unit object to Jess as a fact, then match rules on the existence of a Unit. Right now I only want to match on the existence of ANY unit, but later on the matches will be more specific.

Any help would be most appreciated.

Thanks.
Hunter McMillen

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: JESS: Ignore slots when matching lhs of rules

Hunter Mcmillen
This is what I thought it should be so I was confused when my rule wasn't firing. Thank you for your response. Somehow magically this morning the rule is firing as it should be. Ill attribute that to you :)

Thanks

On Fri, Nov 11, 2011 at 12:47 AM, Wolfgang Laun <[hidden email]> wrote:
You need not worry about the object fields you don't care about when matching the "unit" fact in a rule. By definition, only slots used in the pattern matter; all others are literally "don't care".

-W


On 11 November 2011 04:57, Hunter McMillen <[hidden email]> wrote:
Hi everyone, 

 I am trying to match the lhs of a rule using a template that has 112 slots that is defined from a Java class. 

 Here is the template definition (from show-deftemplates):

 (deftemplate MAIN::unit
            "$JAVA-OBJECT$ eisbot.proxy.model.Unit"
            (declare (from-class eisbot.proxy.model.Unit)))

Now every time that I encounter a unit object in my application I define an instance of the unit to Jess from Java:

engine.defclass("unit", "eisbot.proxy.model.Unit", null, true); (I only do this the first time)

Unit unit = //retrieve a unit
engine.definstance("unit", unit, false);

All of this above is working as it should be, but now when I try to match a unit in a rule I am having trouble:

String unitSeen = "(defrule unitSeen " + 
                          "(unit (ID ?id) (typeID ?typeID)) " + 
                          "=> " + 
                          "(printout t \"Unit seen with ID: \" ?id crlf))";

engine.executeCommand(unitSeen);

The problem is that the Unit class has 112 attributes, I am only listing two ID and typeID, and there are probably only another handful that I care about and need to use. Is there any way to ignore the rest of the slots in the template, matching only on a few slots? 

Goal: 

The main goal of what I am trying to is that when I encounter a Unit in my game application, I want to assert that unit object to Jess as a fact, then match rules on the existence of a Unit. Right now I only want to match on the existence of ANY unit, but later on the matches will be more specific.

Any help would be most appreciated.

Thanks.
Hunter McMillen