MDLedit bug reporting thread

[JCarter426 1,220]

I got a little MDLEdit bug. Or maybe I'm doing something wrong again. I've done everything that should work but no matter what, the smoothing won't apply correctly on this model.

Original model:

Edited model compiled with MDLEdit:

Model in 3ds Max with KOTORMax showing the correct smoothing:

I've tried all manner of things. Redid the smoothing groups to ensure they're correct, messed around with the vertices and UVW maps to make sure the parts that are supposed to be connecting are, and I even merged the cape and torso meshes and welded vertices... that still didn't fix it, and it probably wouldn't be a realistic solution even if it had. I also tried the other smoothing options in MDLEdit but didn't notice any change. ASCII attached.

PMBIM-kotormax_v14.mdl.ascii

[DarthParametric 3,794]

Yes, I don't believe either MDLEdit or MDLOps are correctly smoothing across meshes. I have previously raised the issue with @bead-v, so fixing it is on the to-do list. It probably also requires changes to KOTORMax. The specific issue is down to non-unified vertex normals at the seams. The compiler is generating two separate normals for every pair of vertices, instead of a single averaged normal, as Bioware's compiler must have done.

[JCarter426 1,220]

The thing is I've had very good smoothing results before and I thought some of them were on different meshes. Ah, well... the issues I've fixed are probably worse than the ones I've caused...

[DarthParametric 3,794]

There is supposed to be provision to smooth across meshes when using shared smoothing group IDs, but I have never seen it work, and I had @bead-v confirm that is not working as intended. I guess it is possible there may be some edges cases where it does work, but I have never encountered them personally.

[ndix UR 218]

Yeah, we put quite a lot of work into that feature, but it's still not perfect.

For example, using mdlops, decompiling PFBIM gives you unmatched smoothgroup numbers between torso_Geo and robe_Geo, so recompiling it, you get a result like the screenshots posted. However, compiling the PFBIM that JC posted doesn't show this issue (it has some weird UV stuff happening around the collar and gloves though). I'm a little surprised MDLEdit has an issue with it... I did notice that some of the vertices aren't actually lined up perfectly along the joint between those meshes (in the vanilla model), so possibly bead-v's precision is the issue. I can't quite recall, but I thought we were both using 4 decimal place precision on that... actually, I dug into the code a bit, and fDiff for vector comparison in this context might be 5 decimal places for MDLEdit. That would explain the error nicely because I saw variance in global vert positions at the 5 decimal place level, but not 4.

If you need it to work in MDLEdit, you might get more precise matches by putting the robe and torso origins at the same point? Just spitballing...

This particular concept of smoothgroups is a 3DSMax-ism. I go back and forth between whether to just bypass them or implement the whole smoothgroup system into Blender, but as of now it's pretty impractical for me to work with them so it's not something I've been able (or motivated enough) to really fix.

[DarthParametric 3,794]

I think bead-v was thinking of using an Edit Normals modifier in Max and taking the normal data from that, which presumably would drop the use of smoothing groups (outside of legacy support I guess). I'm not sure what the Blender equivalent would be, but I guess it would take some work to keep both MDLEdit and MDLOps cross-compatible with whatever additional data from either Max or Blender that might be added to an ASCII.

[JCarter426 1,220]

3 hours ago, DarthParametric said:

There is supposed to be provision to smooth across meshes when using shared smoothing group IDs, but I have never seen it work, and I had @bead-v confirm that is not working as intended. I guess it is possible there may be some edges cases where it does work, but I have never encountered them personally.

Yeah, I don't know... I don't recall what models I was working with but I'm fairly certain I've seen it work before. I can't say the smoothing has been perfect but for the most part it has been fairly logical with KOTORMax/MDLEdit, reflecting what I input for the smoothing groups. The only issues that have arisen are when faces are either too close to each other (like each side of a cape) or the angle is too extreme (like the edge of a cube) and both those are cases of getting bad smoothing, not no smoothing. I'll go through my files to see if I have an example of mesh to mesh smoothing, though I'll have to remember what I was working on because I didn't release most of them.

27 minutes ago, ndix UR said:

Yeah, we put quite a lot of work into that feature, but it's still not perfect.

For example, using mdlops, decompiling PFBIM gives you unmatched smoothgroup numbers between torso_Geo and robe_Geo, so recompiling it, you get a result like the screenshots posted. However, compiling the PFBIM that JC posted doesn't show this issue

