Author Topic: Custom Content Challenge: November 2015: Wizard's Tower  (Read 2978 times)

Legacy_ShadowM

  • Hero Member
  • *****
  • Posts: 1373
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #60 on: November 16, 2015, 12:48:00 am »


               

I think I do that for my base, I do not think I need the higher poly books just the better textures. Thanks '<img'>



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #61 on: November 16, 2015, 12:53:10 am »


               


@MD Any plans to convert those books to item icons as well? If you do, grab the scripts from my micro maps so that they can be picked up, placed in the PC's inventory and dropped back down as placeables again.


 


TR




I had not planned on it. I already have too many item icons to mess with, and I don't normally use standard sized inventory items anyway. For instance, most of my potions are 1x1, with larger reservoir items being 1x2. I'll probably just leave that up to other creators if they want to screen shot them or something for item icons.


               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #62 on: November 16, 2015, 01:42:39 am »


               

For good measure, I just standardized the surfaces of all the books so you can just pop a new texture in and replace any of the books. Here's the textures if anybody wants to play with them without the models.


 


ykhytc3.png


 


OOlpWV6.png



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #63 on: November 16, 2015, 01:59:03 am »


               


You know, it's too bad it's so (seemingly) difficult to get new tiles into an existing tileset.  AFAIK, every additional tile (even variations), have to be added to the .SET.


 


Can someone familiar with tilesets chime in on whether there is a way to add a variation (specifically a variation) to an existing tile without having to touch the .SET?  Other than replacing an existing tile in a tileset, are there any "drop in" solutions for tiles at all?




 


The SET editor from way back has a feature to examine and clone any of the tiles. After you alter any data, you can either hit "save change", or to add a copy, there is a button for that. What I do is select the tile I want to clone from the left tile list, immediately click add/copy while viewing the data, then update the data to point to my new tile, then save changes. That's the old SET file editor beta 0.85 by the way, not the newer one from MDA. I can't get his to play nice on my machine and it crashes more often than anything else. Just as a side note, if you are adding to a set that uses nonstandard height transitions, DON'T EVER SAVE WITH THE OLD ONE. It will set all non-zero height transitions to 1.


 


The only other option is override.



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #64 on: November 16, 2015, 09:00:20 pm »


               

I'm starting to worry that I will ever only have time to do some of these tiny projects ever again. In the frantic worry, I'm trying to finish up a few projects which are important to me. I may or may not have some casting alternative animations to package with this month's stuff. I spent most of my free time today trying to refine my special animations for my module characters. The ones with the extra bones, and the parts moved around on the bone system. One of the things I was working on was an animated weapon which backward clones the animation node structure of the arm. It then makes it look like your arm is covered with ice or fire, like you are channeling some tremendous elemental power. Not finished yet, and still having a little trouble with the right and left handedness of GMAX, but I would like to get that out sometime soon. I mean before January 11th when I go back to school.



               
               

               
            

Legacy_PLUSH HYENA of DOOM

  • Hero Member
  • *****
  • Posts: 995
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #65 on: November 17, 2015, 07:06:27 am »


               

3Ravens:- There's no reason you couldn't convert my Rubbish Wizard Towers to Tile Groups, but I did them as Placeables so that they can be, um, placed anywhere, in any Tileset, as and how anyone wants them, rather than nail them down to one specific Tileset.


 


