gzdoom-g1.8.1-303-gcb74dd9 crash

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: gzdoom-g1.8.1-303-gcb74dd9 crash

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Enjay » Wed Oct 16, 2013 5:02 pm

If model skins are already effectively handled just like textures then perhaps the "dedicated solution" is to officially allow them to be used in the textures namespace (ie, the situation that currently works). That way, anything applicable that can be done with a texture could also be done with a skin... I think.

Or, perhaps, defining a graphic as a skin in modeldef could implicitly put it in the textures namespace?

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by NeuralStunner » Wed Oct 16, 2013 3:41 pm

I would still prefer to see a dedicated solution. (Brightmap property for model skins, presumably.)

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Enjay » Wed Oct 16, 2013 10:35 am

As the thread linked by Nash demonstrates, put your model skin in the textures folder and it can then be given a brightmap (perhaps other things too - like animation?). When applied to a model, the brightmap is respected and so the model gets a brightmapped skin.

Image

The initial post in that thread implies that to get this working the model should also be in the textures folder. This is almost certainly bad practice (putting a non-texture lump into the texture namespace). However, MODELDEF allows the skin and model to have different paths and so the skin can be placed in the the textures folder and the model in a more suitable location. Both then need to be identified correctly in modeldef.

Image

The only restriction that I have noticed is that (in accordance with standard texture behaviour) the skin needs to have a name of no more than 8 characters (plus extension) before it can be given a brightmap.

Image

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Nash » Wed Oct 16, 2013 9:26 am

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Graf Zahl » Wed Oct 16, 2013 7:17 am

So what is the brightmap hack. I do not follow editing techniques so I'm not in the loop.

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Enjay » Wed Oct 16, 2013 2:04 am

The brightmap "hack" still works.

I'm rather disappointed to hear it being referred to as a hack though. Before spending hours implementing it in a number of things that I was working on, I specifically asked, repeatedly, if it was considered a legitimate feature and therefore safe to use or not. Having been caught out before through not asking about such things I wanted to avoid similar problems again. I didn't receive an answer so, with the feature being very cool and being based on (what seemed like) sound principles (ie the skin is treated as a a texture in the engine and so using texture based features seems like fair game) I took a risk and used it. :(

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Nash » Fri Oct 11, 2013 11:09 am

Of course. I kept that in mind.

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Graf Zahl » Fri Oct 11, 2013 10:56 am

No, the fixes only affect resource maintenance. The code to free the models has some serious issues.
Concerning your 'hack', please keep in mind if you in any way abuse undefined behavior I can't guarantee that it will remain functional. Use at your own risk!

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Nash » Fri Oct 11, 2013 10:26 am

I wonder if any of these recent model fixes would have any effect on the model brightmap hack that was recently discovered?

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Enjay » Fri Oct 11, 2013 10:18 am

I've only had a chance to make a very quick check because I'm about to head off for a few hundred miles drive but, so far so good with both DoR and my own mod.

I've put a build on line over at the DRD development builds site too.

Thanks for the fix.

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Graf Zahl » Thu Oct 10, 2013 5:06 pm

Fixed the DOR crash. It was also model related but something different. This time it was trying to delete the skin textures twice.

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Enjay » Thu Oct 10, 2013 4:50 pm

Ah, thank you. I too get a crash with DoR and have uploaded a crash report and (possibly meaningless - because I don't really know what I'm doing :P) minidump result screenshot to the above linked GZDoom thread. If I have done the minidump thing correctly, it's interesting that it points to a similar line but in a different file to the minidump screenshot that I already posted in that thread.

Anyway, that's me out for a few days now.

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Ed the Bat » Thu Oct 10, 2013 4:14 pm

Using gzdoom-G1.9pre-312-gb6dab83, Clavicula Nox no longer crashes at map launch, nor does it crash on exit. Same for Braham Manor (it's for Vavoom, so I rewrote the models from xml to MODELDEF so it'll work correctly in GZDoom); no crashes.

I do, however, experience a crash on exit (report attached below) when playing Dawn of Reality, but considering it's a gigantic map, the sheer size of it may be more to blame than anything...
Attachments
CrashReport.zip
(23.79 KiB) Downloaded 31 times

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Enjay » Thu Oct 10, 2013 4:03 pm

Ed the Bat wrote:I just tried gzdoom-G1.9pre-312-gb6dab83, and the crashes have stopped.
I'd be interested if you had time to poke around and push this a bit further to see if any of the mods that you were having problems with still cause a crash/ I'm still getting a crash on exit but I don't have the opportunity to look at it any further for a few days.

http://forum.drdteam.org/viewtopic.php? ... 257#p54257

Re: gzdoom-g1.8.1-303-gcb74dd9 crash

by Ed the Bat » Thu Oct 10, 2013 3:53 pm

I just tried gzdoom-G1.9pre-312-gb6dab83, and the crashes have stopped.

Top