Product Chat (Alpha builds) / MAX - Basic Issues with Doors - Help Appreciated

Author
Message
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 21st Nov 2021 20:19
Hello!

I've been doing some basic testing in MAX before getting down to some more serious work in creating a level for a game prototype. I wanted to do something that I thought would be very simple - create a door that slides open. So far, I've not been successful. I'm going to list what I've done and what the results have been and I hope that someone where can help me to resolve my issues. I am certain a good bit of this is my own fault, but some of it may be MAX's? I just don't know, so any help would be appreciated.

My first step was to create a very, very basic door with a sliding open and sliding closed animation and get it into MAX. My modeler of choice is Blender 2.93.6.

I created a basic door and did an Apply All to set the scale, rotation, etc. of the model:



Then I created a simple keyframe animation with three actions - Open, Close, and NoAnim:



This simple animated model was then exported to MAX as an FBX file and named Door_9 (my 9th test with this) and then imported into MAX. In this case, the door comes into MAX with all animations present:



I check off Static Object Mode, set Collision to Box, ensure the animations are named Open, Close, and NoAnim and set NoAnim as the default by clicking it's check circle. Then I import by clicking the Import Object button, make the screen shot, and click to bring it into my empty scene.



After placing a player start position and running the game, I run into my first issue - the player can walk through the door. There is no collision detection. Selecting the door shows that Collision shape is set to Box. Physics is set to Physics on and Show at start of level is checked. So, why does my player walk through the door? Looking at other doors supplied with MAX, they all seem a bit different. Some are "Static Mode" and some are "Physics". Some have "Affected by gravity" as a check box and some do not. Now, my previous imports of my simple door had the "Affected by gravity" check box and this one does not. I have no idea why they sometimes do and sometimes don't. But when they do and that box is checked, the door normally either drops through the ground or falls over and bounces a bit. But in none of the cases does the door block my character.

Guess what? After adding in some of MAX's doors, the Affected by gravity check box suddenly has appeared for my door, too. It wasn't there before. Now my door falls through the grid floor when I run the game ... even if Affected by gravity is unchecked. Nice. Setting Physics to Physics off solves this, but then my player can just walk right through the door anyway.

The good news is the Door behavior works. It will open if "E" is pressed and close, too. But what good is that if I can just walk through it.

So, what am I doing wrong? How do I fix this? If I can import an animated door that will block my player and open with the Door behavior, then I feel I can actually start making something in MAX.

Any help would be appreciated.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
mikeven
10
Years of Service
User Offline
Joined: 31st Dec 2011
Location:
Posted: 21st Nov 2021 20:36 Edited at: 21st Nov 2021 20:37
Hello Argent_Arts,

I'll be glad if my comment could help you.

Collision needs vertices to effectively work.
If you didn't subdivide your mesh in Blender then there are no vertices to collide with inside your door.

Secondly you need to select the parameter "isImmobile" in the "Developer Mode" of the "Objects Tools" then your door will keep its position on the terrain.
Preferably place it on a flat surface ( use the dedicated tool of the terrain modeler for that purpose).

PM
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 21st Nov 2021 20:47 Edited at: 21st Nov 2021 20:48
Quote: "Secondly you need to select the parameter "isImmobile" in the "Developer Mode" of the "Objects Tools" then your door will keep its position on the terrain."


Thank you. That helped (if I wanted Physics on). Even so, my player can still walk through the door.

Quote: "Collision needs vertices to effectively work.
If you didn't subdivide your mesh in Blender then there are no vertices to collide with inside your door."


That simply should not be the case at all. It's not in other game engines. A player's collision hull does not need to encounter vertices in order to collide. It just needs to encounter whatever the collision is - a collision box, etc. It's more of a field. You should be able to have a large cube made of only six faces and still get collision with no issues. You should not have to sub-divide the cube at all. Doing so only adds unnecessary geometry that could potentially slow down the game, especially if you had dozens or hundreds of these objects scattered around your level.