In terms of making them Tile Groups (they're all too large to fit on a single Tile as a Feature), you would have to play with the walkmeshes somewhat and add Door Nodes in the relevant places... and raise their height to match the Tileset's base height if necessary. For this you will need strong card, scissors, glue and A BIG BRICK...



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #66 on: November 17, 2015, 09:09:03 pm »


               

I put a little more work into what I'm calling spellfire. I had to actually name the weapon type, so I figured why not? It's a bit closer to looking good. It animates like a whip, clones the hand, forearm, and bicep nodes, backward, so that it flows up to the shoulder. The only problems right now are


  • in GMAX if I go frame to frame it behaves exactly. If I play it forward at any speed it wiggles and jiggles all over the place. I expect it will correct itself if I do a good frame reduction algorithm on it. Right now I had to hard code every single frame to get it to function properly. In game it seems like it is a frame slow, and I don't understand why that would be. It also rotates left when it should rotate up sometimes. This may be an export issue. Must find out.

  • when I create alternates and link them via supermodel back to the original, like they do with whips, it doesn't play. I think this might be an issue with the primary bone name being different. We'll see.

  • When I create the weapon, it is scaled to 100% of the base A_BA animation, but weapon scales are set on the creature entry. This makes it so if you have a character with a scale which does not match the weapon scale, in relation to the A_BA animation series, the arm is too big or too small.

  • It only works on the right hand right now, but I have an idea that I can also make a two handed version that will wrap both arms.

  • When you pause for the time required to start standing differently, including putting your weapon over your shoulder, the animations separate, and it continues to play the A_BA matching animation. I think this is because the animroot for the weapon is the hand node, and the animroot for the arm is either the rootdummy in A_BA or the bicep node in the subanimation for that stance. This is why I hate the stance modifying animations to no end. That and they kill attempts at fully skinned characters, which is why my stance animations are fully fleshed out and bound down to the rootdummy in my custom animations. Annoyance!

Anyway, don't expect spellfire this month. If it makes it, we'll declare a miracle.



               
               

               
            

Legacy_Tarot Redhand

  • Hero Member
  • *****
  • Posts: 4165
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #67 on: November 17, 2015, 09:20:05 pm »


               

Here's to miracles.


 


TR



               
               

               
            

Legacy_OldTimeRadio

  • Hero Member
  • *****
  • Posts: 2307
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #68 on: November 18, 2015, 03:26:56 am »


               

@MerricksDad - That's terrifying.  Seriously.  Sending out good vibes for getting passed those issues.  I'm puzzled, though:  Do you know why it behaves so unexpectedly in GMAX?



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #69 on: November 18, 2015, 04:41:35 am »


               

well I just typed out the entire reason and apparently hit the windows key plus something else and refreshed the page, so I guess screw it.


 


Basically it's quat math errors related to 90 and 180 boundary lines on 3 planes. It makes a mess, and is entirely inefficient for simple object animation. Others will say it is the best system for use with huge quantities of animated objects in a scene, all parented to each other. I say to that: blech.


 


More specifically, there is an infinite amount of space between any two frames, based on the processor speed. When you run the engine in a smooth manner, not frame to frame as you want to see it, there is transition time from a to b. Smooth transition shows you the quirky rotation errors when quat math rotates the wrong direction. Frame to frame transition shows you exactly what you told it to do and how to be. Because both max and nwn animate on curve systems, not frame to frame, you'll see it in both systems.


 


If you get a sec, go in gmax and convert this rotation from eulerangles to a quat, and then back again. It is horrifying.


 


((eulerangles 30 120 40) as quat) as eulerangles

 


output is (eulerAngles -150 60 -140)


 


The math inside the conversion is also lossy even when the output whole numbers is the same. Furthermore, even if you get the same output, if you ask it separately if the x, y, or z values match those of the input value, it will tell you most often that they are not, even though the variation is 6 or more digits below 0, and the printable output is in a whole number format. Basically 30 read as 30 is not 30, and it has no way to tell you that.



 



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #70 on: November 18, 2015, 05:09:10 am »


               

Granted the above is a horrible example of numbers to convert, because normally when you convert a vector in 3-space to a rotation, you only need two numbers maximum. You can accomplish the entire thing with only two parts of the eulerangle mix, entirely omitting the final rotation around the Z axis. Anybody who has played with a flight simulator knows that won't work though, or you can never roll, and you certainly cannot make any turns in that state.



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #71 on: November 18, 2015, 09:01:05 pm »


               

Here you can see the three bones which make up the spellfire arm sheath. In most of the animations they play just fine. I found out that the majority of the rotational mess up was due to how nwmax exports rotated objects. Still related to quat math, but the major issue was that the bones were rotated before animation frames began, which caused an offset equal to the values of each bone's rotation offset in relation to frame 0. Once I modified how the chain was set up, by baking the original rotation into the subsequent frames, and at the same time removing the original rotation, they play without as much jerking around. A great majority of the quat math error was then cleared up, but still, not all of it.


 


lM4C64a.png


 


The major difficulty with this is in how animations are transitioned, and especially with those which are animroot-ed NOT to rootdummy, but to another body part. For instance, I mentioned yesterday about the arm subanimations for stances. If you have ever slow walked a character across a map by putting your mouse pointer in front of his foot, and then clicking to move, you will see the arms often move at 100% swing speed, while the legs move at some tiny fraction, like he's sneaking... yet at the same time doing the robot. This is really bad, and is a major reason why subanimations need to be done away with in the A_BA cycle list.


 


Like with skinned PC's, any time the engine calls on a stance/subanimation which has a different animroot, the transition times between the two portions of the model can go out of sync, including having your character's arms continue to swing while standing still. He really really likes to do the robot. This out of sync when viewed on the spellfire arm sheath is just as annoying, especially if the arm sheath keeps moving while you are doing something else.


 


The only way I have found to remove this issue is to reconstruct the A_BA cycle list and clone all leg movement animations to the similar waist-up animations. I've also found that by changing weapon types in the baseitems.2da, you can remove the over-the-shoulder stance for larger weapons, and that such was a requirement for this spellfire arm sheath.


 


So far, I'm testing this as a bow with some success. Initially I wanted it to shoot a projectile, or to have an alternate close combat burning hands spell look to it. As a bow, no matter what ammo type I give it, the item self-destructs on first use. I've even modified ammotypes and iprp ammotypes files to create additional ammo references so that it doesn't just shoot arrows and stones. I also tried giving it the unlimited ammo property with both old and new ammo types associated. Neither works to cure the self-destruct.


 


As a short sword, I can set the preferred attack range to a high number, however, any time I step back past 2m, the character will stop attacking, chase the target, and then start attacking again, as if he DOES NOT actually prefer 30m. He'll then start backstepping during combat rounds until he reaches 2m, rinse and repeat.


 


Setting the preferred attack distance under 2m, as are all physical combat weapons, keeps him in position as expected for close combat attack. Using the realist hands hack makes it look like he really is tossing a spell at people. However, since the sword weapon type is not ranged, no projectile comes out.


 


This all leads me to believe that I have to take a different approach. One idea is to equip the spellfire arm sheath as a wand, and then associate both long range and short range spells to it as click-to-fire attacks. In my unreleased 4E mod, I did this for the unlimited use magic missile all wizards can use from their chosen focus item. That kind of takes the 2da tinkering fun out of it.


 


The other idea is to keep the spellfire associated as a melee weapon, only allow it to lash out like burning hands, or some kind of spray shaped whip by using emitters, and then associate some click-to-cast spell properties on top of that for long range combat.


 


Examining the whip and flail systems in OC weapons, I see they didn't bother doing any animation cycles but the combat ones. That doesn't work for the arm sheath because I need the shape to conform to the body during all frames in which the weapon is visible. Strangely enough, that is every frame but casting frames, as during those frames, the object held in the hand is made invisible, or simply not drawn. What a bummer that was when I was unable to find a fix for that while making custom casting graphics.


 


To properly animate the arm sheath, I need to either 1) not use my custom animation cycles which come from my skinned PC's, and instead model the arm sheath directly off of the OC animations which are often based not at the rootdummy, or 2) not bother with releasing spellfire as a weapon for use with OC characters.


 


