collisionSegments colliding

Scripting Issues
21

Ah, fair enough, and my mistake - it was silly of me to not think of that, I feel. ^^;

It should be fairly simple: First, let’s find out how far the code is getting by putting simply “print” statements at various points in the code. Second, once we do get to the active code, let’s see what results, if any, we are getting by printing those results.

Perhaps try something like this:

(Notes:

  • I’ll place “print” statements in both of the below functions since we don’t know, if I recall correctly, which, if any, might be being executed.
  • When I print values, note the use of “str()” to convert objects to strings; while not generally called for in print statements that only print objects, it is called for when concatenating with strings, I believe.)
def pick(self,handler):
   print "Picking..."
   if(handler.getNumEntries()>0):
      print "Picking: We have entries."
      handler.sortEntries()
      print "Picking: Results: " + str(handler.getEntries())
      picked=handler.getEntry(0).getIntoNodePath()
      picked=picked.findNetTag('collisiontag')
      if not (picked.isEmpty()):
         print "Picking: The picked node is not empty, and is: " + str(picked)
         self.interact(picked)

def combat(self,handler):
   print "Combat..."
   if(handler.getNumEntries()>0):
      print "Combat: We have entries"
      handler.sortEntries()
      print "Combat: Results: " + str(handler.getEntries())
      picked=handler.getEntry(0).getIntoNodePath()
      picked=picked.findNetTag('instance')
      type=picked.getTag('type')
      if not (picked.isEmpty()):
         print "Combat: The picked node is not empty, and is: " + str(picked)
         self.damage(picked,type)

(If you’ve changed the above methods since your second post in this thread (I think that it was), then the above may want for modification.)
[/quote]

22

https://www.dropbox.com/s/6r0e1lrpnliz4ff/printouts.png

those are the printed results.
if i read them well, the enemy DOES get picked, so the problem must be elsewhere.

23

got it,

the damage code was posted here somewhere.
i added some more printouts and found out that the if(type==1) is never true, somehow. allthough type is definately 1, according to the printouts…

24 
def damage(self,object,type):
	global xp
	print "damage: The object is: " + str(object)
	print "damage: The type is: " + str(type)
	if(type==1):
	  print "ready to destroy"
	  object.destroy()
	  xp+=50  
	  xpcounter.setText(str(xp))
	print "done"

returns the following:

25

woo!
it turn out it shouldn’t be type==1, but type==‘1’.
but now the error is that destroy is an invalid call for a nodepath.

26

detaching the node however wont suffice…
how do i delete it?

27

well, they dont seem to overwrite, i have multiple ones standing around. and only 1 disappears (now that the code works) the Tag system works fine for now. maybe the list thing is a good optimization for later.

28

First of all, well done on having fixed it so far! :slight_smile:

Now, a few things:

  • I just noticed that you use brackets in your “if” statement; while not technically incorrect, Python doesn’t require it and you can potentially cause problems for yourself if you at some point end up including a comma within the brackets, either accidentally or otherwise. In Python, control statements (“if”, “while”, etc.) don’t require brackets, as I recall.

  • While your enemies don’t overwrite each other in terms of objects, I imagine that at some point you’ll want to get access to more than the last-created enemy, even if only for cleaning them up on shut-down. I second the recommendation of keeping a list of enemies rather than a reference to the last-created.

  • Since your tags turn out to be strings anyway, I’d like to suggest giving the enemies descriptive types rather than numeric; you can then perform checks along the lines of “if type == ‘kitten’”, which could make debugging and later development easier.

  • Finally, as to destruction, NodePaths are removed by a call to “removeNode” (like so: myNodePath.removeNode()), if I recall correctly.

29

okay, as i said, the list thing is something i had allready planned for later.

renaming the tags to match the actual type was something i did that caused me to find the problem.

and i use the brackets by the if for my own clarity.
i always have done so on other languages too, so.

30

Fair enough, on all counts.

On the matter of the brackets, the problem is that Python uses brackets to specify a tuple; if you end up at some stage with a comma within them, erroneous or intended, you may end up with a bug that may not be obvious to spot. However, if you accept that risk and still prefer to use them, then I’ll not object further on the matter, I believe. :slight_smile:

(I came from C++ and Java myself, as I recall, so I don’t say the above as someone who started out on Python, please note.)

31

Python uses brackets to declare a list, not a tuple. Parentheses are used to declare a tuple.

32

[edit] In short, since the below seems to have ended up longer than perhaps called for ( ^^; ):

It looks as though the differing uses of the word “brackets” is a conflict between American and British English; I use “brackets” to denote any form of such marks (such as ‘(’, ‘{’, ‘[’, ‘<’, etc.), and without additional qualification generally mean “round brackets” (much as “click”, without additional qualification, is presumably to be taken as “left click”).

[/edit]

I think that we have a semantic conflict; I meant the word “brackets” to mean the symbols ‘(’ and ‘)’, I believe. (I would call the others “square brackets”.)

Having looked at Dictionary.com, it does appear that I might be mistaken in that usage - although it does indicate that in mathematics the word can refer to various forms of parentheses, so I might have picked up the habit there.

On the other hand, my old pocket Oxford dictionary supports my usage, giving that the word “brackets” can refer to a number of forms, and gives, I believe, each of ‘(’, ‘{’ and ‘[’ as examples.

Finally, according to Wikipedia: “Used unqualified, brackets refer to different types of brackets in different parts of the world and in different contexts”, and later goes on to note that “In American usage, parentheses are usually considered separate from other brackets, and calling them “brackets” at all is unusual …”.

(For reference, the version of English that I speak and write is closer to British English than American, I believe, which may be the source of our confusion.)

That said, given this ambiguity, perhaps a less ambiguous term, either “parentheses” or “round brackets” might be better, and either way thank you for the clarification! :slight_smile:

33

I had similar problems in the past in my game. You can only set string values using

node.setTag()

That’s why in a lot of places I have type-conversions. The ID of a ship is an int of course, so setting the ID on a node:

self.cnode.setTag("shipid", str(self.id))

Reading the info in the collision handler:

for i in range(self.colls_handler.getNumEntries()):
	entry = self.colls_handler.getEntry(i)
	fromnode = entry.getFromNodePath()
	fromshipid = int(fromnode.getTag("sourceid"))
	intonode = entry.getIntoNodePath()
	intoshipid = int(intonode.getTag("shipid"))

In my game I also have weapons that are a damaging wave, hitting multiple targets through their lifetime.

Upon creation, the collision node of the wave receives all kinds of values: The ID of the ship that fired the wave and an empty set that will receive the IDs of the ships that it has hit:

shot_cnode.setTag("weapname", weapname)
shot_cnode.setTag("sourceid", str(sourceid))
shot_cnode.setPythonTag("hashit", set([]))

When that wave hits an enemy, that enemy’s ID is added to the wave:

if intoshipid not in fromnode.getPythonTag("hashit"):
					fromnode.getPythonTag("hashit").add(intoshipid)

To do that one has to use getPythonTag, which is a Python function, not getTag, which is provided by Panda3D.