[Mark]

On it's face this seems to be an impossible glitch but its happening. There is a lot more coding that goes with this model, but after running across this glitch I took it down to bare functionality in order to find the problem. The model is not taking cstat 257 to make it blocking and hittable. As a test I tried different cstat numbers for transparency and other effects and they work. Its 257 that refuses to work. I can walk thru the model and can't hit it with weapons. I'm totally baffled as to why. The defs and then the simplified test con code. This is so basic it should be working.

//THUG2 big willy

dummytile 6320 36 40

model "assets/models/thug2/thug2.md3"
{
scale 1.2
shade 0
zadd 24

// model skin definitions are here

anim { frame0 "AnimFrames00" frame1 "AnimFrames25" fps 4 }
frame { frame "AnimFrames00" tile 6320 }

}
-----------------------------------------------------------------------

define BIGWILLY 6320
define BIGWILLYSTRENGTH 80
action ABWSTAND 0 1 1 1 1

useractor notenemy BIGWILLY BIGWILLYSTRENGTH ABWSTAND
cstat 257
ifhitweapon { killit }

enda

[Hendricks266]

If you comment out the model definition, the sprite should look like a black rectangle. Does the sprite respond to cstat 257? Keep in mind that the sprite, not the model, is used for collision and hitscan calculations.

[Mark]

No difference with the black box sprite. I can see in Mapster that cstat is indeed set to 257 yet its still unhittable and no blocking. Its just this one useractor. The others are fine. Thats what makes this a hair puller. I checked to see if something else was using the same tile number and confusing things but I don't see any.

Just to rule it out, I moved the model up 10 tiles to 6330 and it works.
I now remember running into this type of problem a few more times throughout the years. It happened randomly with different tile numbers. I would move the model to another tile and didn't care why it happened because it started working. I triple checked. Nothing else was accidently using the previous tile. So just like the previous times I'll put it in the oddball glitch pile and forget about it.

[Danukem]

It would still be a good idea to rule out that something in your code was causing it. You could do that by adding your model and actor on that bad tile number to the vanilla game, with none of your other code or content. If there is something in your project messing with cstat on 6320, it could come back to bite you in the ass later if you just ignore it now.

[Mark]

At the time of adding the model in tile 6320 it was the highest tile being used. No other textures or models are using it.
Custom .art tile textures ended in the 5000's somewhere. The previously defined model used 6300- 6316. I triple checked my code for anything else attempting to use 6320 and I found nothing. I moved on to the ton of other things to code. If curiousity gets the better of me later I'll try placing another model there with cstat 257 and see what happens.

EDIT: I put a different model in 6320. Same problem. Then I tried it in 6319 and 6321 and it works fine. So it for sure has to do with just tile 6320. I'll try that tile number in another project folder and see what happens.

EDIT AGAIN: 6320 works fine in vanilla eduke32. So the unsolved mystery is what is conflicting in my custom project. Mapster shows nothing there and a search of all my cons and defs show nothing there.

[Danukem]

Mark, on 21 December 2018 - 08:01 PM, said:

EDIT AGAIN: 6320 works fine in vanilla eduke32. So the unsolved mystery is what is conflicting in my custom project. Mapster shows nothing there and a search of all my cons and defs show nothing there.

Welcome to debugging hell. You could try disabling all event code, then if that fixes it, add back all events one by one. Same with actors if that doesn't work. Or you could just move it to a different tile and hope nothing breaks later.

It could be some code changing cstat on a sprite that is not being referenced by tile number.

I had a bug a month ago where random sprites would have the wrong cstat for no apparent reason. They would become transparent, half-submerged, and sometimes they would be wall aligned, sometimes floor aligned. This only happened to a very small number of sprites and sometimes I could play without it happening at all. Turns it it was because I had commented out a block of code but missed a few lines. The code had been spawning a laser dot sprite every tic, and some of the code would do calculations and then set cstat on "RETURN" (which had the ID of the sprite). With the "espawn" part of the code commented out, the remaining code was setting cstat on random sprites. Lucily I was able to find the cause pretty quickly once I started looking, but it could have taken a long time.

[Mark]

I guess I'm not curious enough to go through that since moving to a new tile fixed the issue. This project is using code from early to mid 2000s. A lot of it I don't understand and won't mess with. Actually, I understand the logic behind it but would never be able to trace through and modify it. But I still have to examine it because I have found a whole lot of effects that were not yet used in the demo. I've brought them out for use but I still occasionally find a new one. I'm happy I've done as much as I have, fixing and adding things but its been a real struggle for my skill level.