Box2d in beta34.2 broken

vvvv beta bug
22

@gregsn : Simple example (new node interface)

I want to access Value or Color (INodeIn)

FX.SetSubType(
new Guid[]{
typeof(IValueData).GUID,
typeof(IColorData).GUID,
},
“Value Color mainly”);

With “33.7” that would be working.

With new “AND” connection that is not (you can’t connect it anywhere instead).

And in that case you can’t create a common interface.

Plus, adding new interface means that for every pair you’d want to accept you would need to add interface on every types, as an example, type T, U,V

if you need T and U, you need I1 and modify T and U that they implement I1
if now you need U and V somewhere else, you need I2 and modify U and V
and so on. (I’m not even speaking of the case where T,U and V reside in different assemblies) This is more like a workaround to patch the workaround…

Instead with 33.7, you simply set your node to accept T and U, if you need to accept Z (without source code access), you can add it seamlessly. This was working, now it’s gone…

Also maybe I should have done an example patch, but here is what you have with box2d (just tried with b35)

I made the example using the simplified example.

ValueTestNodeIn.zip (11.2 KB)

Connection is not accepted (as you can see the “Connected pin” is false), but link is visually present. So I have doubt that the new type system is still working properly.

So basically ,this is broken, please fix…

23

hey vux!

We once discussed a new version of the plugin API (dec 15) that made it possible to connect any data to an input pin, even basic data like string, value, color, a feature request of yours that somehow sounds related to what we are facing now if you think about it; even though it’s about other interfaces in this case. Plugin interface feature request. I made that change public in alpha builds so that it can be tested and asked for feedback on that, which you thankfully did by saying that it pretty much works as expected. It’s been a breaking change (which of course is always very unfortunate), but one by design. So i wouldn’t count it as a bug that it doesn’t work as 2014 as it got redesigned to work like that. After a test period of one year this got beta.

Now what changed back then: A node pin (even those on GetSlice (Node), IOBox (Node) and Switch (Node)) now stores one list of interfaces. This list includes all interfaces that the data source supports (e.g. Granny Smith, Apple & Fruit). It feels straight forward on a data source of type Granny Smith to support the super-types as well. The simplification back then also got rid of “needed” interfaces, now its all about supported interfaces. This is very much like in c# where you also are just unable to have an input on a method stating that this argument should be of this or that type; it’s only possible to state one type. It’s a simplification of a system that felt bloated and led to subtle bugs before, especially when more source and sink pins got involved (like via a Switch (Node) that introduces many source pins and then of course the many sink pins that always are possible when linking from an output pin several times). So with this simplification again it is all about supported interfaces. If you now have an input that accepts more than one interface you are telling the system that you need to access all of them, and the source shall support all of them, which may be handy sometimes, but is not what you want in this case.

There are ways how to get the “or” done. Just take object or a base interface. Your critic concerning the pairs of interfaces is valid but also getting a bit theoretical. It is a bit like saying c# is broken as it doesn’t allow to specify at a method argument that one or the other type is ok. To be fair c# never had a version where this was possible and didn’t have to sell a breaking change. Anyway i am very sorry that we had to trade the requested features against a breaking change, but i have some hope that adjusting to the change is not too hard, if you would take a shot. We’re right here, if there is anything where we could be of help. Just thinking: maybe also a custom connection EDIT: handler could help? Again sorry for the inconvenience and yes it’s been a tiny neat feature that we’re sorry to have lost…

There is another thing where you are right: links that were drawn back then and now wouldn’t be possible to draw anymore are still present. I guess deleting them on open is also no option. To address this properly we need to wait until we have red links (similarly as in VL). Anyway, i would still hope that by adjusting the source code to just accepting anything (like described in my previous post) would remove the urgent necessity to attack that problem, as the connection would be valid again.

Thanks for your dedication to everything vvvv.

24

as previously agreed upon with @vux we have removed box2d from the addonpack for betas>35. now vux can maintain and release box2d at his own convenience.

it was our mistake to include binary contributions in the addonpack in the first place, as we can see we’re now in the position where we’d like to maintain the code for changes we made to the plugininterface but we have no chance to do so.

our offer stands to help adapt the code when it becomes publicly available.

25

Binary contribution?

Shows code was there, but has been removed on this commit (I emphasize on the “was there”)

So basically, you never had a look into your own repo…

26

