Problem with backreferences

I’ve been trying to find the right message board to post this question and this seems the closest to the problem I’m assuming I’m having.

This code:

if($Text.contains(“Latitude: (-?[0-9]{1,3}.[0-9])\n")) {$Latitude=$1} else {};
if($Text.contains("Longitude: (-?[0-9]{1,3}.[0-9]
)\n”)) {$Longitude=$1} else {};

is populating both the $Latitude and $Longitude with the same values.

Is this something to do with the the results from the first condition “bleeding” over into the second and therefore I need some sort of delay so that the computer can “catch up” or something else?

Thanks for any help.

I’m not capable of answering the “bleeding over” question, though I’ll be interested in what the actual experts say.

A question I do have from this code involves the else {} part. Are you leaving the part inside the brackets blank on purpose, just as a FOO-style placeholder to suggest else {some other action} ?

Or is it meant to be empty in the actual code? If the latter, then a follow-up question: what does the program do, if it has an in-brackets command, like else{}, where the part within the brackets is blank? Question out of genuine curiosity.

By Admin:

I’ve moved posts above this into a new topic as they were not directly related to the topic where originally posted.

Note to all: a polite request to please not add to existing threads unless discussing the same topic as that is confusing for other readers. Engaged forum members will browse all new posts/topics so there’s no upside to tagging onto an existing topic as opposed to starting a new one.

I think I see the problem here. As above both $Latitude and $Longitude get the Latitude value. If you reverse the oder of the two if() statements, both attributes get the Longitude value. IOW, back-references ($1, $2, etc.) aren’t reset after the first if() clause.

I think this is design oversight that arises because originally, back-references were available in agent queries and used by agent actions. An agent only has one query. Subsequently, back-references were made accessible from the conditional test (which is a form of query) in if() statements. What appears to have been overlooked is allowing for multiple queries within a single rule/edict/etc. and thus the need to flush the back references after the expression is evaluated i.e. the code in the {} sections of the if(){}else{} code.

Side-note: I assume the empty else {} code branches are a misunderstanding. They aren’t needed (at least as shown) but do no harm if included.

1 Like

If the second statement’s action were

$Longitude=$2

I believe all would be well.

$2 returns zero, using the same test file as previously.

This worked for me. Happy to take a look at a test file.

My test TBX emailed.

(after further discussion off-list with Eastgate)

For now, set your second if*() clause action to use $3 instead of $1. If you had a third such if() clause you’d use $5 instead of $1, etc. As Tinderbox can give references $0-$9, you could thus accommodate 5 such clauses, assuming each only created one back-reference.

I’m not sure if this is the intended behaviour but works for now (v7.3.1).

To explain a little more:

The first .contains stores the entire matching expression in $0, and the matched back reference in $1, as usual.

The second .contains then stores it’s full matching expression in the next slot, $2, and its back reference in $3.

This scheme is not intuitive, to be sure. It does, however, support multiple pattern matches in an expression:

 if($Name.contains(..something..) | $Text.contains(..something else..))

We’re exploring alternatives. As a general hint, though, I find that when rules or actions become elaborate, that’s often a sign that they want to become several rules, or perhaps several agents.

@mwra Thanks for moving this over to a new topic, Mark. I’m slowly learning how this forum thing works now. I’ll do my best to abide by the established norms and customs.

1 Like

@eastgate & @mwra, thanks for your help guys. It works! Cheers.

1 Like