there are no Maximum setups for Types ... however i would not recommend using more than 32 per type as it does become a little hard to understand all the subtypes, especially if you have several objects lower than that.
you should never exceed 256 data types within a type, because else it'll become a double-byte type - and Pro DOES NOT LIKE THEM at all.
Setting up types is a relatively simple task however, remember that all your doing is making an encapsulated object for use as a custom data type.
First you setup a simple type ->
type pos
x as float
y as float
z as float
endtype
now this type will be used as a position object.
now we can declare this to an object like so ->
and this will mean that now on you're 'player' you now have the position object giving you
'player.x', 'player.y', 'player.z'
however what if we don't ONLY want this for the player, and we also don't just want the position.
let say we want to make a new type which will cover health, sheild, weapon and ammunition.
well we'll create a second type like so
type items
health as float
sheild as float
weapon as armoury
endtype
did you notice how we've put 'armoury' as a data type... this is because the weapon data itself should be a subtype allowing us to understand that it is a weapon rather than part of the main type.
now we make this extra type
type armoury
active_1 as boolean
ammo_2 as word
active_2 as boolean
ammo_3 as word
active_3 as boolean
ammo_4 as word
active_5 as boolean
ammo_5 as word
active_0 as boolean
endtype
notice how they've not been named but given 6 either yes or no slots ... and each have ammo except for 0.
well we can assume that 0 will actually be the default weapon requiring no ammunition - now that will also be used by the enemy, because you don't want them running out of ammunition or altering weapon.
However if you wanted you could have them run to the same rules as the player.
now its time to declare these
type pObject
obj as word
pos as pos
itm as item
endtype
player as pObject
dim enemy(255) as pObject
what we've done here is created the final type required, which for arguments sake will be called a 'Class Type' because it combines ALL of the 'Data Types' into a nice neat package.
we can access and fill the player data with these new objects ->
'player.obj' // player object number (0-65535)
'player.pos.x', 'player.pos.y', 'player.pos.z' // players position
'player.itm.health' // players health
'player.itm.sheild' // players sheild
'player.itm.weapon.active_1' // weapon 1 (active)
'player.itm.weapon.ammo_1' // corrisponding ammunition
etc...
now its a similar setup for the monsters, only you have an array for them ->
'enemy(0).pos.x', 'enemy(0).pos.y', 'enemy(0).pos.z' // enemy position
--||--
now a note to the team it would be nice if we could rather than armoury being setup the way it is... just have
type armoury
active as boolean
ammo as word
endtype
dim armoury(9) as armoury
type items
health as float
sheild as float
weapon as armoury[]
endtype
ofcourse using the [] instead of the usual () to make sure it is recognised as an array rather than a function. Personally I think that arrays should be renamed in this fashion anyways because it does cause some confusion sometimes, especially with functions having same or similar names.
--||--
well i'll leave you now to type that all up and figure out what order it should be in ... remember you don't have to keep 'data types' to just the 'class types' because you can declare them freely on thier own.
you make want to use the 'pos' object for particle generation later
have fun and be creative because types are more versitile for keeping your programming ticking along nicely whilst neatening up the entire overall code.
and I would recommend learning howto use them well now because it is likely we'll see Array and Function encapsulation due to sheer demand
Anata aru kowagaru no watashi! 
