Wall Worm Forums

Design Tools => Wall Worm Model Tools => WWMT Questions => Topic started by: Orvid on October 08, 2014, 04:51:11 PM

Title: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 08, 2014, 04:51:11 PM
I have a model that I'm trying to get imported properly into source, and I believe I have WWMT configured correctly, but every time I try to compile the smd files into mdl files, I get an access violation when studiomdl goes to process the skeleton section. (specifically it's trying to multiply 2 matrix's, but the first matrix is at an invalid point in memory) Because of this, I'm wondering if there is any specific requirements for bones in animated models? I originally had no bones and had the pieces animated via basic transforms, but then, after I figured out where studiomdl didn't like in the smd, I tried adding a couple of bones and skinning the entire model to be attached to them, but it still gives me the same error at the same part. Any suggestions?
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 08, 2014, 05:09:10 PM
I guess the first question is whether you are using WWMT to create the QC or if you are creating it? I know this error can happen if you use $massorigin and $collisionjoints in the QC.

Post the contents of the QC here.

[EDIT] Sorry I was distracted and did not answer your actual question. There are not many requirements for the bones except I'd make sure that you never Scale them. In fact, I'd not scale the meshes either. The only way for me to answer definitively about model problems is to open the files. You can always send me a Max file via my email listed in the WW Zip readme file.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 08, 2014, 08:14:27 PM
Well that would probably be why, as part of my animation scales the meshes to 0 (I have it set to do the change in 1 frame, so there's no frames with a scale in-between 0 and 1) to get rid of them without clipping. Any idea how I could this without the scaling?

As an extra suggestion, I was looking at the generated SMDs and noticed the large number of extra decimals that aren't needed, so I looked at source for wallwormSMD.ms, and noticed that you're using the f format specifier, which forces all decimals, including trailing zeros, to be output up to the specified precision (6 and 12 depending on where). If you change that to a g specifier, it won't output those trailing zeros, and, in my case the change cut the smd size by over half.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 08, 2014, 09:05:48 PM
I don't recall the origin of the "f" format. I believe there was some bug a couple years ago that was alleviated by using it in one of the exporters. I'll test some of my files and see if switching back to g is fine in all the files I have.

In terms of the scaling... the problem is that SMDs do not contain scale information for the mesh or bones. There is no way to export the animated scales with SMD.

Some mods (like TF2) have a scale property in prop entities. But the scale is handled by the entity and I/O in the level and not in the MDL itself.

Another option is to look as using Flex animations, but this is probably not the most viable option.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 08, 2014, 09:35:39 PM
I also was looking into the performance of the exporter, due to it taking nearly 5 minutes to export the model and it's 152 frame animation, and noticed that you're appending to a string rather than a StringStream, is there any particular reason for this? (a string has to be entirely re-allocated and copied every time you append to it, a string stream doesn't have to for most append operations) I'll send you the model via email for testing in a bit.

Also, the QC I'm using is the one generated by WWMT, I haven't modified it at all.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 09, 2014, 12:12:06 AM
So I looked at this model and I think that the problem is that it isn't practical as a single asset for multiple reasons.

There is a hard-coded bone limit in the compilers of 128 bones. Each node exports as a bone. I guess this is a limitation I should have mentioned earlier. I also see why it is so slow to export ... the Skin modifier automatically slows down the exporter significantly. When I removed the skin modifier, it exported and compiled in around 10 seconds. Pretty much you should never use a Skin modifier for mechanical rigs unless it is necessary--and a Skin without any bones in it doesn't actually do anything (except slow things down at export time).

Anyway, I did get the model to export with the animation when I reduced it to one layer thick and removed the edge bricks so that the bone count dropped below 128. But the model still has a couple unexpected quirks that I don't have time to investigate right now.

At this point, the best resource for making a mechanical animation might be this video:
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 09, 2014, 08:17:42 PM
Awesome I now have it exporting properly, perhaps it would be a good idea to add warnings / errors to the SMD exporter if it encounters too many bones, or else encounters a case where a bone is being scaled?


Also, I did end up getting the model to do what I wanted in terms of hiding certain pieces to avoid clipping issues by simply moving the parts of it that I had been scaling to nothing to a place where they would never be visible to the user instead. (The model is a door that only opens at the start of a round, after which I remove the entity from the map, so I don't have to worry about it still being rendered.)

The problem with the bone count was that, as I was unaware of the limit, I hadn't combined various parts of the model that could easily have used the exact same bone, and had almost 500 bones. After combining various parts of the model into single objects, I was able to get it down to 96 objects, without having to change the animation or deleting any of the visual parts.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 09, 2014, 08:31:42 PM
I'm glad you've got it working. Share a screen shot/video for the users when you've got some time. I wish more users would start doing that :)

Regarding a notice about scale/bone count, it's something I can look into. I've got several error checking TODOs for users, but since it's hard to tell how many people bother to take notice of those that I do have or take the time to understand them before sending my irate emails about them... it sometimes seems like wasted effort. But I will add them both to printed notices or into the general WW function for Check for Problems in the scene. There is a very large update to the general structure of WW coming in a week or so, and maybe I'll have time to add these in for that.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 11, 2014, 04:32:12 PM
Well, I have it mostly worked out, but am having minor problems when I go to try to do the animating of the collision model. Due to the way the model functions, I can't simply attach a collision model to one of the existing objects in the model, so I instead created a pair of bones that I skinned to the collision model. I then am able to effectively resize the collision model by moving one bone towards the other, which works fine in 3ds max. However, after adding the bones that I animated into the model being exported, the collision mesh doesn't resize, and instead actually spins with the final brick that's being moved.

Any idea why this would be? I suspect I'm missing something about how bones are dealt with in source, but can't seem to figure out what exactly that is.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 11, 2014, 07:44:20 PM
The collision hull will only use bones that are in your main model. So your best method is to skin each convex object of your hull to a specific node in your main model. The fastest way to do this is to remove the skin on the hulls now. Then select all the hulls (keeping them all separate object but select all at once) and click the Add Skin to Selection button in the Hull Helper floater (Wall Worm > Wall Worm Model Tools > Hull Helper). Then for each individual hull, skin it to one and only one object from the original model (each convex part of the hull must be weighted 100% to a single bone... which is why this method is used as it is fasted to setup).

Hopefully this answer the question. I believe the video above demonstrates the skinning of hulls to the original mesh nodes, though it may have been before I added the Add Skin to Selection in Hull Helper.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 12, 2014, 02:43:20 PM
I suspect you've missed something about my last post. Due to the way the model is made, I can't simply attach my collision model to existing parts of the mesh. Because of this, I instead added a pair of bones to the base model, but didn't skin the base model, and skinned the collision model to those bones. The collision model should be scaling down due to the distance between the bones getting smaller, but that isn't the case once I export it. In fact, the collision model moves with the final block that opens instead of the bones.

Edit:
After a bit more checking, the bones I added are making it into the smd, but are being eliminated from the .mdl, causing the collision model to use the first remaining bone to be used instead...

Edit 2:
Well, I was able to get it working by converting the bones I had into editable meshes. I also removed all but one tri from those meshes, as they will never actually be seen to begin with. Now I just have to figure out why the collision mesh is the wrong size. (It's 1.5 bricks wide in HLMV, but 2.75 in 3ds max) It also appears that the bone's initial position relative to the origin of the collision model isn't taken into account when exporting, although that might just be a symptom of the odd scale.

Edit 3:
Fixed the scale oddity, now to figure out the transform issue.

Edit 4:
I did finally get it working, but, for it to work properly the collision hull's origins have to be at (0, 0, 0).... Not entirely sure why this has to be the case, but, if I get the origin at (0, 0, 0), the animation works like it should. In order to get the origin to (0, 0, 0) I have to first transform the origin only of the object to (0, 0, 0), then I have to compile the SMDs, which will cause the object's model to move to where it appears in the compiled .mdl file. Once it's in this position, I reset the pivot, then I transform the object only to be in the position I want it, and finally reset the pivot again, which should result in the pivot being at (0, 0, 0). At that point the animation works like it should.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 12, 2014, 07:56:14 PM
Ahh... I guess I did misunderstand. It's been a long week and my brain is pretty sluggish at the moment. Which also explains why I'm not entirely following the last edited section explaining how you got it working. It seems overly complex. Although I do not completely understand it, my best guess is that one or more nodes were scaled or had offset transformations. Just in case, I'd read this article: My Model Scale is Wrong (http://dev.wallworm.com/document/127/my_model_scale_is_wrong.html).

You might eliminate the offsets by turning on the Use Local Origin As World Origin in WWMT as well as the Calculate Origin in SMD option. Not sure, as it is dependent on exactly what is going on. For animated models, you usually want to keep Rotate Origin off.

Another thing to keep in mind is that once an object is Skinned, you'll often get unexpected results if you then transform the skinned meshes. If you've already skinned an object but need to transform a mesh, you can save your skin weight settings in the advanced rollout of the skin into an external file, delete the skin, then transform the mesh, then reapply a skin and load the saved weights.

Also, for future reference, if you want to use geometry nodes as bones but do not want their geometry to export, you can Right-Click the node, click Object Properties and uncheck the Renderable checkbox. So long as the global WW setting for Export Non-Renderable Mesh as Bone is turned on, the node's geometry will be skipped in the SMD. But keep in mind that this can conflict with another global WW setting called Processed Hulls become Non-Renderable. These two options should not be used simultaneously, and if you turn on the Export Non-Renderable Mesh as Bone option, you may have to manually make your hull nodes renderable if the other setting was on.

Hopefully these tips help.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 13, 2014, 08:34:00 PM
Alright, the issue with the position and rotation of the physics meshes is now fully resolved, but when I put the model on a map, then compile and run the map, the console complains about `Invalid initial position` on the model, and then proceeds to crash once the opening animation finishes. The vphysics also don't seem to be working at all, even though they are exported correctly and show up animated correctly in the model viewer.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 13, 2014, 09:30:29 PM
I've never seen that error before. You may have to send me the current state of your scene. Use the File > Save As... Archive function as it will collect any needed asset.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 14, 2014, 11:01:58 PM
I received the file you sent and looked into it. I never got any error or crashed as mentioned above but see the offset you mentioned in the email when exporting the level.

The reason the model is offset is because, for simplicity, WW exports a prop's position in a WWMT helper based off of the transformation of the model's "root node". In this model's case, it is the node $Editable_Mesh:Box139 @ [-176.000000,8.000010,184.000000] which has a transform of (matrix3 [-1,3.89414e-007,0] [-3.89414e-007,-1,0] [0,0,1] [-176,8.00001,184]) . That becomes the point where the model will export to in the VMF.

In reality, the VMF exporter should check that you are not using Local Origin and manually calculate the offset. But that doesn't happen right now (and adding that adds one more layer of calculations and possibly slow the VMF Exporter...)

You have a few solutions in order of what I recommend (the last would be too much work).

* Recommended: Turn on the Use Local Origin as World Origin and re-export the model.

* Add a new Bone to pos [0,0,0] and add that to the WWMT helper as you would a mesh. Then, with the WWMT UI open, open the Wall Worm > Wall Worm Model Tools > Bone Tools floater, select that new bone, then click the Root Bone button (which rearranges the node list and will assign the bone as the new root node). Then re-export the model.

* Move the current root node's pivot to [0,0,0], use Reset XForm on the node, then reanimate it. Then re-export the model.




Generally speaking, when building props in 3ds Max to be exported with the WW VMF Exporter, I recommend using the Local Origin as World Origin (which might be renamed to Pivot as Origin at some point to make more sense from a Max perspective). That, or make sure that the root node's pivot is aligned to the world origin.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 14, 2014, 11:53:02 PM
I'm using the model exporter, not the vmf exporter. I'm using the most up-to-date version of TF2 to compile the model. I do know for a fact that the scene has a rather larger number of -0 points, which, while a valid floating point value, doesn't make much sense in a scene. Is it possible that these are the cause of the error in the console in TF2?
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 15, 2014, 01:36:14 AM
So I misread you again :) The email title was Invalid Object Position and when I exported the scene the issue I saw was the offset, so my laziness let me be confused.

The update that I just loaded (WW version 2.31) now truncates the SMD values again with the g format as discussed earlier. It doesn't seem to affect the results. I don't think that the floating values are part of the problem. I exported several other animated props as tests this evening with similar kinds of values without incident.

The animation seemed to play correctly in CS:GO. I did not get the error you mentioned, but I did get this message in console:

QuoteUncached query for bone (1) transform. Please verify that there is an attachment or bounding box associated with this bone.

That message was printed many times.

I'm not confident about the cause at this point. I've never seen that message before. A brief search on Google shows that other people have discussed it but I didn't find any useful input on it. I'm not sure what is unique about the model. The only thing you've done in it that I avoid is using the Group function (grouping nodes together). I did add support for grouped objects, but it's something I generally avoid.

I'm not seeing anything that sticks out that is bad in the SMD.

It is possible that it is the number of hulls that are animated that is the problem. When WWMT exports a model with animated hulls the QC gets the $collisionjoints (https://developer.valvesoftware.com/wiki/$collisionjoints) parameter. According to the VDC, the limit for simulated hull bones is 32 in the current Source. But it also says the limit for Animated Models (which this is) is unknown. For animated models, $collisionjoints is a requirement.

My gut tells me that the hull count is related to this problem.

You may want to check that the global WW setting has the Match $maxconvexpieces to Hull Count option turned on, as it could play a roll in how the compiler handles the hulls.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 15, 2014, 07:31:52 PM
I was compiling with the $maxconvexpieces option disabled, I've now enabled it, and at least *think* I've been able to run the map without crashing TF2, but, as I can't actually see the fullscreen game via remote desktop, I can't be certain. I'll also update my installation of WW before trying again when I get home and can actually see the screen.

I did notice one odd thing about the scene, I have 16 collision bodies that I created, but WW counts 17 hulls, and only the 16 objects I created get selected when I tell WW to select the objects in the collision hull. Could this phantom hull be the cause of the error?

There is also something a bit odd about L1-Right-CM1, the primary collision model for the first layer of the right side of the door, inside 3ds Max it doesn't actually move as you navigate the timeline, but it does export as being properly animated. (as shown in the model viewer) Could this be a symptom of the cause of the problem?

Edit:
Well, with $maxconvexpieces set with a model compiled with the previous version of WW, I didn't get any errors in-game, and the collision model shows up correctly in the model viewer, but the collision model in-game was nowhere near correct. It was roughly a 32x64x192 unit block in the center of the model that didn't move at all. I will try with the newest version of WW, but I don't think that will make a real difference. I'll also note that the model was compiled with not the latest TF2 update originally, will compile it with the updated TF2 as well now.

Edit 2:
Well, recompiled with the current updated tools doesn't change anything. It did however make me realize that the broken in-game physics for the model isn't the only physics that get messed up by having the model on the map, in TF2 throwing a cleaver or hitting a ball into map geometry normally causes the ball or cleaver to just bounce off, but, if a map is compiled with that model in it, the cleaver or ball will simply go right through. The environment is still solid to the player and to bullets, but projectile weapons just go right on through.

Edit 3:
The same error is back, and I've just sent you an email with the .max, compiled model, materials, .smd's, and the map compiled for TF2 (I don't believe the model is currently embedded in the map).
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 16, 2014, 12:25:45 AM
I will try to look at your files tomorrow as I just got back in.

The hull count of 17 while there are only 16 objects is normal because there is no 1-to-1 relationship. A hull is defined as a convex element of an object. That means you can have one object that is composed of 20 hulls, for example. So if you expect only 16 hulls, then it probably means that one of the objects is composed of two elements.

As for the hull not moving in Max. Honestly, I have no idea what is causing that. All the vertices are weighted fully to your animated bone... so it should follow. But regardless of that, the exported hull moves because it's exporting how it should. There could be something odd going on, certainly.

My best advice as this moment is to break it down into a simpler model (maybe just 1 row on one side for now) and get it working at a simpler level. Then you work it up to a more complex rig. And I advise that you avoid using Groups for now, especially while building it up. One problem with using a Group is that you cannot as easily visualize/traverse relationships in the scene without opening the schematic view. I would only apply a group to those systems you are certain about working.

In any event, I'll give it some more thought tomorrow when I get a free minute.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 16, 2014, 09:37:53 PM
I think something may be up with the hull count button, because there are no poly's that are un-accounted for in the objects, and there are only 16 objects in the exported hull SMD.

I also noticed that the bones make it into the SMD for the collision mesh, but nothing is parented to them, should they even be there at all?

Lastly, how exactly is HLMV determining that the collision model's parents are the bones? Because that's not specified anywhere in the SMDs, yet it still works for some reason.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 16, 2014, 11:43:55 PM
The hull count function is working correctly as long as the hull list is made of unique nodes. It appears that the same node was added to the hull list more than once and the WW functions were not set to sanitize the list (removing duplicates). I'll update the code to fix this.

If you select the WWMT helper and type this into the MAXScript listener:

for obj in $.hulls do print obj.name

You'll see that L1-Left-CM2 is listed twice.

I'll push a fix for this on the weekend so that cannot happen.

To clean the WWMT data now, select the WWMT Helper and type this into the listener:

$.hulls = makeUniqueArray ($.hulls as array)
Then type:
$.getWWMT refresh:true

Now close WWMT and reopen it and look at the hull count.

Regarding the bones in the SMD files. All nodes will export as a node in the SMD. This is for both geometry nodes and bone nodes. The SMD exporter does not know what the intended usage of the bones/nodes are. So it cannot just delete the node simply because it isn't weighted in the current SMD. For example, the node/bone might be used for attaching other geometry based on the QC setup, etc.

But that isn't a worry. In terms of the actual compiled model, those bones that were not used at all were thrown away. If you look at the bones in HLMV in the Bones tab, you'll see that only the actual bones exist. And to my knowledge, the hull model can only utilize bones that were defined in the reference model; this may be why the hull nodes never appear.

The bones are animated properly because each is weighted 100% to a specific bone. This information is contained in the vertex data of the SMD (in the triangles).
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 18, 2014, 05:04:52 PM
Well, more information about the collision model issue; Enabling collision model drawing in hammer does show the collision model as it is in-game. It appears that only 1 of the collision meshes is actually getting loaded, and it's rotated 90 degrees and the center of it is at the origin of the model. Is there anything you know that the engine does differently in a map setting when dealing with vphysics of models vs. when working with them in HLMV?
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 19, 2014, 12:36:42 PM
Yes, I see the error with this model.

I'm doing some test right now to see if I can figure out what is causing this issue specifically. I think that the issue if related to either the XForm of a node, the number of bones, or some other related issue. In any event, I'm trying to reproduce the error in a fresh model with less components to see what can cause this. I'm starting with a smaller system because it will be easier to find issues.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 19, 2014, 03:37:47 PM
During the tests, I found some circumstances that can cause some models to have incorrect offsets for geometry or bone orientations. This may very well play a role in this case. So I'm working on a fix for this issue in the SMD Exporter.

That being said, I see that the collision hull displayed in Hammer does not always match that in game if the model is animated with a concave hull with elements weighted to bones. It appears that Hammer often displays only one element in this case, though in-game it displays correctly with wireframe on. (This isn't to say that your issue isn't happening, just that you cannot trust the Hammer CM display as I've discovered in several tests today).

I'll post info on the current fix I'm working on when it's ready to test.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 22, 2014, 06:50:41 PM
While working on a rewrite of the SMD exporter in C#, as a way of boosting the speed of the exporter for skinned materials (no idea if it will actually be faster or not, might actually be slower, we'll see), I was porting wallworm_getMaterialName in common\matfuncs1.ms, and, in the code working with XRef materials, I noticed that on line 574 you check if "r" is not undefined, yet on line 577 you proceed to use "r", even though it's the else case, and you've already proven that "r" is undefined.

I believe you intended for it to be "m.name" rather than "r.name" on line 577 of common\matfuncs1.ms.

Also, is there a better place I should be posting this rather than in this topic?


Edit:
I'd also look at common\matfuncs1.ms line 538, because the checks that it does there, all but one of them anyways, will only ever have one result, due to the code before it.

Edit 2:
Line 643 of common\matfuncs1.ms should be returning undefined, not "unknown". This looks to be just a copy/paste error.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 23, 2014, 01:45:05 AM
Ah yes... some of those lines are copy pasta or relics of older versions that get covered in layers and layers of changes over years. The r undefined is funny; I guess I've never run across an XRef material that was undefined reached that error. Yeah I think that another thread id probably in order for code-related things. I'll add another board for that purpose tomorrow. Feel free to just email me too.

In terms of the problems listed above, there are even more updates in the WW Dev link (http://www.wallworm.com/projects/utilities/dev_wallworm_model_tools.zip) that should alleviate all the offset and orientation problems in about as many circumstances as I could think of testing. I have to do more tests before it's official, though. And I have too much work the rest of the week to test much more until the weekend. But feel free to test it.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on October 27, 2014, 02:02:29 PM
For those who find this in the future, the last of my problems was caused by source not being able to generate hitboxes for the single-tri objects that I was using as bones. Changing those single-tri objects into boxes solved my problem.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on October 27, 2014, 02:22:18 PM
Thanks for finding the reason for this.

Now that we know, an even better solution is to not even use geometry nodes for them. Instead, use Bone geometry objects because their geometry is not exported at all--just the bone node transformations and hierarchy. In the case, skin the geometry to the bones and not geometry.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: Orvid on November 01, 2014, 07:37:46 PM
And when you do so, if you use the "Export Non-Renderable as Bone" option, make sure that your collision hulls aren't set to be non-renderable.
Title: Re: EXCEPTION_ACCESS_VIOLATION when compiling model
Post by: wallworm on November 01, 2014, 07:51:18 PM
Quote from: Orvid on November 01, 2014, 07:37:46 PM
And when you do so, if you use the "Export Non-Renderable as Bone" option, make sure that your collision hulls aren't set to be non-renderable.

Thank you for sharing this advice. I added this option early in WW development when I was collaborating with Wunderboy on a version of his exporter because I wanted to use CAT rigs. And although it serves the purpose well, I have learned that almost no WW users takes the time to understand this feature nor the global settings that effect it. :/