we of course first tried to work this out ourselves using that code from the addonpack. but turned out that “small commit” you mentioned above prevented us from succeeding. you should also have received an email from elias (on feb 9th) about this, asking for help, which you haven’t answered so far.

you indeed had a separate repo for this on your github but have since removed it and the link to it from this forum thread. again: if you’d be so kind as to share the complete code that allows us to build the state that was shipping as binary in the addonpack so far, we’d be very happy to make the adjustments needed to get box2d running for everyone again.

27

what i don’t really get is: why this broken thing was allowed to stay in the repo for ages and now while vux has fixed it or applied changes to react to SDK changes (which were not really published nor set in context with this lib problem), it get’s removed. that’s incoherent SDK politics.

similar erratic behaviour seen in a pull request of a simple plugin on the sdk.

this is not good for the community.

28

@u7angel the removal was in accordance with @vux. since box2d is a bigger library with a more complex build-process (compared to simple plugins, like many are in the addonpack) we agreed with vux to remove it from the addonpack so it would be easier for him to maintain/release it independent of the addonpack release-cycle. we agreed on this before and independent of the problem discussed in this thread.

why did it take so long? because we didn’t pay attention to the issue you initially reported. that was our mistake. removing it now from the addonpack is still the most sensitive thing to do because it can now be fixed and offered as a download anytime and would work with b35.1 as it will not conflict with the “broken” version still in the addonpack.

the pullrequest you’re referring to is this one: https://github.com/vvvv/vvvv-sdk/pull/284
where i tried my best to argue why it is important not for us, but for every user of the addonpack to not accept any submission as it is, but point out some things to help the authors make their contribution more useful for everyone.

hope this makes sense…

29

still, it’s applying standards differently. broken things can stay for ages, simple dynamic plugins are discussed to death about code cosmetics.

30

i’m afraid i’m not exactly sure what you’re trying to say with this?!

if you read my last reply in the PR you should understand that the code-cosmetics are the less important part. my main issue there are the pinnamings which are incompatible with the original framedelay node. did you understand that?

31

i’m saying the quality of the addonpack should be about things that work. and to me it looks like you pay more attention to pin naming conventions than to reported problems of the sdk causing big libraries like box2d stop working. that is my point.

32

i can only repeat, yes, it was our fault not to follow up on this issue much earlier. but here we are now and we’re trying to get this sorted.

regarding pin-naming conventions: there is this feature in vvvv when you replace a node with another one that pins with the same name stay connected. in this particular case a Delay (Animation Framebased) is proposed that should be in everyones interest to be pin-compatible with the original Delay (Animation) so it can easily be replaced without loosing links. when designing the library of vvvv we pay a lot of attention to such details to make sure it is comfortable to use for everyone. this should explain why i think it is in the best interest of everyone that the pinnames are adapted accordingly.

33

In case of c# it is not broken, since it was not possible, that’s a very different thing.
In your scenario, and if your want a better example (which actually fits perfectly), it would be like if suddenly discriminated unions got removed from f# (you would quite imagine that it would make a “few” people unhappy).

So that’s a major difference… (Also as a side note did you even knew that the or case was possible…)

On a large patch you can suddenly see no issues at all, while the whole thing is broken, that’s very problematic.

Deleting links silently (and really, you could at least provide some decent info on TTY, for now there’s not not even a node name,for now it only says : “hey there’s a broken link in your patch, but find it yourself”).

It is not so much nicer, but at least someone who knows the patch can see that a connection is missing (and in that case would have been rather obvious straight away)

Red link in UI would of course be a solution, but there’s the word color and UI in the same sentence…

I would totally prefer that you sort this problem, since actually I had other issues report that it affected some dx11 patches as well (some geometry drawers connections got broken as well in that process…)

34

we are working on a solution for this that will make everyone super happy.

3 Likes
35

fixed for upcoming. alpha comes with a fix. let’s discuss details in a new thread or on irc.

1 Like
36

So this means box2d will be back with next release?

37

yes. vux and I are in contact clarifying details.

2 Likes
38

Does this mean we have to wait til 35.9 or beta36 to get box2d back?
Is the only work around before that to just use a pre-34.2 version?

39

mrVux will add it as a contribution, which will work with the current beta.
Also the old Box2d DLLs from older versions of vvvv, where Box2D were part of the Addonpack, should work with the current beta. And then, here is his repository: https://github.com/mrvux/vvvv-Box2D

40

Thanks Gregsn!

41


@vux thank you so much!!

1 Like