I’m not one of the engineers working on Soba, so take this with a grain of salt - but I think LINQ delegates are features we could implement into Soba eventually!
For now, we’re focusing on releasing Soba in a polished, functional state.
2 Likes
Hm is the GetType not being supported in Soba a forgotten thing/overlooked or is that intentional ? GetType is kinda.. Required for a lot of things xD And removal of that would break probably some people’s stuff 
If you’re wanting just mainly List<> Dictionary<> Queue<> and similar.. Etc..
Then you’ll be able to make your own custom implementations of those, while using DataList or DataDict under the hood, I’ve done the same for U# 1.2 and it’s much faster than the List<> etc.. that U# 1.2 implements.
And in Soba it very likely should be even faster in theory.
Soba has is and as - do you think that would be sufficient, if GetType is not available?
Here’s another upcoming feature for avatars that we’re working on:
We’ll mention it in our next roadmap - sorry for not including it in the post!
1 Like
I don’t see static variables in the soba chart. Are static variables planned to be supported? It would save on a lot of reference passing in my world as each entity needs to be passed a reference to every manager script. Delegates and events would also be extremely helpful as I would be able to save on a lot of polling to get another objects state and I can move to a more interrupt style setup. I currently have hundreds of entities and as an example if I want to watch for a collision, I need to poll for the collision as the collider is on a child of the scripted gameobject, so I can’t use the OnEnter override.
Yes! Soba supports static variables.
Perhaps related but I’ve used GetUdonTypeName() to store “singleton” UdonBehaviours within a DataDictionary (the udon type name being used as the key). And while true singletons won’t require this for Soba, having something like this for PlayerObject “singletons” would still be useful:
localPlayerManager = (PlayerManager)referenceHandler.GetPlayerObject(GetUdonTypeName<PlayerManager>(), Networking.LocalPlayer);
Correct me if I’m wrong but is and as would not be useful for this use case unless I want to manually write down and check for every possible type, having to edit my “reference handler” script every time I had a new type, right?
A bit of a late question but will Unity Events be allowed in soba? General events not being allowed is a bit ‘meh’ but a lot of the issues can be solved with Unity events and some ingenuity.
This is already possible.
You can already do this by choosing ‘CustomUdonEven’ and just calling the function by name when it asks for a string.
I don’t think you understand that Delegate Events/Unity events and Sending Remote procedure calls are not the same.
Remote procedure calls do not support listeners. Events are handy to prevent having to reference large arrays of UdonSharpBehaviours to handle sending ‘messages’ to other components.
The whole reason people want Events to be supported is that they make creating ‘signals’ or ‘message’ or any other alias found for them easier to setup and manage. Remote procedure calls won’t handle listeners.
And with this, making a static UnityEvent or Event Delegate (if ever supported by soba) Allows for singleton events, instead of once again creating Hundreds of references between Udonsharp components for a (remote) Procedure call
Somehow didnA’t see this until now month later.. But “is” and “as” is useful but I don’t think it’s sufficient, apart from the obvious reason that it break the “soba has everything current udon has”
It prevents you from doing any kind of dynamic type matching or similar systems.
“is” and “as” are both compile time in the sense of you can do
object a = “test sring”;
object b = 32L;
if (a is string)
{
//… works as “string” is compile time constant
}
if (b is string)
{
//.. works as “string” is compile time constant
}
if (a is b)
{
//.. Invalid, can’t compile
}
if (a.GetType() == b.GetType())
{
//.. very simple usage but works
}
You can set up event listeners in U# by using SendCustomEvent (calling the function) and optionally SetProgramVariable (setting function parameters) and GetProgramVariable (getting a return value).
The main limitations are that it requires some extra setup, requires all listening classes to use the IUdonEventReceiver interface, and isn’t type safe.
Extra tip: if Set/GetProgramVariable support DataTokens (which I presume they do), you can use those for more flexibility at the cost of type safety.
Example Code
public void AddOnClickListener(UdonSharpBehaviour udonSharpBehaviour, string methodToCallName)
{
onClickEventReceivers.Add(udonSharpBehaviour);
onClickEventReceiverMethodNames.Add(methodToCallName);
}
private void OnClicked()
{
isClicked = true;
buttonRenderer.SetPropertyBlock(pressedMaterialPropertyBlock, buttonHighlightMaterialIndex);
for (int i = onClickEventReceivers.Count - 1; i >= 0; i--)
{
IUdonEventReceiver eventReceiver = (IUdonEventReceiver)onClickEventReceivers[i].Reference;
string methodName = onClickEventReceiverMethodNames[i].String;
if (eventReceiver != null && !string.IsNullOrEmpty(methodName))
{
eventReceiver.SendCustomEvent(methodName);
}
else
{
onClickEventReceivers.RemoveAt(i);
onClickEventReceiverMethodNames.RemoveAt(i);
}
}
}