Python - lists as object properties (and the weird behaviour thereof)

OK, so normally when you want to set up a property as a multidimensional list in Python, you do something like this:

list = [[1,2,3],[4,5,6]]

and usually this all works out OK and everybody’s happy. However, when you want to store this as a property of an object in the GE, what you seem to end up with is this:

[[4,5,6][4,5,6]]

i.e. the last entry in the base list repeated. Note also the lack of a comma between the two sub-lists. Very weird. You can still call objects from the list OK, but when you try to store something to a specific index, i.e:

object.list[1] = thing

it doesn’t work, and I get a message in the debugger: “TypeError: ‘CListValue’ object does not support item assignment.”

This all makes me a sad panda. Does anybody know what’s going on here? Is there a good reason behind this and I’m just being an idiot or is this as weird as I think it is? More importantly, is there a way round it; can I force blender to store multidimensional lists as object properties properly? It’s pretty important for what I’m trying to do.

Yea, I can confirm this behavior.

I don’t think the “game object” was ever designed to properly handle anything other than the property types which can be added via that “ADD PROPERTY” button. So it’s bool, int, float, string, and that special timer type.

For everything else, it looks like you gotta make it global in order to modify properly later on: “GameLogic.mylist = []”

Aside from editing the BGE source, probably not.

Heh, I’m assuming that the objects in question here are being added with an add object actuator, in which case I can see why you can’t simply use global lists. Although, you could write a system that makes relationships between newly added objects and some set of global data structures, but it would all be very “hacky”.

Can you describe what you’re trying to do here in more detail? There could be a better/simpler way of doing what you want.

Theres always a better, simpler way.
do this instead:

list=[[1,2,3],[4,5,6]]
ob.list=str(list)

and when you want to access it do:

list=eval(ob.list)

i had the exact same problem when i was working on an alternative to using Gamelogic “global” variables. This workaround works fine

Ahh, I forgot about eval().

Nice.

Hey, now that eval() solution is clever. I’ve always handled this problem the way Social originally suggested (with global variables), but it would be nicer to keep the lists with their respective objects.

Thanks, guys. Useful stuff.

eval() function is useful but is probably slower (if you are calling your script every frame) than just using a global variable.

Thanks, guys. I’m at work at the moment so I’ll have to make this brief; but essentially what I’m working on is a turn-based game where the data for each ‘piece’ is stored in a single array (i.e. coordinates, orientation data, whose side it’s on etc) which is used to set the positions etc. of the objects which represent them visually in the game engine when a ‘refresh’ script is run. Since it’s all stored in one ‘gamedata’ empty, though, there’s no reason why I can’t use a global variable (I just assumed that I’d have the same problem).

I’m using a lot of lists for various things, though, so that eval() method will probably come in handy as well.

To prevent further suffering for the coming generations, though, does anybody know of a dev who might be interested in fixing the problem? It doesn’t strike me as something that would be too hard to sort out.

My thoughts exactly.

Actually, I think that’s probably the reason why I didn’t even consider using eval(); The whole “convert to string and back” process seems gluttonous. Also, I don’t think you can use the same method for things that don’t break down into regular expressions. I mean, assuming that I have a class “Foo”, I can’t do “foo = Foo(); gameObj.foo = str(foo)”, and then use the same eval() trick.

Can’t say that I do, but someone else might.

I guess you could try the bugtracker, because this is technically a bug in one way or another. That is: Either you’re allowed to declare data structures on game objects, and you should be able to modify them properly, or you’re not, in which case you should not be able to declare them on a game object in the first place.

Heh, seeing as how we don’t really have a dedicated development team, and your request is unrelated to GLSL, I say the chances of it being “picked up” and resolved are somewhere around 16%. :slight_smile:

*Rolls dice.

i found the bug, one _setattr method is missing, i will try to correct it now

by the way, setting python objects works for scene objects (i’m analyzing the differences between them)