Yeah, they were definitely messed up just on import alone. I set them to what I thought would make sense - 1 for the hands and other accessories, 2 for the torso, 3 for the main cape and 4 for the other side of it. Just going by the smoothing groups alone that should be right and the smoothing preview is showing it as it's meant to be.

27 minutes ago, ndix UR said:

it has some weird UV stuff happening around the collar and gloves though

No, that's normal. I redid the mapping there and actually the hands are from another model now. It's no longer mapped to the original textures, but that whole part is working fine (you just don't have the texture).

27 minutes ago, ndix UR said:

I did notice that some of the vertices aren't actually lined up perfectly along the joint between those meshes (in the vanilla model), so possibly bead-v's precision is the issue. I can't quite recall, but I thought we were both using 4 decimal place precision on that... actually, I dug into the code a bit, and fDiff for vector comparison in this context might be 5 decimal places for MDLEdit. That would explain the error nicely because I saw variance in global vert positions at the 5 decimal place level, but not 4.

I went around with the snap toggle on and moved all the cape vertices to the same coordinates as the robe vertices. That has worked on other models and I thought I had sorted that on this one, though I suppose I can't account for MDLEdit's precision or 3ds rounding errors or whatever.

27 minutes ago, ndix UR said:

If you need it to work in MDLEdit, you might get more precise matches by putting the robe and torso origins at the same point? Just spitballing...

You mean the pivot point? How would I do that without messing up the skin? The littlest thing always breaks it.

[DarthParametric 3,794]

5 hours ago, ndix UR said:

I saw variance in global vert positions at the 5 decimal place level, but not 4

Hrm, I wonder if this is the source of some visible geometry gaps I was getting from snapped verts. I might have to run some MDLEdit vs MDLOps comparisons. It seems like 5+ sig figure vert co-ords are present in KOTORMax-generated ASCIIs as well. Although to be fair to bead-v, I gather this is just straight from Max. I wonder how accurate the snap tool is? Maybe I should try using a vert co-ord copy/paste script.

5 hours ago, JCarter426 said:

You mean the pivot point? How would I do that without messing up the skin? The littlest thing always breaks it. 

I doubt that will make any difference, but if you want to try it then use  Affect Pivot Only in the Hierarchy tab. For matching the pivot of another object, my preferred approach is to make the target mesh a temporary child of the mesh with the desired pivot, set the reference co-ord system of the Move tool to Parent, hit Affect Pivot Only, zero out the XYZ of the position, then select Reset XForm in the Utilities tab and hit the Reset Selected button. In the Modify tab, drag the XForm modifier underneath the Skin and OdysseyTrimesh modifiers so it is just above the Editable Mesh modifier. Then right click on it and select Collapse To. That will bake your transforms without destroying your skin.

[bead-v 251]

Something in the patch creation algorithm seems to have been causing this. I noticed that when I applied smoothing in kmax, that part between the torso and the cape would get smoothed, so I rewrote the algorithm in mdledit based on how I wrote it for kmax, and according to my preliminary tests, the issue is gone. The new version is attached.

EDIT: @DarthParametric, I also tried recompiling Visas' head, I think that issue is fixed now too.

 

mdledit_v1.0.5b.zip

[bead-v 251]

On 6/9/2018 at 6:56 AM, JCarter426 said:

Oh, yeah, I am. I was actually having other problems with it before and then came here and saw you and bead-v had sorted that part out already and realized I was out of date. But for this, I meant I did click that and recompile it didn't seem to help. But problem solved either way. Plus, so long as it behaves, I can control which keys are bezier and which are linear in the curve editor.

 

On 6/9/2018 at 7:01 AM, DarthParametric said:

Ah, well I guess that is another bug for bead-v to fix in his spare time then. Although I thought there was also something added to KOTORMax to deal with it as well.

Regarding these... it's intended to work this way. Converting bezier controllers to linear is a switch for decompilation, not compilation. If you want to convert bezier controllers to linear, do it in max (the way JC did it) or change your CONTROLLERbezierkey to just CONTROLLERkey in the ascii with find/replace. To me that seems easy enough to do, so I don't think another switch is necessary in mdledit. Or am I wrong?

@JCarter426 , so all the Holocron issues are clear now? Nothing that would require a change in mdledit, if I understand correctly?

There has been a request for an option in mdledit to change the base name without having to convert to ascii (it can't work without recompiling because the new name may be shorter or longer than the old name). Any ideas what that would look like and where I could put it?

It would be great if all bugs and suggestions are submitted in this thread, so I can see everything in one place. I will also start tracking open issues in the first message of the thread (let me know if I miss something).

 

[JCarter426 1,220]

2 hours ago, bead-v said:

Something in the patch creation algorithm seems to have been causing this. I noticed that when I applied smoothing in kmax, that part between the torso and the cape would get smoothed, so I rewrote the algorithm in mdledit based on how I wrote it for kmax, and according to my preliminary tests, the issue is gone. The new version is attached.

It works! Thanks.

4 hours ago, DarthParametric said:

I doubt that will make any difference, but if you want to try it then use  Affect Pivot Only in the Hierarchy tab. For matching the pivot of another object, my preferred approach is to make the target mesh a temporary child of the mesh with the desired pivot, set the reference co-ord system of the Move tool to Parent, hit Affect Pivot Only, zero out the XYZ of the position, then select Reset XForm in the Utilities tab and hit the Reset Selected button. In the Modify tab, drag the XForm modifier underneath the Skin and OdysseyTrimesh modifiers so it is just above the Editable Mesh modifier. Then right click on it and select Collapse To. That will bake your transforms without destroying your skin.

Ah, I don't think it would've helped here either, but sounds useful. Filing this in my brain for future use.

53 minutes ago, bead-v said:

so all the Holocron issues are clear now? Nothing that would require a change in mdledit, if I understand correctly?

All the issues I reported are clear now. I was having some problems with bump maps seemingly not behaving with mesh transparency, but it was annoying me too much so I haven't properly investigated yet. Might not be an MDLEdit thing.

53 minutes ago, bead-v said:

There has been a request for an option in mdledit to change the base name without having to convert to ascii (it can't work without recompiling because the new name may be shorter or longer than the old name). Any ideas what that would look like and where I could put it?

You can't edit it currently? I see it as an editable value under Header, though I haven't tried editing it so maybe that would break it. I'd suggest either there or the root node right above it, which currently, which currently can only collapse or decollapse.

[bead-v 251]

22 minutes ago, JCarter426 said:

You can't edit it currently? I see it as an editable value under Header, though I haven't tried editing it so maybe that would break it. I'd suggest either there or the root node right above it, which currently, which currently can only collapse or decollapse.

Under Header, you can only change the model name, not the name of the first object (the "aurora/odyssey" base). I don't know if that's enough for the game, or whether the mismatch between the model name and the name of the first object would cause problems. Anyway, this way of modifying data is without compilation – it changes only the relevant bytes in the binary, everything else remaining the same. Renaming any object necessitates recompilation, because the length of the name is not set and may affect the size of the binary, which messes up all the offsets, breaking the model. That's why I need to find another way to do it.

[JCarter426 1,220]

What is the "model name", though? Just the file name? It's definitely the base that the game looks at in many cases. For example, let's say you take a head or weapon model and give it new textures, but don't hex edit it to change the base name. If you load up your new head or weapon or whatever it might end up with the wrong textures. If there's an instance of the model you copied present, the game will recognize your new one as an instance of that model because they share the same base name, so your model will have the original's textures. As far as I can tell this is some sort of efficiency thing - the game stores in its memory how it should render a model and it catalogues everything by the base name. You can see the same sort of thing happen if you drop new versions of your MDL/MDX files in Override. The new version of the model won't be rendered until every other instance of it in the game world is replaced, because it's rendering from its old memory. Basically it learns how it should render a specific model and then keeps doing it until told otherwise. And the evidence suggests this is based on the base name and not anything else that might be more logical like the file name.

[bead-v 251]

In the header of the binary mdl file, there is a string that represents the model name. That is probably the name that the game uses for the things you mentioned. But the same name is also used as the name of the first object. This one is stored in the name array which comes after the header. You can open any model in mdledit and you will see this immediately in hex view. So while you only have one name in max (the name of the base), in the binary it appears in two places, once as the model name, and once as the name of the first object. They are always the same.

I can only change the model name without recompiling the model, and not the name of the first object.

So the question is, if I only change the model name, will it work or are there instances where the game references the first object name instead. It's not likely but it's possible.

[bead-v 251]

I had some free time and decided to work a bit on mdledit. It will now calculate the tangent space vectors for all the nodes that don't have them when a binary model is loaded. This means that you'll be able to open a binary model, enable bumpmapping on one of the textures and save it, and it'll work (well, as long as mdledit produces good smoothing group results). Another thing I finally implemented is when you compare a model to the one opened in mdledit, if you highlight some bytes, it will show you the compared-to file's bytes instead, meaning you can compare the values inside mdledit. I also fixed some issues with the GUI in hex view, as well as how mdledit resizes when hex mode is entered and exited. There were some smaller improvements as well.

For anyone who wants to play around with it:

mdledit_v1.0.6b.zip

[xtprojects 13]

Nice bead! Your work is always tops notch as appreciated! Does this fix that issue where certain models wont load like that revan mod link i sent you where it would crash when trying to load it? Thanks so much man! Everything you do is always much appreciated duder!

EDIT** Just tested this new version of mdledit to see if it would work and it wont open at all. It just says "This application has failed to start because the application configuration is incorrect.  Reinstalling the application may fix the problem" I am on xp, is this why?

[bead-v 251]

6 hours ago, xtprojects said:

Nice bead! Your work is always tops notch as appreciated! Does this fix that issue where certain models wont load like that revan mod link i sent you where it would crash when trying to load it? Thanks so much man! Everything you do is always much appreciated duder!

EDIT** Just tested this new version of mdledit to see if it would work and it wont open at all. It just says "This application has failed to start because the application configuration is incorrect.  Reinstalling the application may fix the problem" I am on xp, is this why?

Thanks, xt!

Nope, haven't looked into that issue yet. Next time!

Here's the xp version:

mdledit_v1.0.6b_xp.zip

[JCarter426 1,220]

Well, I'm back. The issue seems to be mesh-to-mesh smoothing again. Here's how it looks in game:

Again, the preview is correct:

I repeated all the smoothing logic that I used on the male model (which is working fine after the update) and I double-checked them all to make sure they did check out. And then I imported my ASCII and it was reading all my smoothing groups correctly. So I don't think it's anything I'm doing wrong.

ASCII attached. By the way, ignore the hands - I know why those are wrong.

PFBIM-kotormax_v4.mdl.ascii

[DarthParametric 3,794]

Seeing as bead-v is adamant it works on his end, there must be something going on in Max that is different in GMax. Maybe PM bead-v your ASCII and see if he can spot any differences in a GMax exported version.

[bead-v 251]

Okay, so I've been banging my head over this and here are the results.

I double checked the algorithms, tried a number of smoothing group configurations, tried changing weights on the relevant verts... while some attempts produced better results than others, I never could get the seam to go away. I may have fixed the algorithm at least a bit though, so you can fetch the latest BETA at the bottom of this post.

So then I looked at the vanilla model. Here's the debug info for the vert in the middle of the back where the seam is (that's actually 4 verts). Their vertex normals do not correspond to any combination of the corresponding face normals.

 

Combined group 999 (-0.00059877, -0.0985711, 1.12031) - 4 patches.
-> Patch 0/3 (torso, vert 46, faces 29 134)
    Looking for normal (5.17641e-008, 0.981964, -0.189069)
    Comparing to base (1.15827e-017, 0.976355, -0.216174).
    Comparing to proposed (1.27222e-017, 0.957565, -0.288217). Included patches: 3
    Comparing to proposed (1.35364e-016, 0.854697, 0.519128). Included patches: 2
    Comparing to proposed (4.6233e-017, 0.984568, -0.175002). Included patches: 2 3
    Comparing to proposed (1.99517e-017, 0.973304, -0.229518). Included patches: 1
    Comparing to proposed (1.79686e-017, 0.960215, -0.279261). Included patches: 1 3
    Comparing to proposed (6.90234e-017, 0.999773, -0.0213115). Included patches: 1 2
    Comparing to proposed (4.16854e-017, 0.979011, -0.203806). Included patches: 1 2 3
 NO MATCH FOUND!
-> Patch 1/3 (torso, vert 429, faces 557 782)
    Looking for normal (3.45158e-008, 0.979264, -0.202591)
    Comparing to base (3.39678e-017, 0.967784, -0.251784).
    Comparing to proposed (2.24171e-017, 0.946416, -0.322951). Included patches: 3
    Comparing to proposed (1.62014e-016, -0.669325, 0.74297). Included patches: 2
    Comparing to proposed (9.20168e-017, 0.983104, -0.183048). Included patches: 2 3
    Comparing to proposed (2.17655e-017, 0.973304, -0.229518). Included patches: 0
    Comparing to proposed (1.91665e-017, 0.960215, -0.279261). Included patches: 0 3
    Comparing to proposed (7.26562e-017, 0.999773, -0.0213115). Included patches: 0 2
    Comparing to proposed (4.34978e-017, 0.979011, -0.203806). Included patches: 0 2 3
 NO MATCH FOUND!
-> Patch 2/3 (robeback, vert 7, faces 3 161)
    Looking for normal (-2.51713e-006, -0.979264, -0.202591)
    Comparing to base (2.77858e-017, -0.907927, 0.419129).
    Comparing to proposed (8.25737e-016, 0.244777, 0.969579). Included patches: 3
    Comparing to proposed (1.62014e-016, -0.669325, 0.74297). Included patches: 1
    Comparing to proposed (9.20168e-017, 0.983104, -0.183048). Included patches: 1 3
    Comparing to proposed (1.35364e-016, 0.854697, 0.519128). Included patches: 0
    Comparing to proposed (4.6233e-017, 0.984568, -0.175002). Included patches: 0 3
    Comparing to proposed (6.90234e-017, 0.999773, -0.0213115). Included patches: 0 1
    Comparing to proposed (4.16854e-017, 0.979011, -0.203806). Included patches: 0 1 3
 NO MATCH FOUND!
-> Patch 3/3 (robeback, vert 68, faces 87 245)
    Looking for normal (-2.51713e-006, -0.979264, -0.202591)
    Comparing to base (1.40057e-017, 0.927753, -0.373195).
    Comparing to proposed (8.25737e-016, 0.244777, 0.969579). Included patches: 2
    Comparing to proposed (2.24171e-017, 0.946416, -0.322951). Included patches: 1
    Comparing to proposed (9.20168e-017, 0.983104, -0.183048). Included patches: 1 2
    Comparing to proposed (1.27222e-017, 0.957565, -0.288217). Included patches: 0
    Comparing to proposed (4.6233e-017, 0.984568, -0.175002). Included patches: 0 2
    Comparing to proposed (1.79686e-017, 0.960215, -0.279261). Included patches: 0 1
    Comparing to proposed (4.16854e-017, 0.979011, -0.203806). Included patches: 0 1 2
 NO MATCH FOUND!
Getting vertex smoothing groups.
  Patch 0 smooths to 0 patches...
  Patch 0 in patch group has no smoothing group, setting it to 1.
  (patch 0 now has 1 smoothing groups)
  Patch 1 smooths to 0 patches...
  Patch 1 in patch group has no smoothing group, setting it to 2.
  (patch 1 now has 1 smoothing groups)
  Patch 2 smooths to 0 patches...
  Patch 2 in patch group has no smoothing group, setting it to 3.
  (patch 2 now has 1 smoothing groups)
  Patch 3 smooths to 0 patches...
  Patch 3 in patch group has no smoothing group, setting it to 4.
  (patch 3 now has 1 smoothing groups)

If we look at the situation from the side, we see this (sorry for the bad drawing – it's just an approximation, though I did try to get the ratio between the normals right). The arrows are vertex normals, the lines are edges ending in the relevant vert. As you can see, the vertex normals of both vertices that belong to the Cape are the same and point outwards away from the body. The vertex normal of the vert that belongs to the lower part of the torso (the part under the cape) is equal to the cape's vertex normal, except it is mirrored along the Y axis and so it points inwards. Also the vertex normal of the vert that belongs to the upper torso (the part not hidden by the cape) points inwards, but at a different angle.

I don't know why this has to be so. Usually when you want smoothing between faces that share a vertex, you make sure the vertex normals in that location are all the same, pointing in the same direction. But if you try to do the same in this situations, you'll get a seam instead. I also can't see how these normals could be automatically calculated from face normals and smoothing groups (if someone can, please enlighten me). So, the only way out that I can see is to enable the export of vertex normals from max into the ascii and then direct import into the binary model. This needs to be discussed, but if we decide to go this way with all the tools, it'll take a while before everything is synced and ready.

mdledit_v1.0.7b.zip

[JCarter426 1,220]

Yikes. So, if I'm understanding this correctly, it's not a tool issue but rather an issue with this model - maybe it wasn't designed as neatly as it could be or maybe it wasn't decompiled correctly, but whatever the case, that does not look like normal normal behavior. If it's a probem on the model then it probably could be fixed but I'm not sure what the best way to go about that would be... unify the normals along the seams maybe? I'm worried about breaking all the skin data, though. I could get it back, but it's a pain to do that.

[DarthParametric 3,794]

Using an Edit Normals modifier at the top of the stack will let you unify normals along seams without affecting the skin. As I have discussed with bead-v before, this was the behaviour of the Dragon Age Origins Max I/O script.

[ndix UR 218]

@bead-v I believe your problem with the vanilla model is that you're not applying an orientation transform to the normals. The torso skin mesh has a super cool 180 degree Z orientation (quat(0, 0, 1, 1.27e6)), so, actually all those torso vertex normals you drew pointing away from the cape vertex normals, all "3" of those normals go in the same outward direction (and two of them match). If not complete slop/oversight it was probably done to workaround a bug in the vanilla toolset's smoothing. I suspect when you fix that (apply orientation translation to normal vectors), the patch-based normal construction is going to work out better. I don't fully comprehend why this would be necessary, other than, interestingly, apparently we need to be doing world coordinate vector comparisons in our smoothgroup computations where we've been doing something more like object space comparisons. When I opened the binary model straight into blender, it looked ... well ... like it does in-game. For the record, I wouldn't consider the smoothing on the vanilla pfbim model something worth emulating/holding up as an example. It's reaaaaal sloppy and horrible. The weights along the torso-robeback interface don't even match, such that you can see gapping in-game when you look from the right angle. Here's a screenshot of the vanilla model hilighting the garbage smoothing between torso and robeback (basically it's OK on the 5 rear seams, but kind of sucks on the side seams)

@JCarter426 if you're tweaking this model, I'd definitely recommend applying the rotation on the torso skin mesh if that's not one of the for-some-reason-sensitive-for-skin-weights-in-3DS operations. If the model you posted in thread already has this done, sorry and nevermind! (I only looked at vanilla while debugging)

[bead-v 251]

@ndix UR Aha! I'll try to implement it tonight. This also means improved SG caluclations Thanks, ndix UR!

The object space : world space comparison bit also explains why it always worked within a single mesh but only sometimes between meshes (when the spaces matched).

Awesome!

[JCarter426 1,220]

11 hours ago, DarthParametric said:

Using an Edit Normals modifier at the top of the stack will let you unify normals along seams without affecting the skin.

Yeah I did try that but I'm always reluctant to because doing that means going out of the KOTOR safe zone of 3ds Max 8 and into a newer version. When I did try it yesterday, the abomination that resulted made me realize late night modeling is a bad idea. Figured I'd wake up to the brainstorming session here instead.

9 hours ago, ndix UR said:

For the record, I wouldn't consider the smoothing on the vanilla pfbim model something worth emulating/holding up as an example. It's reaaaaal sloppy and horrible. The weights along the torso-robeback interface don't even match, such that you can see gapping in-game when you look from the right angle. Here's a screenshot of the vanilla model hilighting the garbage smoothing between torso and robeback (basically it's OK on the 5 rear seams, but kind of sucks on the side seams)

Yeah, I just redid all the smoothing groups from scratch on mine. The male model's wasn't so good either.

9 hours ago, ndix UR said:

The torso skin mesh has a super cool 180 degree Z orientation (quat(0, 0, 1, 1.27e6)), so, actually all those torso vertex normals you drew pointing away from the cape vertex normals, all "3" of those normals go in the same outward direction (and two of them match). If not complete slop/oversight it was probably done to workaround a bug in the vanilla toolset's smoothing.

[...]

if you're tweaking this model, I'd definitely recommend applying the rotation on the torso skin mesh if that's not one of the for-some-reason-sensitive-for-skin-weights-in-3DS operations.

That did work!

Crazy.

So, while it would be super cool if this weird orientation weirdness were sorted out with a tool update, I know how to solve this now so I'm good. Thanks.