I think that some of the library objects are not fully assigned.
I had one item tested that I could not change collision on in the editor. Player can walk thru it no matter the setting.
I will run thru them and identify which ones are still giving issues.

Yep..
my bad guys are still running thru
just about everything..most walls for sure..

UNIRD12B

@UNIRD12B

I confirm that the enemies pass everywhere, through. But I think it comes from a problem with the navigation mesh. I posted on Github and Lee is informed.

Pirate Myke's problem is different : it is he himself who passes through.

Ye i reported to Lee AI was running through the walls of my Warehouse model also some time back.
Some builds improved and some got worse but never solved.

Not sure if this belongs here or not but noticed that if you add the spin behavior or the hover behavior to an object, the object loses all collision. this happens no matter what collision settings you use. I imagine it's probably the same for other behaviors as well, but only tried the spin and hover behaviors trying to make moving platforms. Maybe this is a bug, maybe not, perhaps it's just not fully implemented yet. Just wanted to see if anyone has any thoughts or more information.

@Toxicclowd
Thanks for raising this issue.
It's the same for me : all collisions are lost once the Spin or Hover Behaviors are assigned.
I will report it on Github.

Regards,
UltraVox

I wonder if this is like the door issue, where collision is turned off when the door is animated to open/close. Do you think that perhaps MAX is purposefully turning off collision on these objects because they are being moved?

I will find out quickly :
https://github.com/TheGameCreators/GameGuruRepo/issues/2028
I'm going to ask Lee directly to find out if it's a bug, or a voluntary act.

Doors are deliberate i think. Generally so the AI or the player do not get snagged in the frantic action and there is a requested door script around that does not turn off collision but turned out not to be so good as users thought because of the points i mentioned.

Yes, I know. I was wondering if the other was deliberate as well for perhaps similar reasons.

Although we are looking at the animated door opening and closing, the door itself remain in their position, due so, the door scripts usually use CollisionOff(), to let the player walk thru.

Doors, we don't care. Looks to me like @syncromesh produced a rotation script for the doors.
@syncromesh do you intend to propose it to TGC ? This script would be very useful to many people.

For Behaviors (recent topic introduced here), Lee asked me to post it as a bug on Github. It's done.

Had to get permission first i did not make the script myself.
but yes its all in hand

Excellent news ! Thank you @syncromesh
I feel that in a short time, TGC will offer a pack of doors... immobile

Using it myself now on a demo ... works really well

Can't wait to use it for the first time.
In the meantime, I must find doors.

@Ultra;
Wordle much?
You famous now.

More than you imagine !
My player name is Mk Ultra : https://en.wikipedia.org/wiki/Project_MKUltra

Hello,

Toxiccloud posted this comment :



It is not too difficult to modify the behavior "hover.lua" which contains a nice trigonometric formula to create that back-and-forth motion on the vertical axis.
If you examine that behavior you can see that "Collision" and "Gravity" are disabled in the "function init" section of its script.

To convert that behavior into a new one being able to control a moving platform it just takes a few minutes.
Here is a modified version of that behavior ( it is just an idea and it could surely be improved) :



What was modified ?

The deactivation of the "Collision" and of the "Gravity" are inserted in the "function main" section of the script before the lines of code controlling the vertical motion.
After the execution of the motion ( I think that this process could be evaluated in microseconds) the "Collision" and the "Gravity" are reactivated.
In this way the player or any object having its "Physics on" parameter enabled will collide in real time with the object to which that modified "hover" behavior is applied.

In that modified version of the script I also changed the speed and height of the motion ( done fast, it is just to give an idea that could inspire you for a better script).

That modified behavior was successfully tested on an object (an imported mesh) for which I forced the combination "Physics on" with Collision Shape "Polygon" (*) to transform it into a moving platform/elevator.
(*) Surprisingly it is possible to cheat with the settings in the parameters of the "Object Tools".

What did I say?



So, this is not a bug, but by design because of worries of a player getting caught somewhere when used (or some such).

Here is a short video demonstrating a modified version of the behavior "hover" applied on two imported items : the first one is a platform with walls and the second one is a platform having no walls.
You'll notice that the soldier staying in the platform with walls doesn't shoot on the player because the collision's process works properly between that character and the platform.

This is the link to that video (sound included) (length : 60 seconds, size : 107 MBytes) :

A new experiment : combining collisions with the behavior "Patrol" is possible as shown in this short video clip ( 17 MBytes = 13 seconds ) published on Vimeo :