I can bring in the same door, unanimated, as a static model and set the collision type to BOX and it will stop the player perfectly. So, the issue is not the geometry, though I do appreciate you trying to help.

Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 21st Nov 2021 20:56
As evidence, below is a quick video. It shows two models - the white one is the animated door and the red one is a non-animated door. Both have the same amount of geometry (the same number of vertices). The red door blocks the player while the white door does not. The difference is the red door can be set to static, it seems.

Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Agustine
User Offline
Joined: 21st Oct 2021
Location:
Posted: 21st Nov 2021 21:40
I've animated made doors before as fbx embedded with the collision model. both the door and collision have their pivot set at 0,0,0 and only the door is animated. The collision automatically follows the door.... am not sure about GGMAX as I don't have a copy yet, but if you can upload the custom collision made in blender try that... door should not be set to phys but static, you don't want the door to fall or move out of place with phys...
PM
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 21st Nov 2021 21:43
Hi Agustine - Thanks. I don't see how I can upload a collision mesh to MAX ... yet. I've requested this on GitHub. When I imported the animated model into MAX, I checked the Static box. Even so, the model is NOT coming in as static, which is the problem, I suspect. So, this is most likely a MAX issue.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Agustine
User Offline
Joined: 21st Oct 2021
Location:
Posted: 21st Nov 2021 22:05
Hello Argent_Arts, once I get a copy of GGMAX will investigate and post my findings... I hope you resolve the issue soon.... btw, does the door open and close ok in GGMAX?
PM
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 21st Nov 2021 22:36
Yep. It does. The script is looking for an "Open" and a "Close" animation name, so I've named them that way. Once I get close to the door, I get the "Press E to Open" message and pressing "E" opens the door. Pressing "E" again closes it. So, working as it should in that regard.

