@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?
i tried to harass vux several times, it didnt work. sounded like the essentiell code is lost.
maybe it’s time for something else
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.
@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
@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.
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
So adding that base interface is an option then?
No, it’s not a solution, there is an issue with your connection system and it should be fixed.
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 ;)
So is there an ETA for this bugfix?
Any further ideas instead of using 33.3 for now?
allthebest!
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
- use the feature https://vvvv.org/blog/mixed-data-over-that-same-ol-pin and test for interfaces as mentioned (plugin interface v1) via
[Input] INodeIn - introduce a base interface and expect that on your input (plugin interface v2) via
[Input] ISpread<IBase>
@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…
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.
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.
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…
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.
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.
@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…
still, it’s applying standards differently. broken things can stay for ages, simple dynamic plugins are discussed to death about code cosmetics.