Fitzquake Crash
#13355 posted by ijed on 2013/11/23 18:46:41
I've got a mesh, that if created causes a hard crash in Fitzquake.
Condebug doesn't give me any readout of the error, nor does developer 1 - it just hangs before crashing to desktop.
Other engines (FTE, Tyrann's) have no problem with the mesh in question.
I can't see anything in the documentation, is there any known issue with this?
Ok
#13356 posted by ijed on 2013/11/26 12:21:28
FYI, Fitz crashes if you set a skin on a model that doesn't exist.
I'm generalising gibs and different types thereof.
#13357 posted by metlslime on 2013/11/26 20:25:39
ijed: if the skin doesn't exist, or if the model doesn't exist?
Just The Skin
#13358 posted by ijed on 2013/11/26 21:05:47
It's a hard crash without an error message, which is what had me scratching my head.
If the model didn't exist it'd give me an error.
It seems the other engines I mentioned default to skin 0 if the qc tries to call a bad skin, same as with a bad frame.
#13359 posted by metlslime on 2013/11/26 22:58:00
Interesting, I thought I had set it up to display a blue/black checkerboard texture when the skin is missing. Maybe some other changes have broken that feature.
Yeah
#13360 posted by ijed on 2013/11/26 23:50:10
I thought it was odd when I figured it out. Ah well nobody's perfect :)
I doubt it matters, but this was with Spike's hack to make it usable with BSP2.
#13361 posted by negke on 2013/11/27 18:35:34
Remember my cellshading sm134? It uses invalid skin numbers on purpose for the blue/black effect, and there's no crash. So it sounds more like there's another condition at play on ijed's end.
Possibly
#13362 posted by ijed on 2013/11/27 20:38:20
But like I say, I fixed it by inserting duplicate skins on the mesh. It also only affects this particular mesh as well.
Here it is, if you want to check it out;
https://www.dropbox.com/s/9e5vvwd3vnt8bnh/hunter_gibs.mdl
GtkRadiant 1.4
It's for Quake 3 but surely there are some experienced Radiant mappers around?
I had a system crash and now I'm kinda worried. In reinstalled and everything works fine. When I open the map in the editor, all textures are nicely aligned (except I'm missing some due to the crash). However, if I compile, regardless of what option I use, I get this:
http://i.imgur.com/2sbGuq4.jpg
Any ideas?
PS: If I build a new map, regardless which textures, the same happens. As if some value is off somewhere that's downsizing them.
Antilights And Weird Classes
#13364 posted by Preach on 2013/11/28 02:18:27
I'm mucking about with weird entity settings as usual. Most of my experiments have found that no matter what classname an entity has, you can give it keys that light.exe recognises and it just works. For some reason, antilights only seem to work on proper light entities, not on these repurposed entities. I'm using benlight for these tests, has anyone ever encountered this and worked around it? Or does another light tool cope any better?
Preach...
#13365 posted by quaketree on 2013/11/28 07:05:02
I'm not quite getting what you are asking. Are you asking if someone has found a way to apply or tie a negative light to an entity as a sphere around the entity? If so I haven't seen it.
Sprony
#13366 posted by - on 2013/11/28 08:37:57
Even the stock Quake3 textures do that? If not, then likely there is a disconnect between the Q1 textures you are seeing in editor and the textures the game is using (maybe there is a pk3 of half-size textures in your Q3 directory stomping correctly scaled textures in a directory you are using for radiant?)
If not, first thing I would look at is if your textures are being scaled down properly. Quake3 generally uses double-sized textures that are scaled down by half in radiant (so, a 256x256 for a 128x128 wall). Select a face in your map and bring up the surface properties, your x and y scale should be "0.5". (in 1.5 at least, there's a setting in 'edit -> preferences -> settings -> brush' that controls this default) I'd then save the .map and then look at it in notepad. You should have brush faces that look something like:
( 0 96 256 ) ( 0 32 256 ) ( -64 96 256 ) egyptsoc_mat/block01a 0 0 0 0.5 0.5 0 0 0
Where the "0.5 0.5" parts of the line are the texture scale. If Radiant showed you something different in editor vs when it saves, then there's a problem that I don't know how to fix :(
I don't believe there are any compiler settings that could be doing this.
#13367 posted by Preach on 2013/11/28 11:04:00
I'm not quite getting what you are asking. Are you asking if someone has found a way to apply or tie a negative light to an entity as a sphere around the entity? If so I haven't seen it.
It's a compiler issue I'm having, and I don't understand the compiler source code all that well. In general, the light.exe tool doesn't care what classname an entity has, it's only looking for the "light" key on that entity. You can give a monster_shambler the key "light" "200", and the compiler will create a light source at that point (obviously it doesn't follow the shambler, it's just static).
The other thing is that antilights - lights with a negative value in the light key which some compilers support. What I've found is that these two things don't mix. If you create two mapobjects with "light" "200" and "light" "-200", what I've found is that the antilight one doesn't have any effect. If you take the entities and just change their class to "light", suddenly the antilight starts working as well.
I think I've spotted a separate issue in what I'm trying to do, so don't worry too much about it, but it's weird all the same...
Well
#13368 posted by ijed on 2013/11/28 13:04:27
AFAIK it was AguirRe who invented antilights, or standardized them at least. Maybe send him a direct email because I don't think he views this board anymore.
I'm Probably Wrong But
#13369 posted by Rick on 2013/11/28 15:16:27
I would guess that when anti-light was added (negative light), that particular code only checks actual Light entities, whereas the original Light code (as you have noticed) just looks at everything.
Personally, I've always considered that to be a bit of a bug.
Scampie
Yes, even stock textures do that. Thank you for your suggestion. I checked but Radiant shows the right scales, just like you said. I did some extra checks:
It's not the editor. Regardless which map I make or load, everything works fine.
It's not the game. If I take old compiles or load the original maps. all is displayed normally.
It's not the textures. Even vanilla textures show the same problem.
It has to be a compiler issue. I reinstalled Q3map2 to no avail.
Sprony:
#13371 posted by - on 2013/11/28 16:03:56
Can't Compile Map
#13372 posted by Breezeep on 2013/11/28 17:08:33
Hey, I'm using necro's compiling gui and I get this error in the console:
Copying Files... The system cannot find the file specified. Converting map... --------------QBSP-------------- 'C:Program' is not recognized as an internal or external command,operable program or batch file.
#13373 posted by Spirit on 2013/11/28 19:03:52
put the map in a path without spaces (it breaks at the space in "Program Files"), quake tools are a bit last century
Scampie!
My man! Thanks to you I found the problem. After re-installing Windows I decided to sort through my old files and make everything tidy. This resulted in me installing Q3Map2 in a directory outside the Quake 3 directory. That's apparently the problem because I now placed it in the Quake directory and tada, it works like a charm!
@Spirit
#13375 posted by Breezeep on 2013/11/29 04:26:39
good. I might try that tomorrow.
@Spirit #2
#13376 posted by Breezeep on 2013/11/29 18:02:27
Alrigt, It compiled. But I can't instantly launch quake and play my map on it, (I have the steam version BTW.) but it's alright now! thanks for the advice!
Random Idea
#13377 posted by Spirit on 2013/12/03 09:59:21
could a very low r_speeds limit lead to a "Quake the way id did" look?
I Guess So
#13378 posted by RickyT33 on 2013/12/03 16:05:56
Could be a good speedmap theme also.....
Ogre Idle Sound
#13379 posted by Rick on 2013/12/05 05:27:20
Why do they have one? No other monster makes noise when standing still. It makes no sense.
|