http://www.quaketastic.com/files/single_player/mods/Keep%20Mod/devdata.jpg 

i would advise you to increase the secret count on your map, for a such big map the number of the secrets is to low 

 

Hallo friends. six months have been gone till I started with mapping for quake. Now I think this thing is going for finish.
Right now I'm checking out the failures in compiling.

I would ask you guys now for help.
Are there bugs? Graphic problems? or other issues.
Please tell me!

best wishes

GunSgtHighway

http://www.quaketastic.com/index.php?dir=files/tod 

An interesting map you have in the making here, GunSgtHighway. :) I like its oldschool looks. It's really rough around the edges, but there are elements that are nicely detailed, like individual decorations and I like the brushwork in the cave areas, especially in the Shambler/Scrag room.

One thing about the map's filename: It's called tod.bsp, but there is already a map called tod in Quaddicted, Tower of Death, so when I tried to extract your map to my maps directory, it was trying overwrite the older tod map. You might want to change your map's filename. People often name their maps after themselves, like in my case I could name my map esrael01.bsp, for example.

To spare the older map from being overwritten, I renamed your map files to GSH_tod.xxx and recorded a demo of my playthrough in Quakespasm. You can download my demo from the link below:

http://www.quaketastic.com/files/tod/tod_esrael.zip

You may have to rename your own tod.bsp and tod.lit to GSH_tod.bsp and GSH_tod.lit, so my demo would work on your computer.

Most of my comments are in the demo, but my main gripes about the map would be the low difficulty and the lack of guidance. Combat could be made more difficult by adding more tough monsters like ogres, fiends and scrags. The map is mostly populated by lowly grunts and knights, which makes the map quite easy. I'd also recommend mixing monsters together. You could combine Scrags to attack from above while other monsters keep you occupied below.

I couldn't also find the Thunderbolt anywhere, even though you added cells in the map. Is it hidden in some secret? If it is, you could also add secret markers in the map.

The biggest problem would be the lack of guidance. Doors aren't marked with the symbols of the corresponding keys, especially the gold key door I found completely by accident.

All in all, it's clearly a beginner map with its flaws, but it was really interesting to explore. I was really interested to see what I was going to see in the next room. I'm looking forward to seeing the map finished and your future maps! :) 

Thanks for your thoughts on the map Esrael. I will rename it and rethink the guidance and monsters. Will take a week or more.

Thanks! 

A stupid question. How can I open the demofile? :D 

1. Place the dem file to your id1 folder
2. Start up your Quake engine
3. Open the console and type

playdemo <demoname>

That's it! :) In this case you'd type

playdemo tod_esrael01

If it doesn't work, rename your map files to GSH_tod.bsp and GSH_tod.lit, because that's what I renamed them to when I extracted your files to my maps directory. 

Ok. I Finaly got it. :)
Yes you're definitly right with the guidance. Will place the keylogos on the doors and maybe some signs on the way too. The clipping is a big thing too. Hmm a little of work to do. :) 

If you want to fix the clipping issues without affecting the looks of the map, you can prevent the player from going to forbidden places with invisible walls. Just make a brush with the clip texture.

Glad I could help you out by testing the map. It's easy to become blind to flaws when creating stuff, so having someone else inspect your creations with a set of fresh eyes can be really beneficial.

Anyway, don't give up! Doing the final touches to a map can be tedious, but reaching the point where you're happy with the end result can be very rewarding! 

Made a new ogre model (with some glitches) bow_ogre. 

Hoo boy, like the concept but the QME jitters are strong with this one. 

With a glitch, I know.

I use a bone model to animate and it measures normal lengths (1m70). The Quake models are in this standard just 40cm.
When converting from this scale a lot of adjustments get lost, because the modelgrid is 512x512. Importing a giant in Qmle and scaling down is not the way to do it.

I'm convering down the bone-model, as it produces finer details in the movements. 

errrmm...aka "fundamental unavoidable artifact when using the mdl model format, irrespective of tools" jitters you mean?

I've often banged on about a hypothetical "mdl2" format that just uses higher precision for vert coords. This is what I'm going on about. 

Adjusting the bone model had a better result.
Still it's hard to make the right movement with the shoulders. There are two cubes in the upper arm that have a wicked connection.
Bow_Ogre 

I've often banged on about a hypothetical "mdl2" format that just uses higher precision for vert coords. This is what I'm going on about.

Something backwards compatible would be nice, what I'm picturing is:

[standard binary for an MDL]
[extra double-precision frame data]

The idea would be MDL standard, just with 16 bit precision instead of 8 bit on each coordinate. The most compact way of doing that is to treat the standard frame data as containing the upper 8 bits of the coordinate. Then the double-precision part is a second chunk, the same size as the normal frame data, but the vertex coordinates in this chunk are used in the lower bytes instead.

I suppose it would be healthier to add a small header between the two chunks, so further extensions could be added.

[standard binary for an MDL]
[extension 1 header]
[extra double-precision frame data]
[extension 2 header]
[shader language]
[extension 3 header]
[hidden bitcoin miner]
[extension 4 header]
[interpolation rules]

