January 12, 2011
Due to demand and in anticipation of our next avatar, we've released Aggro's interactive trees in a concise and functional package for public use. If desired, the trees can be dragon-proofed and used as regular decoration.
The package contains the tree controller and several physical variations of trees which can be set to live, dead, snow, or fire modes. There are also two variations of tree stumps, and a fallen tree with always-dead branches. In addition to this, there's an optional texture preload block, and an alternate but slower non-mono script that consumes less memory at the cost of speed.
Central to this package is the tree controller, which allows the owner to adjust settings and globally edit trees. Only the owner of the object is able to use the tree controller.
Toggles whether the tree responds to being hit with fire or ice.
Forces all trees to return to their currently configured default state.
Sets tree's default globally to normal, living mode with green branches.
Sets tree's default globally to dead mode, with no green branches and dying, dried bark.
Sets tree's default globally to snow mode, with exposed branches mostly covered with snow.
Sets tree's default globally to fire mode, with a chance of live flames set by the Fire Particle Chance bar (described later on this page). Any tree with visible fire will emit a burning sound.
This bar adjusts the time that trees reset themselves after they've been affected by dragons. Clicks are locational from left to right, 5 seconds to 120 seconds respectively. When set on fire, the tree will spend this much time on fire, then turn to the dead state for another length of the timer.
This bar adjusts the chance in percentage that live fire will appear on burned trees. The consideration to make regarding this setting is both that of sim resource usage, total particle count, and fire emitter variation in large groups of trees.
The large fire particle emits 325 concurrent particles, and the smaller 225. With a single tree at 100%, you will see 550 simultaneous particles. The default particle setting for the standard viewer is to see 4096 particles. As such, with little or no other particle emitters present, you should not have more than seven trees (3850 particles) in place with 100% particle emission active if you want to have the full effect of the particles.
The following table contains recommendations for squeezing the maximum possible particles out of the trees. It's possible and recommended to place it a bit lower than this as activation is random by percentage, other particles may be present in the area, or players may have their settings lower than the default.
This button removes scripts from all of the trees. This is useful if you don't want the trees to change and want to save a little script time. Take note that this is permanent and should only be used if you're certain you no longer want the changing functionality for your currently placed trees. You will be prompted for confirmation before the scripts are deleted.
This button deletes your current in-world Aggro trees. This is used as a quick cleanup function more than anything, and cannot be undone. You will be prompted for confirmation before the trees are deleted.
Turns all your trees phantom, which means objects and avatars can move through them. If "power" is enabled, they will still react to fire and ice.
Re-enables object and avatar collision with your in-world trees.
Landmark to Aggro. :3
Multiple Defaults for Trees
The control panel uses llRegionSay and the trees verify that something the owner owns is doing the commands. This means the control panel should effect all trees you own in the current region (and theoretically, no trees outside of the region).
If you want to have an area that has snowy trees, an area with burnt trees, an area with dead trees, and an area with green trees, you'll need to place all of the trees you want in a single area, use the control panel to set them, then "disable" them while you create and modify the other areas.
Complications arise because using the handy "set scripts to not running" does not ignore but only pauses the event queue. Also, official viewer 2.x does not actually show completion feedback on said mass-script operations, making it more difficult to use. Following the below instructions are probably the easiest way to set your trees to different defaults.
The trees should now have different default states but still respond to fire and ice as expected.
Another method would involve putting down a group of trees as you like, then taking it back into inventory as a coalesced object, and proceeding to the next area of trees. Rez them all back out when you're done.
Please note that, after having done any of these, if you set a new default state it will change all of the trees. This is a workaround, rather than a design solution.
There is a "preload prim" that comes with the trees. It contains on its faces all of the textures that the trees use in any of their states, including the texture used for the fire particles. To avoid the texture load time between state changes, it's recommended you take this preload prim and hide it somewhere near the middle of the forest you create. If the forest is large enough, you may want to rez a couple of them in various areas.
Proper use of the preload prim will prevent the delay with blank/murky textures on the tree during a state change.
Public Control Panel
If you want others besides the owner to be able to control the trees, you can replace the script in the control panel with the "Control Panel Public" script. This will allow anyone to use the control panel's buttons except for the buttons power, delete scripts, and delete trees. Also, all messages are heard by anyone within 20 meters of the control panel rather than sent directly to the control panel's owner.
If you use this script, it's strongly recommended that you also change the name of the object so you don't confuse it with the owner-only version of the control panel.
The trees contain one script. In order to get a quick and snappy response, it is compiled as Mono. This means it takes 64 kilobytes of script memory. We include a non-mono version that is noticeably slower in changing states, but only takes up 16 kilobytes.
Overall, it's probably better to use the Mono version, especially because the bytecode is shared in Mono scripts. But if you really prefer, we've included the standard LSO version for you to test.
Once script memory can be properly limited in Mono, there will be no potential advantage to using LSO.