I think it would be useful if the more complex operators had detailed descriptions of how they function. use case examples welcome.
The stacker.splitter is a good example of that (there is information about how it works in the concepts but it would be good if that information was available in the nodes page.
Yes. I do want to provide this. As you can imagine it’s potentially quite a lot of work. I might set up the framework for these pages adding the ‘problematic’ ones first and then gradually working through all the rest, over time.
I was experimenting with in-world and interactive demos of the operators (see this pic) and whilst the interactive nature might work for some (and be cool), I still think it’s not going to be able to be as detailed and useful in covering all the nitty-gritty details as proper docs will be.
Other concepts that I can imagine wanting to know how to do relativley soon (assuming these are even things that exist):
- Passing Frames into procedures, so that spaces and subspaces can be operated on without actual geometry
- Passing meta information
- Structs/Lists and their usage (I know I’ve talked with you about these before, but I don’t recall if they’re a future feature or already present).
Hi Kalev, welcome to the forums!
You may need to elaborate a little, so I’ll ask some questions…
- Do you mean passing frame around within procedures and sub-procedures? or do you mean as top-level parameters that appear in the actor details panel? or perhaps working with frames in blueprints?
- Not sure what you mean by ‘meta information’, you can pass int/float/string/bool/colour/frame/vector/lists/geometry around already. If you mean the metadata options you can set on procedure inputs (defaults/ranges/etc), then yes that could do with a bit more coverage in the docs, but it’s a bit of an advanced feature.
- Structures and lists are supported via the dynamically typed List data type (brown wires) and there are a number of operators to support them, e.g. Append/Get (by type), Count, etc. And you can compose your own ‘make struct’ and ‘breakout struct’ procedures to work with them. Currently lists are only accessed by index so you will have to keep track of the order of your struct members by hand.
If that doesn’t cover it, let me know
And yes, these could be tutorials, definitely.
So I think that there are tutorials about how to use features and tutorials about how to think in Apparance and the design patterns that support that. Most of the tutorial already present are about features, but the tutorial on iteration begins to cross over into how to think.
For the most part, I’m advocating more tutorials about how to think, and making guesses about what those would contain. If someone was building a city generator with districts, how would they go about it? I’m guessing they would pass frames down into sub-procedures, but then also have ‘meta’ information about what ‘district’ a building is in, and some of this may be done via structures.
However, you’ve just tantelised me with some of your answers. I may just stumble across this on my own, or it may be obvious if I were to go looking for it, but I’m now wondering how exposing top-level parameters to the actor works - specifcially I’d like to have a list of frames with some type or string information attached, so that, for example, in the city generator I could specify the size and locations or particular features or districts, or I could choose to leave those up to the algorithm.
Yes, there are both of those on the list. Currently I don’t have to bandwidth to provide them before release but will work on them post-initial release. As you know documentation is a bottomless pit of effort, but I do intend to add to what I have already, and in several forms potentially.
At the moment, the List type isn’t exposed on the Unreal side (Entity Actor parameters in the details panel). This is due to complications about how to specify structure types for lists, but this is one of the top items to come in update form after release. For now you will have to add multiple parameters and explicitly list the values you support (e.g. have a Frame input for coverage of each district type).