I spawned MAP16 and the collision worked fine. There was error spam from gmDoom, but that isn't my addon to fix.

I found the issue, it was chromium.

Originally posted by Jcw87:

I spawned MAP16 and the collision worked fine. There was error spam from gmDoom, but that isn't my addon to fix.

Ok, don't want to harass but, do you know what the problem is in there?

The error description made it pretty clear what was going on. It is trying to change the physics of an object at a time that is not allowed, namely during a physics callback. IIRC, all the gmDoom objects use cylinders for collision, and these cylinders need to change sometimes. I also vaguely recall it using actual source engine models for this at one point. Ghor and I had a discussion about PhysicsFromConvex (which powers the map collision) while I was working on my maps addon, so maybe he changed it to use that. I would have to look at the code to get more specifics on what needs to be changed to fix it without breaking functionality.

Originally posted by Jcw87:

The error description made it pretty clear what was going on. It is trying to change the physics of an object at a time that is not allowed, namely during a physics callback. IIRC, all the gmDoom objects use cylinders for collision, and these cylinders need to change sometimes. I also vaguely recall it using actual source engine models for this at one point. Ghor and I had a discussion about PhysicsFromConvex (which powers the map collision) while I was working on my maps addon, so maybe he changed it to use that. I would have to look at the code to get more specifics on what needs to be changed to fix it without breaking functionality.

Yeah, i also noticed this happened immediatly with The Ultimate Doom maps, but in Doom 2 Maps nothing happened (except for that the whole map was really bright) until i defeated the first possesed.

Originally posted by John Tech-Head:

Originally posted by Jcw87:

I spawned MAP16 and the collision worked fine. There was error spam from gmDoom, but that isn't my addon to fix.

Ok, don't want to harass but, do you know what the problem is in there?

Yes, it was chromium.

Originally posted by Specteroid:

Originally posted by John Tech-Head:

Ok, don't want to harass but, do you know what the problem is in there?

Yes, it was chromium.

what do you mean by chromium? was the x86-64 thing causing gmdoom maps to stop having collision?

Originally posted by ren:

Originally posted by Specteroid:

Yes, it was chromium.

what do you mean by chromium? was the x86-64 thing causing gmdoom maps to stop having collision?

I assume he is talking about this: https://github.com/solsticegamestudios/GModCEFCodecFix
Though, it doesn't make any sense that this would interfere with collision.

Originally posted by Jcw87:

Originally posted by ren:

what do you mean by chromium? was the x86-64 thing causing gmdoom maps to stop having collision?

I assume he is talking about this: https://github.com/solsticegamestudios/GModCEFCodecFix
Though, it doesn't make any sense that this would interfere with collision.

yeah i don't really understand what that has to do with collision. i brought up the x86-64 branch because i'm using it and also having collision issues. very strange

Originally posted by ren:

Originally posted by Jcw87:

I assume he is talking about this: https://github.com/solsticegamestudios/GModCEFCodecFix
Though, it doesn't make any sense that this would interfere with collision.

yeah i don't really understand what that has to do with collision. i brought up the x86-64 branch because i'm using it and also having collision issues. very strange

It looks like it is indeed related to the x86-64 branch. I guess I have some debugging to do.

It should be fixed now. There was a very bizarre order of operations issue. When I first created this addon, I had to deal with the scenario where the server instructs the client to create the map entities before the client has received the map. Because of this, I had to put all of the initialization logic outside of the ENT:Initialize function, where that stuff normally goes. This led to the following order of operations: Create entity, call setup function, then spawn entity.

The issue occurred when spawning the entity. In the main branch, if I had previously set the model on the entity in the setup function, then the spawn function would not tamper with the collision bounds set up by PhysicsInitMultiConvex, and everything worked great. On the dev and x86-64 branches, spawning the entity messed up the collision bounds, regardless of whether I set the model previously or not. This resulted in the game only checking for collisions when you were very close to the entity origin. I just needed to split out the collision part of the setup into a step that happens after the entity spawns, and now it works on all branches.

damn did the demons break up their alliance or something