The Lua error I get when trying to create it shows that it expects 2 strings (char *) followed by 6 floats as parameters. No regions/points/colors; I have no clue what these parameters are supposed to be, aside from presumably one of the strings being a material. Unfortunately, this function isn’t used anywhere in Stonehearth. Anyone (@max99x ?) have an idea?
1 Like
This was a weird experiment I did of rendering Chrome into world textures to show rich and dynamic (but non-interactive) tooltips. I guess we ended up not using it in the final game so I don’t know if it still works well. The parameters are:
- Node name
- URL of the page to render
- Width in world units
- Height in world units
- Width of the browser in pixels
- Height of the browser in pixels
- X offset, not sure in what units
- Y offset, not sure in what units
1 Like
Oh gotcha, thanks! Maybe I’ll use it for something in the future… I was thinking it was for rendering something like overlay nodes, as used by thought bubbles and requested task indicators, etc. Is there a particular kind of node I’d create for that? Otherwise it looks like I can kind of hack it through the start_client_only_effect function of a RenderEntity.
Thought bubbles and task indicators use the add_billboard_node method, without the ui part - it just renders a texture in screen space at a world coordinate.
I can’t find that function in the C++ reference, and it doesn’t appear to be a property of either RenderRootNode or _radiant.client in the debugtools client Lua console.
Huh, looks like it isn’t exposed to Lua directly, which sucks. You can still achieve the same result via unit status effects.
Yeah, I’m trying to do that now, like the thought bubble renderer does, except in a service with the terrain root entity’s render entity (which I was assuming was host to the RenderRootNode, since I don’t know how to go in the other direction and get the render entity of a render node), but having trouble.
-- passed in unique string 'name'
local render_entity = _radiant.client.get_render_entity(radiant.get_terrain_root(0))
local e = render_entity:start_client_only_effect('stonehearth:effects:attention_effect', {renderNodeName = name})
local n = render_entity:find_node(name)
but n is nil. I can switch it around to being individual entity-based rather than trying to stick everything into the RenderRootNode, but then I have to keep track of all the entities I’m rendering for to stop their effects, since that’s done via the individual render entity and not just by deleting a node.
IIRC the terrain is just an entity as far as the render hierarchy is concerned. My memory is fuzzy by now, but my instinct would be to avoid messing with the root render node and attach to the actual entities.
Unfortunately, as far as I can tell, this means it can’t be dynamic, because I see no way to generate HTML files or modify content. :-\ Otherwise this would actually be perfect for me. Unless… if the pages are rendered in the same browser sandbox as the main UI and I can specify scripts to pull in game data… but that seems like a big hassle.
Edit: Nope, trying to use jQuery in a script in the html page didn’t work, the ‘$’ operator was undefined. So if jQuery isn’t loaded, then I’d conclude that it’s not in the same sandbox. If there’s a way to dynamically generate html files, like how you can generate images (in a fairly limited way) with _radiant.client.generate_icon, then I could make use of it. But it’s rather impractical to generate hundreds (or more!) of html files ahead of time and ship them with my mod, and then it’s also not feasibly moddable by others.
Unfortunately, as far as I can tell, this means it can’t be dynamic, because I see no way to generate HTML files or modify content.
You can pass query arguments. E.g. /foo/bar.html?quux=42. Then pull the argument in the JS of bar.html.
Nope, trying to use jQuery in a script in the html page didn’t work, the ‘$’ operator was undefined. So if jQuery isn’t loaded, then I’d conclude that it’s not in the same sandbox.
Each billboard is its own sandbox (reused from a pool of CEF windows). You can definitely load jQuery and any other libraries the same way the regular main SH UI page does.
1 Like
Hmmm… HMMMMM…
Edit: Looks like it’ll be a little wonky with zoom, since it doesn’t seem to scale at all no matter how zoomed you are, but I think I can make it work for my purposes. It’ll certainly be better and simpler than the results I was getting trying to use the regular billboard nodes (that seemingly can’t be scaled, and the whole shader/material thing just seems really complicated).
You can mess with the zooming logic in the shader if you want a different zoom behavior.
But can I set a shader for a ui billboard node? Or would that just be if I wanted to adjust zooming for regular billboard/overlay nodes?
Edit: Oh, does it use the world_space_ui.material.json and world_space_ui.shader? I’ll have to look into it later.
Oh, does it use the
world_space_ui.material.jsonandworld_space_ui.shader? I’ll have to look into it later.
Yes.
Alright, it’s not perfect, but I think it’s getting a lot more usable. Just need to add some “select all/none” buttons and get properly colored buff icons. Currently caching on-demand the various billboard nodes for a given tower and then toggling their visibility rather than recreating every time, because they’re not frame-perfect and would flicker on creation otherwise (e.g., if it has debuffs in multiple filters and you switch one of them off, it will hold onto the old node so if you switch the filter back on it can just switch which node is visible).
3 Likes