Serpentine

Nah, regex was more than enough - and in the end, it was only the lights file that needed it.

iirc in the last release there were changes to the way loading is handled at startup, and often if you're dealing with threads getting things done quickly, the window will not be updated and as such Windows will mark it as 'not responding' until it returns... or if it doesnt. If Windows is terminating this, it might be as a result of you lowering your timeout for 'end task' to something like 10 seconds, which is far too low for many things.

Yeah I just tested, works as expected - so good call there. I'm just going to make a better expression to try find other characters which would need this to be done.

Hmmm sure, that makes sense. As to the assumption about the loader translating -'s to _'s or whatever, the idea is more that we could make all non-word characters into underscores, this would not load them, however it would allow the files to be renamed to comply(rather than allowing more bad sprawl), without breaking any other defs/lexer/tokens. However should this work, it wont be required.

An example of the problem can be seen here - this is the training mission (and as such the list is only that of models used on the map): WARNING: Couldn't load image: - WARNING: Couldn't load image: extinguishable/arclight WARNING: Couldn't load image: extinguishable/electric_plain1_unattached WARNING: Couldn't load image: extinguishable/grill_light WARNING: Couldn't load image: extinguishable/grill_light_short WARNING: Couldn't load image: extinguishable/lamp_shaded WARNING: Couldn't load image: extinguishable/lamp_shaded02 WARNING: Couldn't load image: extinguishable/lantern_oil_hand WARNING: Couldn't load image: extinguishable/wallight1 WARNING: Couldn't load image: extinguishable/wallight2 WARNING: Couldn't load image: extinguishable/wallight_3_unattached WARNING: Couldn't load image: extinguishable/wallight_3_unnatached WARNING: Couldn't load image: extinguishable/wallight_outdoor3 WARNING: Couldn't load image: models/darkmod/lights/non WARNING: Couldn't load image: }

They must have been defaulting to something else, I think the easiest way around it is just to make the model loader replace minuses with underscores. Least work, solves a bunch of possible issues and lets us rename things safely in the future.

The skin should still find the model, it does with my little test here, however I'm only looking at it in the engine - not DR. Feel free to revert it, but if you're going to go changing lexers - you're going to have one hell of a time testing that all operand uses are still working correctly. I really doubt that these skin have ever worked correctly, seeing as it cant load the correct image.

Removed a bunch of these files, nothing too major. While I was in the area I fixed up the skins for various lights. 'non-extinguishable' has the '-' character in it, which is problematic for images/materials/skins/etc. However since the models have a hard path including them, I cant just rename the models and change the skins to represent that. I have replaced the -'s with _'s this should work (I did test, but I would not consider it a clean test). I expect this might not work, but I hope it does. PLEASE stick to a-Z, 0-9 and underscores for names.

It's just a timeout, most likely busy loading assets and too busy to tell windows what's going on.

Thanks

@BC - Are you using your test materials/particles?

Ah ok, sorry about that then! I'll have to test those fires against 1.07, but they seemed way too fast to me... mmm!

The font itself is already in, the normalmaps can go in - but will be messy until I can enable them by default, however for that to happen we need the performance regression to be out of the way so that it doesnt end up either being a pain to revert or hiding the problem.

Just a note BD, don't speed it up too much. I've noticed on some of your maps some of the light sources flicker far too quickly, at lower fps this may be less noticeable however in most areas it's quite annoying. I noticed this quite a bit on stalban, the fireplaces and some outside lights.

Hey there, There are a few material and particle files (and likely others). Can we start removing these from the SVN? while backing your work up is good and I know that the packaging scripts remove them. It does make working on the engine a bit messy with loads of warnings and errors which are not actually important. If you're finishing an asset and want to iterate design based on feedback, its fine to just use the real files. I can set an ignore rule to allow personal test files to be ignored (stops you accidentally adding them); i.e if the name includes 'ptest', ignore it when committing. Would this be something that would interest anyone? We also have a bunch of maps which are either out of date or not related to mapping within the main repo - Do we really need these? Just trying to get some spring-cleaning done so that I can reduce noise in logs and prevent some bit rot.