The header could be quite minimal, just a value to indicate what type of extension is coming up, then the size of the extension data. That way engines could skip the extensions they don't recognise and keep going. Existing engines wouldn't even look for the extensions, there would just be a bunch of junk at the end of the file they don't look at (this is how Extended-BSP format worked).

May be worth also adding a value that can be set in the standard MDL header to signal to compatible engines that there are extensions to look for. Otherwise any junk at the end of the file might be misinterpreted as an extension (and I think QME used to write bonus stuff to the end of files). 

How would an extension not cause a file read error? 

The header of the MDL file tells you how many of each repeating element the file contains (skins, triangles, frames). Based on the rest of the data in the header (vertex count, skin dimensions) you can pretty much predict exactly how much data you need to read for each one (animation groups complicate this a bit but you can read them one at a time).

This scheme relies on the loading code running loops of the lengths specified in the header, reading elements from the file until the correct count is reached. At that point, it just stops reading the file - in a normal mdl file that happens to be the end of the data anyway, but if there's more data it's just discarded*. This is known to work OK in the base engines because QME used to tag additional data on the end without making the .mdl file unreadable.

* There is the possibility that a source-port engine rewrote its mdl loading code, and by doing so made an error of excess data at the file-end. The QME files might mean the issue was already caught. Otherwise this engine would not be compatible with extended-mdl files until fixed. I'd say this is unlikely in practice, and would be easy to patch. 

When it comes to getting people to support new formats, you need both a carrot and a stick.

eg:
carrot: higher precision coords.
stick: an annoying message appears until its actually supported properly.

Without the stick its just something that can be put off for another day if anyone ever uses the format, and if no engines support it then noone will ever bother using the bulkier format that tools cannot even write. Think of it simply as a constant reminder that action is needed.
Without the carrot its just an annoying format that has no reason to exist.
So by designing your extended format to have no stick, you ensure that there's no reason for anyone to ever support the format, and thus that there's no reason to ever write it either. Never underestimate how lazy engine devs can be...

Another thing is that the reason to use mdl is qme. remove qme (because it cannot write the format) and you remove the reason for people to stick with such an ancient obtuse format too. Just use MD3 or something, QSS is such a minor upgrade. (ignoring bugs new to qss,) The only reason not to is if you're targetting vanilla, in which case any hidden extensions are pointless anyway.

Additionally, if you're trying to make it easy for engines to support then just add a new alternative type of framegroup - one that's 16bit instead (the stick being that engines that don't recognise it will glitch out weirdly putting the blame on the engine). Nothing drives adoption better than users constantly reporting horrendous glitches.
That way there's no need to go backwards or anything, its just a struct/datatype change (with the old stuff being padded where its read).

Either way, you still need tools. You already explicitly mentioned QME's additional data - part of that additional data being 16bit data. Find out+document the format of that existing additional data and you not only have a tool that can already write your extended mdls (one that people already seem to be using for some reason), but you also grandfather in all those models that were already (unintentionally) distributed with that data. Still needs a stick though.

Or just provide both an mdl and an md3 and throw in a little qc to select formats based upon the engine's supported formats (hurrah for in-game messages recommending users switch to another engine until a feature is implemented properly).
Or just use md3 exclusively and ignore anyone using an engine that STILL doesn't support that. Yes, it sucks for vanilla but in fairness its been a while since I(and presumably most people) ran quake in dos/dosbox. 

People have had 15 years to say "I'm using MD3 and you just need to switch engines", but nobody does that. Nearly all the engine additions that have been actually adopted (skyboxes, fog, coloured lights) succeeded because they were backwards compatible.

It's not about being able to still play it in dosquake, it's about being able to play it in any engine. That's pretty important if you want to keep all the players who don't pay much attention to engine developments, or who value the stability of engines with slow release cycles. Writing off a percentage of an already small audience seems unwise.

Nobody's ever tried to make backwards compatible enhancement to the .mdl format, I'd like to see if it works. Maybe it won't catch on, but the nice part is that it won't matter - because any content that experiments with it will also be forwards-compatible with future engines if it turns out to be a dead end. 

I'd like to see if I can make it work 

I agree that the model that seems to succeed is where there is an acceptable fallback for engines that don't support that feature, such as entity alpha, skyboxes, fog, fence textures, lit files, external textures, etc. In all those cases the content is mostly still playable in a vanilla engine.

There are exceptions: aguirre's extended bsp limits, and the bsp2 format are two cases where there is no fallback and it still caught on and became accepted. I was going to add protocol 666 to this list, but this is not something forced on people by a map or mod, so users still have a choice of protocols that provide the raised limits. 

protocol 999 

I agree that extended BSP limits are the rare exception that tests the rule (and this is coming from someone who usually doesn't bother playing maps in bsp2 format). To my mind the key difference there is that it's about breaking limits more than visual enhancement, and there's no obvious way you can do that in a backwards-compatible way. 

I always figured the reason to do a 16-bit mdl format is so you can make monsters that would otherwise look like total trash in mdl. The thought of having a large chunk (most?) of your audience just seeing the trash version anyway because of backwards compat will probably make you design the model in a conservative way to minimise this, which itself weakens the reason for doing 16-bit in the first place, so eh I ‘unno.