Expose connected logic bricks from python #29679

New Issue

Francesco Zoffoli · 2011-12-23T01:22:19+01:00

Francesco Zoffoli commented

2011-12-23 01:22:19 +01:00

%%%Hi,

this few lines patch exposes the list of sensors' connected controllers and controllers' connected actuators.
At first i called both properties .links, but to make it more clear that controllers- [x].links returns only actuators, i called them linked_controllers and linked_actuators

Why this patch should be added?
Well, i needed this informations in order to finish my python script that allow to share logic setups. With it you'll just need to press a button and you'll have all your setup saved in a file, so that it is easy to reuse (the script saves and loads the files) and share. If you visit the blenderartists' game forum, you'll see that a lot of requests are made about how to configure the setup. With this patch and the script the problem will be solved!%%%

%%%Hi, this few lines patch exposes the list of sensors' connected controllers and controllers' connected actuators. At first i called both properties .links, but to make it more clear that controllers- [x].links returns only actuators, i called them linked_controllers and linked_actuators Why this patch should be added? Well, i needed this informations in order to finish my python script that allow to share logic setups. With it you'll just need to press a button and you'll have all your setup saved in a file, so that it is easy to reuse (the script saves and loads the files) and share. If you visit the blenderartists' game forum, you'll see that a lot of requests are made about how to configure the setup. With this patch and the script the problem will be solved!%%%

Francesco Zoffoli commented

2011-12-23 01:22:19 +01:00

Changed status to: 'Open'

Dalai Felinto commented

2011-12-23 04:52:05 +01:00

%%%Hi,

In don't understand why do you need linked_controllers, linked_actuators, but not linked_sensors for example.
Also, couldn't you do all from the controller? (linked_sensors, linked_actuators). This would mimic the behaviour and API from the game engine.
The patch has a fundamental error:

controller = MEM_callocN(sizeof(bController)* totlinks, "sensor_links");
actuators = MEM_callocN(sizeof(bActuator)* totlinks, "controller_links");
+controller = MEM_callocN(sizeof(bController ) totlinks, "sensor_links");
+actuators = MEM_callocN(sizeof(bActuator ) totlinks, "controller_links");

What means you didn't test the patch, right ;)
So, even with the above change what I'm getting is more a copy of the controllers/actuators then the object itself.
For example try to change the name of: bpy.game.sensors- [x].linked_controllers- [x] it doesn't change a thing.

small thing, but we tend to do post increment in blender unless needed otherwise:

for(counter = 0; counter < totlinks; ++counter)
+for(counter = 0; counter < totlinks; counter++)

%%%

%%%Hi, 1) In don't understand why do you need linked_controllers, linked_actuators, but not linked_sensors for example. 2) Also, couldn't you do all from the controller? (linked_sensors, linked_actuators). This would mimic the behaviour and API from the game engine. 3) The patch has a fundamental error: - controller = MEM_callocN(sizeof(bController)* totlinks, "sensor_links"); - actuators = MEM_callocN(sizeof(bActuator)* totlinks, "controller_links"); +controller = MEM_callocN(sizeof(bController *)* totlinks, "sensor_links"); +actuators = MEM_callocN(sizeof(bActuator *)* totlinks, "controller_links"); What means you didn't test the patch, right ;) So, even with the above change what I'm getting is more a copy of the controllers/actuators then the object itself. For example try to change the name of: bpy.game.sensors- [x].linked_controllers- [x] it doesn't change a thing. 4) small thing, but we tend to do post increment in blender unless needed otherwise: - for(counter = 0; counter < totlinks; ++counter) +for(counter = 0; counter < totlinks; counter++) %%%

Francesco Zoffoli commented

2011-12-23 12:52:37 +01:00

%%%1) Actuators don't store linked_controller, so the bidirectional linking was not possible(sensors<->controllers<->actuators). I thought it was more logical to follow the left to right pattern.

