|
|
 %object2% reference with no %object1% fails "exists" restriction
| Issue Type: |
Status: |
Priority: |
Date Submitted: |
Votes: |
| Bug |
Completed |
Critical |
Mon 4th Aug 2014 |
1 vote
 |
| |
| Found in version: |
Last Updated: |
Completed in version: |
Date Completed: |
Track Changes: |
| 5.0.31.4 |
Fri 28th Nov 2014 |
5.0.33 |
Fri 28th Nov 2014 |
Log In |
| |
| saabie | | Mon 4th Aug 2014 10:16 |
If you write a task with an %object2% reference but no %object1% reference (which I did to try and find a workaround for bug #18924) then it fails the Referenced Object 2 must exist restriction, even though other debug output shows it as a blue pen.
Debugger messages:
Task 'Write text on assumed object' matches input.
Referenced Object 2 must exist: Failed
Referenced Object 2 must exist: Failed
Task doesn't pass restrictions, but is current highest priority failing task with restriction output.
Attempting to execute task Write text on assumed object...
Checking double reference task write hyjygy [with/using] a blue pen
Referenced Object 2 must exist: Failed
Failed Restrictions
First Reference: (no output)
Second Reference: a blue pen(no output)
|
| |
| Campbell | | Thu 28th Aug 2014 21:51 |
| Note to self, will need to store matching reference (%object2%) within clsNewReference structure. |
| |
| saabie | | Thu 27th Nov 2014 08:08 |
This is actually more serious than I though.
If you have a task with references then they MUST be written in the order %object1% %object2% %object3% or else ADRIFT will store them incorrectly.
In fact, no matter what order you write the references in the command line, ADRIFT will store them in numbered order, completely ignoring what you wrote.
So if you write the references: %object3% %object4% %object2%, the object keys get stored in %object1% %object2% %object3% instead.
Even more seriously, if you need a task like:
fill %object2% with %objects%
and the player types:
fill the drum with the water and the oil
Then what you get is:
%object2% = the water and the oil
%objects% = the drum
Changing the order of references for different commands in the same task like:
remove %objects%{,} %Character%
%Character%{,} remove %objects%
can also end up scrambled, especially if you try to pass references to a called task.
|
| |
| Campbell | | Fri 28th Nov 2014 01:28 |
| This should be fixed now. |
|
