type stuff

Blitz3D Forums/Blitz3D Programming/type stuff

Ruz(Posted 2004) [#1]
problem with types is I have set my player type to global so i can reference it anywhere.
so now I can call it 'p\model' in my update player function
rather than 'player1\model'

the problem is that if I try to refer to it as p\model in my 'update enemy' function its returns as 'entity must be a type'.

conversely if i try and refer to my enemy as 'e\model', in the 'update player' function the same thing happens
ie 'entity must be a type'.
syntax wise 'p\model' and 'e\model' work fine inside their own update functions, but not when referencing each other for some reason

Bsically I am trying to copy the enemy1\model to make a generic level enemy and have them all with the same behavior/triggers.


TartanTangerine (was Indiepath)(Posted 2004) [#2]
Are you declaring p or e as Global Variables??

ie.

Global p.MyType = New MyType


Ruz(Posted 2004) [#3]
I am declaring the new type as a global
ie
global Player1.Player=CreatePlayer( -20,0,0 )
global Player2.Player=CreatePlayer( -20,0,0 )
etc
global enemy1.enemy=CreateEnemy( -20,0,0 )
global enemy2.enemy=CreateEnemy( -20,0,0 )
etc
this is the create player function

Function CreatePlayer.Player( x#,y#,z# )
p.Player=New Player
p\entity=CreatePivot()
p\model=CopyEntity( player_model,p\entity )
p\player_y=y
PositionEntity p\entity,x,y,z
EntityType p\entity,TYPE_PLAYER
EntityRadius p\entity,1.7
ResetEntity p\entity
Return p
End Function


Floyd(Posted 2004) [#4]
That looks like it should work, but there is no way to be sure.

We need to see some code we can actually run and observe the error.


Difference(Posted 2004) [#5]
Your globals are named Player1, Player2, enemy1, enemy2 not p and e. Isn't that the problem?


Ruz(Posted 2004) [#6]
ahh, my code is pretty big and messy.I wil have another look, see if I missed anything simple

perhaps
p.Player=New Player
should be global but its inside a function ?


Techlord(Posted 2004) [#7]
Ruz,

If I can offer a word of caution with using globals. Please be sure that you don't rely on them within your functions. I ran into several hard to find bugs in which functions were overwritting data of globals.

I would recommend using a Array of types for your situation.
Dim player.player(24)
Dim enemy.enemy(24)



ChrML(Posted 2004) [#8]
Sure the e and a identifiers are not already used? As a variable perhaps...


Ruz(Posted 2004) [#9]
'Your globals are named Player1, Player2, enemy1, enemy2 not p and e. Isn't that the problem? '

How do I make p and e global if they are inside a function though?



I wil check ChrML

Frank,what else can i do in this case?
I need to refer to 'e/model' not just 'enemy1\model' so each enemy does the same stuff, not just enemy1


Techlord(Posted 2004) [#10]
Ruz,

If all your enemies use the same functions etc then you only need access them with one variable. I use a For..Each loop to update. If the states are different, then you should throw a select case in the update to select different actions. My approach would be:
Function playerUpdate()
	For this.player=Each player
		Select this\state%
			Case 1 playerAttack(this)
			Case 2 playerRun(this)
		End Select
	Next
End Function
My approach is based of the typical Particle system framework, in which you create, update, and destroy a particles. This approach could be applied to all game objects IMHO. Hence, create, update, and destroy a enemies, bullets, etc.


ChrML(Posted 2004) [#11]
Or if you want to "seperate" them somehow, then assign them ID's:

tmp.Player = new Player
tmp.Player\id% = 1

tmp.Player = new Player
tmp.Player\id% = 2


For tmp.Player = Each Player
  if tmp.Player\id = 1 then
    ;action for player 1
  elseif tmp.Player\id = 2 then
    ;action for player 2
  endif
Next



poopla(Posted 2004) [#12]
hmm... I hope by destroy you mean recycle(Store for later use in a sorted list), and use at a later time. Actually destroying much of anything is a big waste. When it will undoubtedly be used again in most situations.


Techlord(Posted 2004) [#13]
ShatteredReality,

I mean destroy as in remove it from update.

If your using different kinds of enemies but they use a common set of properties then you can add a property like
enemy\kind% or enemy\typeid%
to differentiate between them. I would keep the
enemy\id%
independent as you may need to track a certain number of a specific kind enemy.

Function enemyUpdate()
	For this.enemy=Each enemy
		Select this\typeid%
			Case 1 ;enemyBoss
				;do stuff
			Case 2 ;enemyMidBoss
				;do stuff
			Case 3 ;enemyHinchman
				;do stuff
		End Select
	Next
End Function



Ruz(Posted 2004) [#14]
he I was just going to come and ask if I could use
'For this.enemy=Each enemy' type of thing, then you all answered for me
hmm select case confuses me a little . i get the principle , but then it confuses me whe applying it to my code.

I just have one attack right now which is a punch and one enemy grunt type, all grunts will have all the same properties( for now)

is it best to make a one generic type for enemy or if you have say a buttefly/badger/human etc would I make a seperate type for each one or just lump them all as 'enemy'
but have lots of properties/fields in that one type

I will go and try and make it work now.
thanks for the help so far guys
the id stuff seems very helpful.


Ruz(Posted 2004) [#15]
well i ended up doing it this way. i didn't really see the need to do it more complex way here. i realised that i want to have access to each new enemy so i can adjust properties like health/damage etc
I just got confused on how to turn this in to select case
or one the other methods mentioned.

For e.enemy=Each enemy
UpdateEnemy(e)
and
For p.Player=Each Player
UpdateEnemy(p)

are called in the main loop BTW

This is the attack from the update player function
BTW I used animtime to make the player punch at the correct time, ie after he has swung his fist, not before

;player attack #####################################################################


If KeyDown(157)
If AnimSeq(p\model)<>1

If AnimSeq(p\model)<>8

Animate p\model,3,.24,8,3;bigslap

EndIf
idleflag=0

;enemy 1************************************
If EntityDistance(enemy1\model,p\model)<6

If AnimTime (p\model)>=4
If AnimTime (p\model)<=4.2

MoveEntity enemy1\model,0,.3,-3;punch knocks enemy back

PlaySound(hit)

enemy1\health =+enemy1\health-10

EndIf
EndIf
EndIf
EndIf

;enemy2**********************************

If EntityDistance(enemy2\model,p\model)<5

If AnimTime (p\model)>=4
If AnimTime (p\model)<=4.2

MoveEntity enemy2\model,0,.3,-2

PlaySound(ouch)

enemy2\health =+enemy2\health-10

EndIf
EndIf
EndIf
EndIf

If I have 30 enemies though, thats a lot of tying/ repeating the same stuff


Stevie G(Posted 2004) [#16]
I'm with Frank and ChrML on this one. Use a type field of "enemy_type" - much cleaner and easier to understand in the long run if you have loads of enemies.


Function update_player(p.player)

for c.enemy = each enemy

select c\enemy_type

case 1 ;enemy 1

If EntityDistance(c\model,p\model)<6 and AnimTime (p\model)>=4 and AnimTime (p\model)<=4.2
MoveEntity c\model,0,.3,-3;punch knocks enemy back
PlaySound(hit)
c\health = c\health-10
EndIf

case 2 ; enemy 2

If EntityDistance(c\model,p\model)<5 and AnimTime (p\model)>=4 and AnimTime (p\model)<=4.2
MoveEntity c\model,0,.3,-2
PlaySound(ouch)
c\health = c\health-10
endif

case 3 ; enemy 3 etc....

end select

next

end function


Ruz(Posted 2004) [#17]
thanks stevieG and everyone . i agree that using stuff like frank and ChrML were using is better/more organised, its just I confused myself with the syntax and stuff when applying it to my code. never used case select before, dohh

But it works great now, I have three enemies in the level which is so much more fun than one.
I am going do some health packs now
woot !!