I originally built this structure and the functions which power it for the Jennica character I fear most of you will never actually see in a module. As the story goes, she lost an arm while fighting a beholder at level 1. She died by being turned to stone, but was brought back later, but only AFTER a gnome reshaped her a stone arm to replace the one he thought she lost by having it broken off by vandals (not exactly the case). The new arm was never quite right to her, and being a paladin of the gods of magic, she looked into alternative hands, many of which turned out to be pretty much magical Stark-tech. This is why I needed arm-sheath skins as equipable items in the hand slots. One of the hands functions as a wand. The other has a big ass sword attached to it with some mechanical action. Since she has a stump at the elbow most of the time, she doesn't have much in place of the hand and forearm models, but I cannot animate those at all, so I animate the weapon instead. Since my specific characters are entirely skinned (multiple skins), and don't use most of the stance-like subanimations, I don't have these animation transition problems with them.



               
               

               
            

Legacy_OldTimeRadio

  • Hero Member
  • *****
  • Posts: 2307
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #72 on: November 18, 2015, 10:44:23 pm »


               


Here you can see the three bones which make up the spellfire arm sheath. In most of the animations they play just fine. I found out that the majority of the rotational mess up was due to how nwmax exports rotated objects. Still related to quat math, but the major issue was that the bones were rotated before animation frames began, which caused an offset equal to the values of each bone's rotation offset in relation to frame 0. Once I modified how the chain was set up, by baking the original rotation into the subsequent frames, and at the same time removing the original rotation, they play without as much jerking around. A great majority of the quat math error was then cleared up, but still, not all of it.