I cant see horses in the entity browser, however once inserted into the map, they show up correctly. They seem to be translucent when lighting mode is active... but yeah.

The viewer tool is part of the Assimp project, so it's not really TDM specific at all, I just added the ASE export module and fixed up a few other things. The Assimp guys are interested in pushing most of this upstream tho, so it's going to good use. The viewer itself is just a debugging tool really, assimp is aimed at getting models into games, not for really exporting (which was just a nice feature recently added, before people were wrapping it with python and such). Anyway - pretty much its a 'not my baby' thing, I didnt write it and havent poked around much inside. However seeing as I know a bit about it lemme answer some of your questions: 1 - This is semi-possible already, meshes are split into nodes per material (or per imported node if optimization is disabled in the file menu). If you show the side panel (on the right in my screenshot above), there are 'N' nodes under 'dummy root' or similar, those will be the sub-meshes. While you cant filter out, you can view specific ones quite easily. 2 - You can add texture maps to the model, select a material -> add diffuse etc. This can be a bit quirky, but it's handy from time to time. It can also preview normalmaps and such - but any changes to these settings will not be exported. 3 - I will have a look at this, I know what you mean.

Please try installing the latest DirectX redist (here). Let me know how that goes. It should work as that's the version I'm building against.

Ah, it might have needed the latest directx redist, it's working correctly now tho?

On topic: Finished up generating non-verbose ASE's, lists have been converted to sets and indices are maintained. This means that there's a lot less spamming of unique verts/normals since the engine will do those checks and generate them anyway - and more accurately. Vertex colour also seems to be correct now. Anyhoo, got a few tests to do, then I should release the new build tomoz evening. Nah, that is a road that only leads to trouble later on. However using it as a loader/converter/health check in tools would most likely be a good idea. The ASE importing can be spotty (for example the broken ASE's that DR's export script generates, which are technically invalid, however d3 seems to load them). You need to have constraints in an engine, constraints allow you to minimize the surface area for mistakes/problems and maximize assumptions to help performance, compatibility, portability etc. Some people don't quite understand that last point tho

I'd still go with cheaper stuff, cpu is fine - however since you work with asset creation and such, 4gb is going to be a pain after a while. Mobo seems rather overpriced(), if you're not going to be overclocking to the edge of stability, there seem to be plenty cheaper models which will cover the increase in ram.

Game should be Doom 3 Engine path should the the directory that contains the directory base/ should you have one. (i.e doom3 if you're also using doom3 assets) If you have a different folder like hexeneoc/ in the same directory, which contains your hexen specific assets, you would set fs_game_base to that. (i.e if you are acting as a mod of doom3 still - sharing files that are still in one of the base pk4's) i.e : C:\ |-Doom3\ - engine |-base\ |-someotherfolders\ |-hexeneoc\ - game base |-hexengame01.pak |-textures\ doom3.exe hexeneoc.exe That said, it's quite likely that there are particles which might have trouble, the module was written before the doom3 source was out. I myself have not used it very much, however I guess if you have any examples of ones that dont, perhaps it can be looked into.

Cheaper mem + cheaper mobo is quite a large saving - When I purchased, I saved 40% off distribution price by doing that, once you've halved the price you're paying for the majority of your components, it makes sense that you could upgrade in half of the time (and move gfx over to the new box if needed). Considering the aging of the overclocked and stock clocked components will be linear while newer hardware will be assumed to be exponential with the same starting point, it makes more sense to upgrade those components than pay a premium, and you get some interest for being clever. This only really applies to high end stuff, not mid range or ultra high end - the premium scaling of the ultra high end, and the performance degradation of mid range products is pretty horrible. But maybe that's just my thrifty hobo logic at work! That and there's nothing worthy of the hardware at the moment

If you wanted to add support, you'd need to decode the ogg to raw anyway - there's very little reason to do that. It's overhead and messy without a reason.

If you're not actually going to overclock - save the cash and drop the K to a normal and drop the mem to whatever the cheapest standard 1333 is. Don't bother with dual cards or any of that rubbish.