I'm building a class (sorry - Agent) that will work with a set of Tank objects (Fluid Library) - doing things like monitoring individual levels or total level of all tanks, reporting on levels and initiating actions based on levels - things of that nature. For argument's sake let's call it a "TankMonitor" agent.
Ideally I'd like to be able to define a Parameter in my "TankMonitor" agent that allows me to define the tanks of interest when I place a TankMonitor in main. I have tried to define the type of the parameter as Other - ArrayList<Tank> however I don't know how to set up the next step to allow me to populate the ArrayList of Tanks when I put an instance of this agent in main. My preference would be to have a list type control to populate the ArrayList - much like the way the AnyLogic Seize block allows you to specify multiple resource pools to choose from.
Has anyone attempted this before and been successful?
This is possible as follows:
Change the type to "Other" and then 'Tank[]' , i.e. an Array of Tanks
Change the control type to "one-dimensional array"
Example below. Now you have the same UI to pre-define tanks at design time for your agent instance.
In addition to Benjamin's perfect answer, I'd just add the manual workaround, which is not needed here but can be useful when the parameter in question has a more complicated structure than covered by the pre-made controls, say a list of lists, a map, or similar.
In such a case, the Control Type is still Text, and populating it in an instance happens by pointing it to a new object of the parameter's type. E.g. for an ArrayList<Tank> parameter, you might instantiate a new ArrayList object, which you fill with a list of objects like so:
new ArrayList<Tank>(Arrays.asList(tankA, tankB))
In the Java code, whatever is written into that text box will end up on the right side of a parameter assignment statement in the embedded Agent instance's auto-generated parameter setup function. Therefore, multi-statement code won't work in this spot. Instead, if the process of building the parameter value doesn't fit neatly into a single expression, you can hide the code in a function which returns the desired object, and call that from the parameter's text box.
Related
I built a custom block that, among other things, tells the resource entering portIn of the block to move to the resource's seizing unit. I use a moveTo block with the destination node as: (Node)((Cart)agent).getServicedEntity().getNetworkNode(); but I need to know the agent type and cast it into the method. I would like to make this a generic block that can be used in other models and with any Resource Unit.
I've tried using generic parameters in the custom block
then selecting the agent type:
and then trying: (Node)T.getServicedEntity().getNetworkNode(); but this results in compiling error: The method getServicedEntity() is undefined for the type T. Is there a way to do what I'm looking to do? I'm fine if the user has to select the agent type using the generic parameter pulldown, but I'd like to avoid having to change the code every time to add in all of the resource types available in the model using the instanceof command and then duplicating the code. Seems inefficient.
Well, your "T" extends Agent, and Agent does not know about getServicedEntity.
What your T extends needs to know it is a resource unit. Easiest solution I can see:
Create a parent class MyResourceUnit (but do not instantiate it)
Make sure it is "used in flowcharts as Resource Unit"
Make all agent types that should ever use your custom block to extend MyResourceUnit
Now in your custom block, you should make T extends MyResourceUnit
I've created a Pure Data abstraction which takes 5 MIDI controller IDs as arguments, and has two inlets (velocity and MIDI controller). I use spigot to output the input velocity at outlet i if the MIDI controller ID matches the i th argument to the abstraction.
I use this to control 5 sliders (volume, attack, decay, sustain, release) from my MIDI controller, which look like this:
As you can see, the abstraction is very repetitive, and ideally it would be able to take n arguments, outputting the slider value of the given MIDI slider at the i th outlet. Alternatively I could just use a single argument and use the abstraction anew for each slider, but that's a bit repetitive too.
Is there a way to take n arguments in my abstraction? Or, is there any other more elegant solution to control sliders from MIDI that I'm missing?
For core vanilla objects or externals it is a common feature to take a variable amount of arguments. Many objects like [trigger], [select], [pack] or [unpack] behave this way and create a number of xlets according to how many arguments they are given.
For abstractions however, there is no simple way to have a variable number of outputs depending on the number of arguments given. It's possible, but it's rather a hack.
Let's first look at some techniques to make the patches easier.
As you can see in the following screenshot the [expr] object in your patch can easily be substituted by a simple Pd object: [==]
Let's look at the MIDI messages. MIDI objects output the elements of the hierarchical tree: channel, controller, value in this order but from right to left (true for all objects in Pd, the rightmost outlet fires first). What you want is routing them according to the controller number, ignoring the channel number. For this you need to flip the order of the two first outlets so you can use the controller number as a selector in a list. One way to do this is to pack the numbers and then reorder them in a message using the dollar symbols (careful, dollar symbols in message objects operate on local messages, they have nothing to do with what dollar symbols do in object boxes). Another method would be to use the object [swap] (using [swap] in this case would reduce the number of objects by one in the patch, but the [pack] and [message( is more versatile, that's why I show it here).
Regarding the actual question of taking n arguments to change the number of outlets: This challenge are two separate problems:
How to detect the number of arguments
How to change the number of outlets dynamically
Until recently there hasn't been a way proper way to detect the existence of arguments. Since Pd 0.50 there is [pdcontrol] which allows exactly this.
Using [initbang] here because [loadbang] would fire too late for creating the outlets.
The second part of the challenge may be solved either through a technique called 'dynamic patching' or by outputting a list instead of creating additional outlets. However with a list output you'd need to route it afterwards and then you'll arrive quickly at the patch pictured above.
Say i have a public list of integers then of course I will see the list in unity inspector and i can assign multiple values inside it. My question is when the list will actually assign the values to the variables in the game?? Does it assign values in "OnEnable()", "OnAwake()", "OnStart()".
During deserialization
Which occurs before any method of that script's code is called.
If you want to run code at that point in time, you need an ISerializationCallbackReceiver. Note that the intended use of this interface is to serialize/deserialize certain complex Types (such as dictionaries) for use in the Inspector; I have not attempted to use this in a runtime capacity even though the interface does appear to be in UnityEngine not UnityEditor.
I'm just picking up om.next and have run into a situation where I've got some form inputs realized as components which hold on to local state, e.g. validation state, actual input value, etc--this state is updated and accessed via om.next/update-state! and om.next/get-state. The trouble with this seems to be when I wrap the inputs in a form in a parent component I'm unsure how to get the state held by the input components. Is it better to pass along the parent component as a property of the input component? What about situations where there is no parent component?
It seems to me that there are 2 options for the use case you want to achieve:
pass the parent component as an argument as you said
have an entry in the global app-state that represents the current form being edited, which you can update via transact! irregardless of the component corresponding to the input. This way every component that represents an input knows where in the app-state to update itself (which key in the current form) — probably captured succintly in one mutation function.
1) is probably the easiest to implement given the code you have currently, but I always like to go for 2) because it doesn't deviate from the "single source of truth" opinion that Om Next recommends (and tries to enforce). Form data is in fact business data, which might not be desirable to have scattered in components. Testability is just one advantage that I immediately see from such approach.
I would like to present the user with a variable number of scenes within the GUI (arranged say horizontally) composing different views of the data, depending on runtime conditions?
I really don't want to redefine the GUI, and a number of scene related traits for every use case. (i.e. bool_scene_1_viewable=Bool(), bool_scene_2_viewable=Bool()... )
It looks like I might be able to define a wildcard trait: scene_=Instance(Scene,()). But, if this is the best way to do it, how would I go about combining n traits into a View?
(A) I did not distinguish between "runtime" dependence, and merely depending on some number of traits that are declared after initialization (but before config_traits is called). As such, I can use default_traits_view to create a view that depends on the current state of the object and its members.
(B) I was also confused about how to turn this list_of_scenes into an object that could be viewed. After all, HGroup and VGroup don't take lists! I was missing that * could be used to unpack the list.
Steps:
1. init class instance
foo=Foo()
add scenes as you like
foo.add_trait(string_scene_name,scene)
foo.scene_name_list.append(string_scene_name)
foo.scene_list.append(scene)
Create group within default_traits_view()
items=[Item(name,style='custom') for name in self. scene_name_list]
scene_group=Group( *items)