(this is mostly for Ama)
I noticed in your initial release notes that you're using your "standard" style of index/search parameters, and wondered if you had any plans or interest in implementing the new object query methods that were introduced to Innerspace a few versions ago.
I poked around at ISXDK 3.0, and while Lax's documentation is a bit sparse at the moment, these don't seem hard at all to implement. This would give us a much more powerful search mechanism, while (it seems to me) making less work for you in the process, as you wouldn't have to write/maintain a new argument handler each time you add an indexed datatype.
(for those not familiar with object-query indexing, or for whom Lax's description is a bit opaque, it works something like this: With isxgames extensions, we're used to indexing an array like this -
Actor[radius, 10, name, David]
Under the hood, those index arguments are passed and handled much like the arguments to a command. We as users have to make sure that the index we're using is supported, and that we're passing all of the commands in the right order. If somebody requests that we be able to say search for the nearest corpse, Ama would have to add code to parse for the new "corpse" argument, as well as a few lines to actually do the work of checking each actor to see if it's a corpse. With object queries, instead of a fixed list of search parameters, we can pass in an expression, a "mini-function" if you will, that gets evaluated at run-time. Something along the lines of -
Actor[Radius <= 10 && Name=="David" && (Type=="Corpse" || Type=="Pet")]
where we can build our queries out of any members within the datatype. In the example above, if we later decide that we want to further limit our search to only actors outside of a radius of 5, all we have to do is add && Radius > 5 to our query.)
I noticed in your initial release notes that you're using your "standard" style of index/search parameters, and wondered if you had any plans or interest in implementing the new object query methods that were introduced to Innerspace a few versions ago.
Code:
1.09 Build 4419
* Object query support has been added. Extensions can use ISXDK 30a (or later) for direct
access to this functionality. An object query is a math formula where all variables
are relative to a specific object, and results in a boolean value -- the query is either
true, or it is false. Query math can compare and manipulate text, decimals, or integers
(note that bool counts as an integer for this purpose) with standard math operators. Text
comparisons are not case sensitive. One intended use for object queries is a uniform search
mechanism, to find an object or set of objects from a larger set of objects (compare to a
SQL SELECT statement, where a LavishScript object query is the WHERE clause).(for those not familiar with object-query indexing, or for whom Lax's description is a bit opaque, it works something like this: With isxgames extensions, we're used to indexing an array like this -
Actor[radius, 10, name, David]
Under the hood, those index arguments are passed and handled much like the arguments to a command. We as users have to make sure that the index we're using is supported, and that we're passing all of the commands in the right order. If somebody requests that we be able to say search for the nearest corpse, Ama would have to add code to parse for the new "corpse" argument, as well as a few lines to actually do the work of checking each actor to see if it's a corpse. With object queries, instead of a fixed list of search parameters, we can pass in an expression, a "mini-function" if you will, that gets evaluated at run-time. Something along the lines of -
Actor[Radius <= 10 && Name=="David" && (Type=="Corpse" || Type=="Pet")]
where we can build our queries out of any members within the datatype. In the example above, if we later decide that we want to further limit our search to only actors outside of a radius of 5, all we have to do is add && Radius > 5 to our query.)
Most of our use of the Custom* TLO objects is to do just this type of pruning, so if you *were* to backport this into ISXEQ2, you could probably just create QueryActor and QueryInventory, leave the old stuff intact, and call it a day. (Alternatively, I suppose you could train your existing handler(s) to check the first argument for a leading & or somesuch to indicate a query). I haven't felt out the VG community, but I'm sure it would find more favor there where there's some active bot developers. (Killing time waiting for the game to die off the rest of the way, no doubt. Oh the irony.)