As far as the collision/static issue - I've reported it on GitHub.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Agustine
User Offline
Joined: 21st Oct 2021
Location:
Posted: 21st Nov 2021 22:41
Hello Argent_Arts, is there a way to see the collision in action while testing ingame? A toggle shortcut key to show collisions so you can see what's happening to the collision..
PM
AmenMoses
GameGuru Master
5
Years of Service
User Offline
Joined: 20th Feb 2016
Location: Portsmouth, England
Posted: 21st Nov 2021 22:53
Animated entities should be set as dynamic not static (otherwise they can't run the script)

A door should also be set issimobile = yes so it stays where you put it.

Collision is controlled by the script, i.e. CollisionOn(e ) when shut and CollisionOff(e) when open.

Been there, done that, got all the T-Shirts!
PM
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 21st Nov 2021 23:00
Quote: "A door should also be set issimobile = yes so it stays where you put it."


I have this and collision set to box and my player passes right through the door.

Quote: "Collision is controlled by the script, i.e. CollisionOn(e ) when shut and CollisionOff(e) when open."


When no behavior is attached to the door (i.e. no script is controlling the door), the player still passes through the door. When the Door behavior is attached to the door, the player still passes through the door.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
AmenMoses
GameGuru Master
5
Years of Service
User Offline
Joined: 20th Feb 2016
Location: Portsmouth, England
Posted: 21st Nov 2021 23:18
What does the collisionmode setting in the .fpe say?
Been there, done that, got all the T-Shirts!
PM
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 21st Nov 2021 23:23
Quote: "What does the collisionmode setting in the .fpe say?"


collisionmode = 0
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
AmenMoses
GameGuru Master
5
Years of Service
User Offline
Joined: 20th Feb 2016
Location: Portsmouth, England
Posted: 21st Nov 2021 23:25
Weird! Sounds like you are doing everything right.
Been there, done that, got all the T-Shirts!
PM
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 21st Nov 2021 23:31
I tried importing the model without ticking the "static" checkbox and I can still walk through the model.

Now, I have three animations with this model - Open, Close, and NoAnim. NoAnim is just the door sitting closed. That shouldn't affect anything, right? Especially since I tested this without any behavior/script attached to it, so it should just function like any other model in the scene.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Agustine
User Offline
Joined: 21st Oct 2021
Location:
Posted: 21st Nov 2021 23:35
Hello Argent_Arts, what are your blender export settings for the door? Did you try welding the verts before export?
PM
AmenMoses
GameGuru Master
5
Years of Service
User Offline
Joined: 20th Feb 2016
Location: Portsmouth, England
Posted: 21st Nov 2021 23:44
Does the door work in Classic?
Been there, done that, got all the T-Shirts!
PM
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 21st Nov 2021 23:50 Edited at: 21st Nov 2021 23:51
Quote: "Did you try welding the verts before export?"


Not sure why I would weld the verts before export. All I did was create a cube and scale it to shape it like a door. Then I applied the scale when done. So, no need to weld any verts.

Quote: "Does the door work in Classic?"


I don't currently have Classic installed.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 21st Nov 2021 23:54
Quote: "Hello Argent_Arts, what are your blender export settings for the door?"


Here are my FBX export settings that I use for GameGuru MAX:

Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 22nd Nov 2021 00:03 Edited at: 22nd Nov 2021 00:36
EDIT - No answer on the Discord yet. Removed last comment as it turned out to not be correct.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 22nd Nov 2021 00:54
Okay! I may have a solution. I will be testing more to see what's what and reporting back here.

I was using Blender Actions (I think they're called) to create and name the door animations. So, I would make one animation from 0 - 30 and name it "Open". Then I would press the New Action button and name that one Close and create another animation where the door closed, again from 0-30. These animations came into MAX and, to MAX's credit, it saw them as Open and Close and had everything set up for me. But, for some reason, the collision was not working when I did this.

I then created a simple animation that went from 0-60 with the door opening from 1-30 and closing from 31-60. When I imported this into MAX, I just created and named two animations channels (open and close). This door had collision and it worked correctly with the Door behavior supplied.

So, it seems that MAX does not like keyframed animations made with Actions, but is fine with them all strung out in a single row.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 22nd Nov 2021 03:14
Okay, this is getting frustrating. I decided to repeat my steps to see if I had a sequence I could follow so I could start making some real doors for a real level. But guess what? The next three test doors I made all came into MAX with NO animations found. None. Zero. Zip. Even though I made all of them the same way as the one that worked correctly. Importing the FBX files back into Blender shows the animations are there. So, it looks to me like there's an issue with the MAX importer.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 22nd Nov 2021 03:44
I've noticed something else, too - even though the animation I've created in Blender is 60 frames long, it comes into MAX as 76 frames long! Why is that? I'll have to look into some of the export settings to see if they alter things in some way ...
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Bored of the Rings
GameGuru Master
16
Years of Service
User Offline
Joined: 25th Feb 2005
Location: UK
Posted: 22nd Nov 2021 07:01
what script are you using ? if it's the same as the GG classic, it doesn't work well. I recall having to use the legacy door version.
Professional Programmer: Languages- SAS (Statistical Analysis Software) , C++ VS2019, SQL, PL-SQL, JavaScript, HTML, Three.js, others
Hardware: ULTRA FAST Quad Core Gaming PC Tower WIFI & 16GB 1TB HDD & Win 10 (x64), Geforce GTX1060(3GB). Dell Mixed Reality VR headset, Aerodrums 3D
PM
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 22nd Nov 2021 07:31
I have found the issue with why sometimes animated models are coming into MAX without animation and sometimes with. I believe it's a bug and I'll report it on GitHub.

If you create a model in Blender and rename it to make sense, MAX will not associate the animation with the new name of the geometry. For example, let's say you create a cube in Blender. By default, Blender will call this Cube. If you look at the list to on the left side of Blender, it's named Cube. But let's say you want to make Cube into a door, so you rename Cube into Door. Then, after you've reshaped it to look like a door, you animate it and export it. Once you import that model into MAX, it will say that it has no animation. Why? Because it will find an animation for Cube, but not one for Door! I can actually bring the model back into Blender and change the name of Door back to Cube, re-export back out and import into MAX and it will suddenly find the animation. And in the animation track in the importer, it will read - Cube|NameOfAnimation (swap out NameOfAnimation with the actual name of the animation).

This is a problem because we may have several parts to an animated model, such as left_side_door, right_side_door, etc. We will want to name models to make sense. But currently the MAX importer is going to be looking for the default names for some reason.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 22nd Nov 2021 07:32
Quote: "what script are you using ? if it's the same as the GG classic, it doesn't work well. I recall having to use the legacy door version."


This is in GameGuru MAX and I am using the Door behavior.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 22nd Nov 2021 08:01
I found the solution:



It's not good enough to just rename the top level Blender gives you when you initially create a piece of geometry, like a cube. You have to twirl down and rename the actual geometry there. Once you do that, MAX will associate the geometry and the animation.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 22nd Nov 2021 09:22
Okay! I've even got Blender animation Actions working in MAX, which means I can NAME all my animations in Blender and they import, already named, into MAX. I'll try to put together a tutorial on this later today ... after I've had some sleep ... (or at least later this week).
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 22nd Nov 2021 09:45
Solved the issue as to why my 60 frame animation was coming into MAX at 76 frames ... I needed to set the FPS in Blender to 30 before export. Now I get a perfect 60 frames in MAX.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
mikeven
10
Years of Service
User Offline
Joined: 31st Dec 2011
Location:
Posted: 22nd Nov 2021 09:50
Argent_Arts, I'm glad to read that your tenacity helped you to find the solution to correctly animate your doors in GG MAX.
About the collision, my conviction about the necessity to subdivide a mesh came from years of practice with clothes simulations (Marvelous Designer). The particle distance played an important role in the collision of clothes with other meshes.

Quote: "I've noticed something else, too - even though the animation I've created in Blender is 60 frames long, it comes into MAX as 76 frames long! Why is that? I'll have to look into some of the export settings to see if they alter things in some way ..."


Here is a screen capture showing the required setting to export your Blender's animations with a FPS compatible with GameGuru :



Have a nice day.



PM
Belidos
3D Media Maker
6
Years of Service
User Offline
Joined: 23rd Nov 2015
Playing: The Game
Posted: 22nd Nov 2021 11:59 Edited at: 22nd Nov 2021 12:06
Quote: "About the collision, my conviction about the necessity to subdivide a mesh came from years of practice with clothes simulations (Marvelous Designer). The particle distance played an important role in the collision of clothes with other meshes."


Collision in Blender, and collision in the game engine are two completely separate things, collision data from Blender does not carry over to GameGuru Max, GameGuru Max uses simple collider shapes (box, sphere, cylinder, concave hull, and polygon), this is assigned by the engine itself and currently we can't add our own, for example a box collider in GGM will be a simple invisible box that conforms to the size of the object, so the number of vertices and quantity of geometry makes no difference as GGM will still create an invisible box around the whole geometry for collision.

Because of the way that collision works in GameGuru Max, the engine cannot move (or animate) an object while it has collision, so how a door script works is the object is placed with a box collision on it, then when you activate the animation it disables the collision while it animates, then when it has completed the animation it re-enables the collision box.

Unless you are good at scripting the only way to open and close a door is via animation (you can do it using quaternians and rotations etc. but that's an AmenMoses level of skill to script), and while most animators can animation multiple object meshes without bones, for GameGuru Max (if it's the same as classic) it is best to include a bone based key framed animation because there are issues with how GameGuru Max detects proximity to an object based on the camera angle and the origin point of the object, this was more prevalent in third person in classic because of the way the camera worked so not such a big issue in Max.
Primary Desktop:
i7 7700,k NV1070 8GB, 16GB 3200mhz memory, 1x 2TB Hybrid, Win10.

Secondary Desktop:
i5 4760k, NV960 2GB, 16GB 2333mhz memory, 1x 2TB Hybrid, Win10.

Primary Laptop:
i5, NV1050 4GB, 8GB memory, 1x 1TB HDD, Win10.

Secondary Laptop:
i3, Intel 4000 series graphics, 6GB memory, 1x 500gb HDD, Win8.1.


mikeven
10
Years of Service
User Offline
Joined: 31st Dec 2011
Location:
Posted: 22nd Nov 2021 13:04
Belidos, thank you very much for your clarification about the collision's process inside GameGuru MAX.
Importing assets in GameGuru Classic and assigning a collision's method to them was sometimes an uneasy task.
In GameGuru MAX it is now much easier and much faster even if the process is invisible behind the selection parameter.

Conclusion (for me) : I'll follow the advice of Argent_Arts to reduce the number of polygons in my imported assets.


PM
3com
7
Years of Service
User Offline
Joined: 18th May 2014
Location: Catalonia
Posted: 22nd Nov 2021 14:41
I honestly hope that open/close doors with animations in GGMax, don't be that hard to do, but just as GG does or something similar.
Really not willing to make a master just to open/close a door.
Laptop: Lenovo - Intel(R) Celeron(R) CPU 1005M @ 1.90GHz

OS: Windows 10 (64) - Ram: 4 gb - Hd: 283 gb - Video card: Intel(R) HD Graphics
cpu mark: 10396.6
2d graphics mark: 947.9
3d graphics mark: 8310.9
memory mark 2584.8
Disk mark: 1146.3
Passmark rating: 3662.4

PM
Argent_Arts
1
Years of Service
User Offline
Joined: 5th Feb 2020
Location:
Posted: 22nd Nov 2021 17:48
Quote: "I honestly hope that open/close doors with animations in GGMax, don't be that hard to do, but just as GG does or something similar.
Really not willing to make a master just to open/close a door. "


It's actually very simple. Most of my issues were just that - my issues - end-user problems. I plan to create a tutorial on how to get a simple door animated into MAX and working with MAX's default Door behavior.

Quote: "About the collision, my conviction about the necessity to subdivide a mesh came from years of practice with clothes simulations (Marvelous Designer). The particle distance played an important role in the collision of clothes with other meshes."


As Belidos has pointed out - what you're talking about here has nothing to do with collision in a game engine. Cloth sims and the like in a 3D modeling program are very different than what goes on in a real-time game engine. As I had said somewhere in this thread, vertices don't mater when it comes to collision and you want to keep your models as light as possible (while still maintaining their shape) to keep frame rates up. But Belidos covered all of that.
Intel i9-10900K 5.10GHz, 64 GB RAM, Nvidia GTX 1080 ti 11GB, Windows 10 64-bit, dual monitor display
GubbyBlips
3
Years of Service
User Offline
Joined: 14th Jan 2019
Location:
Posted: 22nd Nov 2021 19:31
Yeah, there are two camps here, modelers and scripters. To be both would be bliss. You could have had this working in 10 seconds with a non-animated slab using a script. I would recommend that going forward doors and similar basic items become scripted to move rather than animated. Using the script method is faster when you don't have to insert animations or import through the MAX importer. Also the player can be more interactive with the object. Thirdly Collision is always active, even if the door is currently opening or closing-- you can't walk through it's collision box. I'm pretty sure from playing games like Fortnite, they probably use a physical movement method.

If you want to script your doors, you just (actually very important)-- you need to pre-plan the object to correspond to lateral/width north @ original angle...... for sliding doors, or edge point 'x=0' at hinge for rotating doors. Then it's pretty simple script nearly identical to the animation script, but with this method you have full control and aren't inhibited by model animations.
Quaternions are useful for flying stunt planes or driving Matt's OffRoad Recovery across mountains- (to feedback a civilized 3-axis behavior)

As an example of a *sliding door* script, it could be something almost as simple as this; (but this itself won't work) I went ahead and wrote a completed script you can request from me. Very similar in function to small_g's scripts and I think I did a very similar script when somebody wanted a cage to fall down on the player when they got near it.

if door_closed == true then
if mf < 100 then
MoveForward(e, 50); mf=mf+ 1
else
door_closed = false
end
elseif door_closed = false then
if mf > 1 then
MoveForward(e, -50); mf=mf- 1
end
PM
Belidos
3D Media Maker
6
Years of Service
User Offline
Joined: 23rd Nov 2015
Playing: The Game
Posted: 23rd Nov 2021 13:17
Quote: "Also the player can be more interactive with the object. Thirdly Collision is always active, even if the door is currently opening or closing-- you can't walk through it's collision box. I'm pretty sure from playing games like Fortnite, they probably use a physical movement method."


It may be the case in Fortnite or other games, but in GGc (i haven't messed with Max much yet) that is not the case, in GGc running a door animation with the default door script will turn off collision while it is opening. Place a door and stand in front of it as it opens towards you and see, it will go through you.

I wrote before that it was because of moving while collision is on can break the animation, but i've just remembered that was something different, that was physically moving objects, which would apply to the scripted method of opening doors. With animated doors In GGc the actual reason i now remember that the door script turns off collision while animating is to stop the player being trapped on or behind the door.
Primary Desktop:
i7 7700,k NV1070 8GB, 16GB 3200mhz memory, 1x 2TB Hybrid, Win10.

Secondary Desktop:
i5 4760k, NV960 2GB, 16GB 2333mhz memory, 1x 2TB Hybrid, Win10.

Primary Laptop:
i5, NV1050 4GB, 8GB memory, 1x 1TB HDD, Win10.

Secondary Laptop:
i3, Intel 4000 series graphics, 6GB memory, 1x 500gb HDD, Win8.1.


Login to post a reply

Server time is: 2022-01-28 05:30:23
Your offset time is: 2022-01-28 05:30:23