The only issues I have spotted are related to vfx / visual applied to pc before/after scaling that are not syncing. I have a visual familar on shoulder system that while the pc apply the visual(familar on shoulder) the visual matches the size even after scaling, but if the visual is removed and reapplied then it reverts to standard size. Hmm might be able to work around it with scripting.
Seem the latest build has fixed these issues, but more testing is need. Thanks BD great new development branch release.
So . . . if we had a way to determine an angle perpendicular to walkmesh, we could script a system that made for much more natural traveling over steep/sloped terrain: especially 'long' animals or 'objects' such as a stagecoach, could be tilted to match the terrain going uphill or downhill. Horses would look better going over steeply sloping grasslands if their hindquarters weren't floating above the ground, right?
Is there any way to get such information currently, and if not, could this be something added at some point?
So . . . if we had a way to determine an angle perpendicular to walkmesh, we could script a system that made for much more natural traveling over steep/sloped terrain: especially 'long' animals or 'objects' such as a stagecoach, could be tilted to match the terrain going uphill or downhill. Horses would look better going over steeply sloping grasslands if their hindquarters weren't floating above the ground, right?
Is there any way to get such information currently, and if not, could this be something added at some point?
-JFK
Best way I can think of is to have mirrored hit box/ rootdummy system adding another column in the appearance.2da. You would have two rootdummy/impact node on a mesh, attack radius mirrored in the 2da and treat each separately for walking so the front hitbox/rootdummy mesh of the horse would start up the hill and the back part would follow but be treat at a different height in relation producing the angled effect you want. I asked for mirrored hitbox in the suggestion section, but has not been added to the trello yet. I mainly wanted it for elongated creatures like dragons on four legs looking and working right in fights. (with some attacking the back and some attacking the front). This would be backward compatible because the if the mirrored .2da column is left **** then it just defaults to normal behavior.
This definitely needs some clientside lerping. Adding some scriptable walkmesh transforms should be one of the next steps for that "feature set" as well, but it's going to need very careful thought on how to design the API and behaviour.
Slapped this one together. This is an example of where it gets tricky (for me anyway) because I'm not so good with the maths. You have to rotate AND translate either x or y AND translate z to make it look as though it's pivoting at the base of the logs rather than the base of the horizontal object. Kind of a pita.
The sliding bookcase was done before in 2012 by Borden Haelven for January of that year's ccc. This was purely modelling though. That particular month there was also a demo module which shows off all the content made for it including the bookcase. So you can check it out if you want.
Re. your maths headache. If you want to save in-game time it might be an idea to do the calculations out of game and store the results in a custom 2da. Then access using Get2DAString.
Also you may find the manual I wrote for a small utility that I made a while ago, to be of use. As the utility is for the manipulation of the coordinates of models, it is probably of no use to you. However in the manual I explain about the maths of rotation in 3D space and include the formulas necessary to do so. RotateEm is here.
I just thought of an addition: it would be so cool if the transformations could be done over a specific amount of time, like by adding a float to the end of the command. This would hopefully allow the bridge to be done with far less steps and math, and make it look generally smoother. (Pretty rad job though, @NeverwinterWights!) But also, think about it - you could fake having bridges you could walk over and under by playing a characters walk animation, have them translate across the bridge over a specific amount of time, and then reset their translation and just teleport them at the end of the bridge. This could also make the transition between two different scale values more smooth and less like its in burst.
I might be ahead of myself, though, and I don't know the technical ramifications of such a feature, but to me that would be an incredible addition to an already great addition to the game.
I just thought of an addition: it would be so cool if the transformations could be done over a specific amount of time, like by adding a float to the end of the command. This would hopefully allow the bridge to be done with far less steps and math, and make it look generally smoother.
Yeah something like that might be nice. Right now the only way to make it look smooth is to translate a very small amount at a time. But you have to be really careful with the delay between each translation and how many iterations. So if you move something like by 0.01, 1000 times, with a delay of 0.1, it looks really smooth but moves really slow. You can speed it up a little with a delay of like 0.05 but then you start to loose some of the translations visually, and if you try to speed it up more you can end up with a stack overflow (depending on iterations). I've been tweaking the heck out of these trying to make them look as smooth as possible without too many iterations and using workable delays.
The system really wasn't designed to do manual lerping like that.
Please keep in mind that every update to the transforms sends a full update containing all the transform vectors, incurring the bandwidth cost (negligible at 10ms intervals, but still - 10 floats a 4 bytes per update per client, if you want to do the math yourself), the cpu cost on the script system, and the general messiness of it.
I'm not saying you shouldn't do it, just pointing out the hidden costs of it.
That would be great. Using it for animation right now is possible, if you don't mind that it's not very smooth (as the great examples posted here demonstrate).
However, achieving smoother motion is tricky. I wasn't surprised to find that very small delays (in the region of, say, 0.001 seconds) crash the engine. A delay of about 0.05 seconds (equivalent to 20 fps) works quite well, but still looks jerky unless each movement is tiny (and therefore motion is slow).
Of course, since the scripter is sensitized to look for choppy motion, we are probably aware of tiny defects that players might not notice.
Ah, sorry for digging this thread up, but I'd like to ask a couple of things.
In regards to size effects, I've managed to enlarge a placeable on OnClick, as well as define a tag that enlarges (or shrinks) items OnModuleLoad.
I'm having a problem customizing this further, because I'm terrible at scripting. What would be an example of fliping an item on its own, as @TheBarbarian did for the PC? Let's say I have a boat, which I converted into a placeable from a tileset, and want to show it as capsized. How should I write the script if I wanted to tilt it over terrain, or go full out and flip it entirely?
SetObjectVisualTransform_Rotate_X(GetObjectByTag("capsized") = 35);
-Isn't recognized by the Script Editor.
Also, let's say I'd want to apply the enlarge effect on an enemy with each successful melee hit in combat. Is this more complex?
I believe that 1.0 is just default scale and won't change anything. 2.0 is quite a big difference so you might want to play around with smaller float increments. 1.1, 1.2, etc.
So, just a quick test. I got more or less the kind of effect I wanted.
The rowboat model placeable doesn't have a bottom (as @NeverwinterWights said, many don't have one), so it's a question of rotating and placing objects in a certain manner (I'm guessing other placeables can be added neaby to give a shipwreck feeling, like timber, debris, etc.)
On the other hand, that bright white fog is the standard Mist placeable blown out of proportion, and placed below the terrain (around -5 on the Z axis). Great for some wintery stuff.
In another test module I've also managed to create a Winter Wolf copy, and define an increase in size OnSpawn. Unfortunately, because most animations aren't keyed to relative size, when the wolf attacks it bites and lunges the space behind me. But it's a start!
Comments
Is there any way to get such information currently, and if not, could this be something added at some point?
-JFK
This definitely needs some clientside lerping. Adding some scriptable walkmesh transforms should be one of the next steps for that "feature set" as well, but it's going to need very careful thought on how to design the API and behaviour.
Re. your maths headache. If you want to save in-game time it might be an idea to do the calculations out of game and store the results in a custom 2da. Then access using Get2DAString.
Also you may find the manual I wrote for a small utility that I made a while ago, to be of use. As the utility is for the manipulation of the coordinates of models, it is probably of no use to you. However in the manual I explain about the maths of rotation in 3D space and include the formulas necessary to do so. RotateEm is here.
TR
I might be ahead of myself, though, and I don't know the technical ramifications of such a feature, but to me that would be an incredible addition to an already great addition to the game.
Please keep in mind that every update to the transforms sends a full update containing all the transform vectors, incurring the bandwidth cost (negligible at 10ms intervals, but still - 10 floats a 4 bytes per update per client, if you want to do the math yourself), the cpu cost on the script system, and the general messiness of it.
I'm not saying you shouldn't do it, just pointing out the hidden costs of it.
Maybe lerping should be a followup soonish.
However, achieving smoother motion is tricky. I wasn't surprised to find that very small delays (in the region of, say, 0.001 seconds) crash the engine. A delay of about 0.05 seconds (equivalent to 20 fps) works quite well, but still looks jerky unless each movement is tiny (and therefore motion is slow).
Of course, since the scripter is sensitized to look for choppy motion, we are probably aware of tiny defects that players might not notice.
In regards to size effects, I've managed to enlarge a placeable on OnClick, as well as define a tag that enlarges (or shrinks) items OnModuleLoad.
I'm having a problem customizing this further, because I'm terrible at scripting. What would be an example of fliping an item on its own, as @TheBarbarian did for the PC? Let's say I have a boat, which I converted into a placeable from a tileset, and want to show it as capsized. How should I write the script if I wanted to tilt it over terrain, or go full out and flip it entirely?
SetObjectVisualTransform_Rotate_X(GetObjectByTag("capsized") = 35);
-Isn't recognized by the Script Editor.
Also, let's say I'd want to apply the enlarge effect on an enemy with each successful melee hit in combat. Is this more complex?
Hopefully someone can help me with this... ^_^
void main() { object oObject = GetObjectByTag("testboat"); SetObjectVisualTransform(oObject, OBJECT_VISUAL_TRANSFORM_ROTATE_Z, 180.0);//rotates/flips object SetObjectVisualTransform(oObject, OBJECT_VISUAL_TRANSFORM_TRANSLATE_Z, 0.8);//raises the flipped object }You can play around with the numbers to get the rotation angle you need.
And of course just bear in mind that a lot of objects don't have visible textures on the bottom so flipping some things might look weird.
SetObjectVisualTransform(OBJECT_SELF, OBJECT_VISUAL_TRANSFORM_SCALE, 2.0);
I believe that 1.0 is just default scale and won't change anything. 2.0 is quite a big difference so you might want to play around with smaller float increments. 1.1, 1.2, etc.
The rowboat model placeable doesn't have a bottom (as @NeverwinterWights said, many don't have one), so it's a question of rotating and placing objects in a certain manner (I'm guessing other placeables can be added neaby to give a shipwreck feeling, like timber, debris, etc.)
On the other hand, that bright white fog is the standard Mist placeable blown out of proportion, and placed below the terrain (around -5 on the Z axis). Great for some wintery stuff.
In another test module I've also managed to create a Winter Wolf copy, and define an increase in size OnSpawn. Unfortunately, because most animations aren't keyed to relative size, when the wolf attacks it bites and lunges the space behind me. But it's a start!