Definitely a good point. I'll redo the patch to work like this!
Actually i have a build that i used to see if it worked. Everything i needed was working, but i must admit i only used it to read data, and not to write. My fault!

  Yes, what you get is a copy of the data. I tried to use the array of pointers, but even if it compiled, i got wrong results. This is why the cast is to the struct and not to a pointer to the struct. I did this 1)because i didn't thought someone would use it to modify the logic brick 2)i didn't find somewhere an example about how to expose an array of pointers. So this was the solution i found. I'll look better to the RNA, so that i pass the pointer to the actual object instead of a copy.. Maybe defining all functions for _begin, _next, _end, _get..

4)no problem, i'll fix it.%%%

%%%1) Actuators don't store linked_controller, so the bidirectional linking was not possible(sensors<->controllers<->actuators). I thought it was more logical to follow the left to right pattern. 2) Definitely a good point. I'll redo the patch to work like this! 3) Actually i have a build that i used to see if it worked. Everything i needed was working, but i must admit i only used it to read data, and not to write. My fault! ``` Yes, what you get is a copy of the data. I tried to use the array of pointers, but even if it compiled, i got wrong results. This is why the cast is to the struct and not to a pointer to the struct. I did this 1)because i didn't thought someone would use it to modify the logic brick 2)i didn't find somewhere an example about how to expose an array of pointers. So this was the solution i found. I'll look better to the RNA, so that i pass the pointer to the actual object instead of a copy.. Maybe defining all functions for _begin, _next, _end, _get.. ``` 4)no problem, i'll fix it.%%%

Francesco Zoffoli commented

2011-12-23 15:20:32 +01:00

%%%Corrected how you suggested.

Now the controller has linked_sensors and linked_actuators. In addition it returns the real logic brick, not a copy(i tried changing the name from py console)

I still have some doubts about only accessing the links from the controller.. I think it is more natural thinking from sensor to actuator, but i'll wait for your opinion(keep things as they are now, or add the linked_controllers to sensors)

Btw both the solutions works for my script%%%

%%%Corrected how you suggested. Now the controller has linked_sensors and linked_actuators. In addition it returns the real logic brick, not a copy(i tried changing the name from py console) I still have some doubts about only accessing the links from the controller.. I think it is more natural thinking from sensor to actuator, but i'll wait for your opinion(keep things as they are now, or add the linked_controllers to sensors) Btw both the solutions works for my script%%%

Dalai Felinto commented

2012-01-11 09:15:22 +01:00

%%%1) is controller.linked_sensors working for you? I tested here and it seem not working (controller.linked_actuators works fine though)
2) it's better to name it controller.sensors and controllers.actuators
3) #include "MEM_guardedalloc.h" is no longer necessary
4) if you get controller.sensors working and actuator.controllers we could have them all exposed. Although I still feel that we need no more than controller.sens/act.

*) if controller.sensors is not doable we can consider the sensors.controllers and controllers.actuators only :/%%%

%%%1) is controller.linked_sensors working for you? I tested here and it seem not working (controller.linked_actuators works fine though) 2) it's better to name it controller.sensors and controllers.actuators 3) #include "MEM_guardedalloc.h" is no longer necessary 4) if you get controller.sensors working and actuator.controllers we could have them all exposed. Although I still feel that we need no more than controller.sens/act. *) if controller.sensors is not doable we can consider the sensors.controllers and controllers.actuators only :/%%%

Francesco Zoffoli commented

2012-01-12 00:17:16 +01:00

%%%1) you're right. I don't remember if i tested them, since it was the same 3 lines of code of actuators access, i just changed the the DNA field it points to. (more on this point later)
2)done
3)i receive warnings if i don't put it in. It says something like unknown external symbol, suppose it returns int.
4) more on this point now

Here the patch on which i'm working (note: it does not work)

I have no problems in sens->cont->act, but i'm facing really strange problems on the other way.

Let's talk first about cont->sensors(it is easier)
The code is the exactly the same of cont->actuators, i just changed to load the slinks instead oflinks and to return totslinks instead of totlinks, getting this informations from the DNA_controller_type.h (here it is commented that links refers to actuators and slinks to sensors)
Btw, while trying to get sensors from controller, it gives a list of length 0.
I run blender with the debugged attached, and i discovered that this happens because iter->valid is set to 0. Still, i don't know why this happens. I put a break both in actuator_begin and sensor_begin to see the difference, and i didn't see anything strange, except in both iter->ptr->data and ->type is 0x0000000, and the debugger can't evaluate the type informations. But it works.
While debuggin sensors_begin, it(MSVS) enlight a few fields as red (iter, ptr, iter->prop, iter->internal) and both iter->valid and iter->ptr->valid are set to 0. Forcing it to 1 raises an Access violation reading in rna_iterator_array_dereference_get trying to read 0x00000000.
But collection_prop informations are right, the lenght is correct, and the code is the same as actuators, so i don't really understand what's wrong...

