adjacent objects

[Richmond]

On 06/12/15 20:44, Walt Brown wrote:
> Richmond,
>   I was trying to recreate "Boids" (but got distracted playing with the
> muckingabout stack at the same time, more on that later :-).
>
> I had each object post their position to a global list of objects when they
> stopped moving (or when a new recalculation cycle is declared). Then each
> object had it's own script to look at that list during next-move planning
> and determine nearest neighbors. I compared the shortcut of just averaging
> the XYZ differences but found getting the actual XYZ distance (the root of
> the sum of the squares) took close to the same time for the number of
> objects I was estimating. I used layer difference (multiplied by a suitable
> factor to get in the same scale as the screen XY) as the Z distance to
> emulate 3D. I created a parameter called MinDistance, and if the distance
> was less than that, declared a collision (In boids, MinDistance is
> variable, depending on if the collision was inter or intra species or
> static objects). Each object then incorporated that fact in it's next plan
> - typically going in a vector somewhat opposite of the collision point,
> after disassembling the 3D diagonal vector into XY screen coordinates and
> speed, and a Z emulation using layer changes.
>
> If you wanted orthogonal adjacency (as in the muckingabout stack), you
> could compare the position difference against the objects' sizes on each
> axis. If they are equal, the objects are adjacent. Adjacency would have XY
> differences of either 0,object height or object width,0.
>
> Or you could fill a global XY array (ie a set of lines of lists, which is
> what I am adding to muckingabout) which stores what (ie a tile) is at each
> location (square) in the grid (along with rotational data) and each object
> can query and update that list. In muckingabout, I am thinking of naming
> each square their XY location, so a tile can query specific squares without
> loops.
> Walter
>
Sounds good.

Although now I am storing the characteristics of sides in 4 custom 
properties (e.g. TOP, BOT, LEFT, RIGHT)
there is no need to store their rotation at all: you can pop the value 
of those custom props into places in your
array.

If we imagine a chessboard . . .

And each row of the chessboard stores the properties of each tile in 
each 'square': loc1, loc2, TOP, BOT, LEFT, RIGHT,
2 further spaces for other things that may crop up . . .

Or, as I have felt extremely negative about arrays ever since wrestling 
with one during an end-of-year PASCAL project
(to make a concordance of the English translation of Leibniz's 
/Monadologie/), one could store "all that"
as a set of comma delimited values in a multi-line field . . .

. . . at which point all sorts of heavy types will jump out of the 
LiveCode bushes to pummel me into pulp for
(among other things . . .) using fields when one can use variables, 
arrays and other less concrete things.

The tiles can have screamingly original names such as "t1", "t2" and so 
on, and their sets of properties that we
need to know

[ location of tile, side characteristics, and so on ]

can be stored in lines corresponding with the numeric parts of their names.

Then, I would jalouse, as soon as one drops a tile 2 things can happen:

the "where" and the "how" of the tile when it is dropped can be written 
to its line in the props field,

and, should it have been dropped on a drop-target,

the "where" and the "how" of all the other tiles can be accessed to see 
if they are 'kissing' our tile.

The drop-targets (consisting of square graphic objects) should have a 
custom property ("OC" = occupied) that
should, initially be set to 0 (zero) and set to 1 when a tile is dropped 
on it, therefore giving us a way to stop
the end-user dropping a tile on a drop-target that is already taken by 
another tile.

Of course, the main criticism about my idea of using a field to store 
prop details is that looking up info in it
will be significantly slower than using an array.

As the base game of Carcassonne uses 72 tiles this may involve quite a hit.

Best, Richmond.

  On Sun, Dec 6, 2015 at 10:12 AM, Richmond 
<richmondmathewson at gmail.com> wrote:
>> I am aware that objects/controls are on different layers on a LiveCode
>> card,
>> but the end-users looking at a 2-dimensional screen they are all,
>> apparently,
>> on a flat surface.
>>
>> Has anyone any idea how a script within the mouseUp of one control could
>> detect the presence of "adjacent" controls on the same card, and,
>> subsequently,
>> read properties from those adjacent controls?
>>
>> This would seem to be mission-critical for games.
>>
>> The 'problem' is that adjacent controls cannot be detected by INTERSECT
>> because they don't . . . intersect.
>>
>> Richmond.
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode