Box2d in beta34.2 broken

vvvv beta bug
1

box2d seems to be broken in beta34.2 32bit version. it’s not really clear why. i’m not able to connect getbodydetails to world anymore. as if the type “body” is not recognized anymore.

all the helpfiles stopped working

box2d playground either

2

randomly picked an older version 33.3 -> box2d works

what happened ?

3

indeed. broken since b34.1. the problem with box2d is that we shouldn’t have included it in the addonpack in the first place. iirc it was too complicated to build so we decided with vux to only include it as binaries. now of course it was only a question of time until those binaries are no longer compatible with the core.

and now we don’t even know if that is the case or actually something else changed in the core that broke them.

so in order to find that out i’d like to ask @vux to check that by building it against the b34.2 core and see if that works.

4

ok ok, but you guys are responsible for the core, any guess what might changed in the last release ?

5

please, just anybody fixed that for the next release?

+1

6

talked to vux. he is going to have a look at it…

7

No news is good news?

8

Unfortunatly not - Box2D is still broken.
Hope to have it back soon as well- Box2D is just great!

9

@vux
what has to be done in order for this to work again? is the source available somewhere?
what changed on the vvvv side for this to break?
is it likely that this might happen again, what can be done to prevent this from happening?

10

i tried to harass vux several times, it didnt work. sounded like the essentiell code is lost.

11

maybe it’s time for something else

12

I think @Vux Box2dNodes-Project are to be found in the vvvv-SDK = https://github.com/vvvv/vvvv-sdk/tree/develop/vvvv45/addonpack/src/nodes/plugins/2d/Box2d

When i open the Box2dNodes.sln in VS 2015, i can see the old PluginInterfaces and Utils to be missing. Maybe we can replace with Nuget-Versions?

And then (I think so) we need to add the Source code from box2d.org = https://github.com/erincatto/Box2D/tree/master/Box2D/Box2D in the Project-Folder.

13

@kimiki, the github code is not the full thing. vux did a c++ wrapper which is missing on github. this wrapper is basically the problem, why we can’t just recompile the github code against the latest vvvv version

14

@vux
Just had a look at it including the sample you sent us. Before b34.1 a node input accepted an incoming connection of the source if it provided ANY of the GUIDs set by SetSubType, after b34.1 it only accepts if ALL GUIDs are present on the source (Node type pins connection and type names broken). Reasoning was that to get the ANY behavior one simply adds a base interface to its class family and uses that ONE GUID of that base interface on node input pins.
This was a breaking change not properly documented indeed. So to get Box2D working again such a base interface has to be added somewhere - no clue though where exactly since I can’t access the source code and as I understand it you neither because the code was simply lost? :/
Reverting those changes doesn’t seem like a viable option to me as it probably breaks other nodes.

16

About code, since there is a bit of confusion there (and people tend to imagine things a bit too much) ;)

It’s always been in addonpack code, the whole thing (ok probably some outdated include path, and by the look of it it missed a small commit ;)

It’s indeed in separate repo now, as set above

17

So adding that base interface is an option then?

18

@Elias

No, it’s not a solution, there is an issue with your connection system and it should be fixed.

19

@Elias

Ok longer answer:

  • Prior to beta34.1 connections were working fine, so the ALL vs ANY was a non issue in case of direct connection.
  • There was an issue with IOBox (Node) and friends, this was localized to those nodes, which were messing the type system
  • Seems like the “fix” for IOBox node (from 34.1) is more a dirty workaround than a real fix (since as mentioned, connections without it are totally fine), which ended up breaking existing features.
  • So the problem is that reverting the change will make the IOBox (Node) issue visible again (since it was then just hidden), which is good, since now you can concentrate on fixing the root issue instead ;)
20

So is there an ETA for this bugfix?

Any further ideas instead of using 33.3 for now?

allthebest!

21

hey vux!

i just had another look at your bug report that azeno mentioned above, checked your patch again and our solution from back then. I also had another look at this one here: https://vvvv.org/blog/mixed-data-over-that-same-ol-pin which again needed some changes on the node pin system.
All in all i am positive about the changes we did to the system since then, as they not only conceptually cleared up a long-standing question, added features, simplified the node connection concept and still also got rid of the subtle bugs you reported in that small patch https://vvvv.org/sites/default/files/user-files/PinConnection_Issue.v4p

The long standing question was how we need to interpret the list of needed interfaces. Does every interface need to be supported by the source or just any.

In c# it is easy to express that a certain data type supports different interfaces. This is the “and” model: a certain class comes in different shapes and supports this “and” that interface. So basically when writing c# code and exposing all the different interfaces to vvvv you already express “and”. However there is no way to state in c# that you somewhere expect data to be of this “or” that type. You would take “object” or any other super-type and then test for the sub-types. This now aligns very well with how vvvv deals with lists of interfaces. Sources typically support many, sinks typically need just one. In short: we are happy with the rework and now want to help you to fix the issue that suffered from our breaking change.

What you can do is