That sucks.  You can always get rid of every last bit of those extraneous rotations by selecting all the geometry involved, applying a real Reset XForm (not the thing in NWMax) and then going to each piece of the geometry and deleting the XForm modifier that gets tossed ontop the modifier stack.  Or, if you have Max, you can just run this MaxScript while all geometry is selected:


 


for obj in selection do

(

ResetXForm obj

deleteModifier obj 1

)


 


And then you get to see the pose it was modeled in, which often times makes way more sense.  By the way, if you're ever cruising through the creature models in NWN (like in NWN Explorer), be sure to mentally make note of the creature models that aren't in a neutral pose and then think about how many times you've seen those particular models modified by the community.  For the most part, people have steered clear of almost all of them except for reskins.


 


Edit: Just to be clear, this has to be done when you first load the model in.  You can supermodel it back into whatever you're working off of, as well. 



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #73 on: November 18, 2015, 11:14:41 pm »


               

I have my own resetxform function which can be told to do children or not. It basically just deletes the transform controller inside the node and then makes a new one, while at the same time retaining the structure of children. I first tried that, but that made everything wrong in the opposite direction. What I had to do is move the rotation from the parent down the child tree, stacking it as I went, and then set the rotation to up the z axis, as is default in gmax, on every node in the tree directly after transferring the rotation. I have to do this a lot.


 


This dumbed-down function assumed only one child per node, so it won't be that useful to most people.


 



   Spoiler
   


 


Just to see how the engine would react, I change my reverse bone cloner (not a sexual act) so that it used only the frame indices which existed on the target it needed to reverse clone. The result in gmax is a mess, as there is a longer visible period between any two frames. In the game, it is exactly the same as my 1-key-per-frame version. At least I know with the current setup, I can do it in a reasonable quantity of frames, reducing the file size from 2.2M to 0.6M. Not that it matters being so small either way. Just interesting to watch how very similar yet different both engines are.



               
               

               
            

Legacy_MerricksDad

  • Hero Member
  • *****
  • Posts: 2105
  • Karma: +0/-0
Custom Content Challenge: November 2015: Wizard's Tower
« Reply #74 on: November 18, 2015, 11:42:07 pm »


               

By the way, if you're ever cruising through the creature models in NWN (like in NWN Explorer), be sure to mentally make note of the creature models that aren't in a neutral pose and then think about how many times you've seen those particular models modified by the community.  For the most part, people have steered clear of almost all of them except for reskins.

 


Edit: Just to be clear, this has to be done when you first load the model in.  You can supermodel it back into whatever you're working off of, as well. 




 I'm remembering what a pain in the arse it was to change EVERY SINGLE key in the entire A_BA list when I changed the underlying pose of the human to a legs-spread T-pose. Not the one I put on the vault where all I did was include a "default" entry for a new T-pose, but one where I had to think about exactly where the rotation was going to have to go. It wasn't fun.