About actuators-> controller
As you can see in the patch, i check for all the controllers the current object owns, and check if some of that controllers hods the current actuators. Obviously this is wrong since it doesn't find other object controllers connected to the actuator: it should get all the objects in the scene, and repeat the same process on each of them.
I don't know who to find the current scene from the actuator or the object, in addition is it correct to initialize the array of pointers in the _begin method? Will it be called again if after accessing it the first time, a new controller is linked?

To sum up:

sensors->conts-> actuators -- Already doable
sensors<-conts->actuators -- I think it is doable, just need to understand what is happening
sensors<->cont<-> actuators -- Hard, inefficient, and right now always crashes on BLI_countlist (i think i'm doing something wrong retrieving the ListBase..)%%%

%%%1) you're right. I don't remember if i tested them, since it was the same 3 lines of code of actuators access, i just changed the the DNA field it points to. (more on this point later) 2)done 3)i receive warnings if i don't put it in. It says something like unknown external symbol, suppose it returns int. 4) more on this point now Here the patch on which i'm working (note: it does not work) I have no problems in sens->cont->act, but i'm facing really strange problems on the other way. Let's talk first about cont->sensors(it is easier) The code is the exactly the same of cont->actuators, i just changed to load the **slinks instead of**links and to return totslinks instead of totlinks, getting this informations from the DNA_controller_type.h (here it is commented that links refers to actuators and slinks to sensors) Btw, while trying to get sensors from controller, it gives a list of length 0. I run blender with the debugged attached, and i discovered that this happens because iter->valid is set to 0. Still, i don't know why this happens. I put a break both in actuator_begin and sensor_begin to see the difference, and i didn't see anything strange, except in both iter->ptr->data and ->type is 0x0000000, and the debugger can't evaluate the type informations. But it works. While debuggin sensors_begin, it(MSVS) enlight a few fields as red (iter, ptr, iter->prop, iter->internal) and both iter->valid and iter->ptr->valid are set to 0. Forcing it to 1 raises an Access violation reading in rna_iterator_array_dereference_get trying to read 0x00000000. But collection_prop informations are right, the lenght is correct, and the code is the same as actuators, so i don't really understand what's wrong... About actuators-> controller As you can see in the patch, i check for all the controllers the current object owns, and check if some of that controllers hods the current actuators. Obviously this is wrong since it doesn't find other object controllers connected to the actuator: it should get all the objects in the scene, and repeat the same process on each of them. I don't know who to find the current scene from the actuator or the object, in addition is it correct to initialize the array of pointers in the _begin method? Will it be called again if after accessing it the first time, a new controller is linked? To sum up: 1) sensors->conts-> actuators -- Already doable 2) sensors<-conts->actuators -- I think it is doable, just need to understand what is happening 3) sensors<->cont<-> actuators -- Hard, inefficient, and right now always crashes on BLI_countlist (i think i'm doing something wrong retrieving the ListBase..)%%%

Dalai Felinto commented

2012-01-14 00:57:21 +01:00

%%%so let's reflect what the blender code exposes:
sensors.controllers and controllers.actuators

simple, cleaner and get your patch in trunk sooner. mind updating the final patch so I can commit?
thanks%%%

%%%so let's reflect what the blender code exposes: sensors.controllers and controllers.actuators simple, cleaner and get your patch in trunk sooner. mind updating the final patch so I can commit? thanks%%%

Francesco Zoffoli commented

2012-01-14 02:04:40 +01:00

%%%No problems!
Here the patch!
Thanks for your time!%%%

%%%No problems! Here the patch! Thanks for your time!%%%

Dalai Felinto commented

2012-01-18 23:43:34 +01:00

%%%committed on rev. 43510 thanks for your work!%%%