i used structs to create a "QUATERNION" type which can be passed to quaternion functions that i wrote. it's much easier than handling var array's, and much more intuitive to work with (if you know what you're doing with quaternions, my_quat.w/x/y/x makes much more sense than my_quat[0/1/2/3]).
i also used structs to create a "PHYS_ENT" type. these contained a pointer to an entity; two quaternions (containing orientation and angular velocity); a velocity vector; floats for mass, elasticity, coefficient of friction, moment of inertia; and lastly a PHYS_ENT pointer called "next_phys".
this helped in making my own custom physics engine. the pointer to "next_phys" allowed me to use linked lists to keep track of which PHYS_ENT's were enabled and which were disabled. it also meant i could create force-applying functions (and similar) that only need to be passed a force, position, and pointer to a PHYS_ENT, and then the function knows how to use and change each of the parameters within the PHYS_ENT struct.
additionally, every object in lite-C -- ENTITY, VIEW, PANEL, MATERIAL, PARTICLE, VECTOR, ANGLE etc -- is a struct. ENTITY contains things like var skill[100], ANGLE pan, VECTOR x, and all those other things that belong to an entity. if you need other stuff, create a struct. i created PHYS_ENT because you can't access local variables (or local structs) from one action in another, so i gave PHYS_ENT everything extra that other PHYS_ENTs would need access to.
linked lists are very useful. they are a bit like arrays except they can change in length, and new members can be stuck in anywhere without affecting others.
for example, i had a PHYS_ENT called phys_enabled, and another called phys_disabled. i also had an array of 128 global "phys_ent"s. at game start, phys_disabled's pointer "next_phys" was pointed to the "phys_ent[0]". a loop made each phys_ent point to the next one (don't confuse phys_ent, the array, with PHYS_ENT, the type of the array). any PHYS_ENT in the "phys_disabled" list could be found by checking a PHYS_ENT's next_phys, and then checking their next_phys, and so on and so forth.
i had a function that gets called to enable a physics entity, and that would do so by just grabbing the first PHYS_ENT in the phys_disabled list (after the actual "phys_disabled" PHYS_ENT, of course), pointing it to the ENTITY i wanted to enable and putting it in the phys_enabled list. a separate function which ran 60 times a second would cycle through every PHYS_ENT in the phys_enabled list and allow them to move, react to collisions, etc.
more info on linked lists can be found in this example:
http://www.coniserver.net/ubbthreads/sho...4550db041639079i hope this is helpful,
julz
