|Posted by metlslime on 2002/12/23 18:27:46|
|This is the place to post screenshots of your upcoming masterpiece and get criticism, or just have people implore you to finish it. You should also use this thread to post beta versions of your maps.
Need a place to host your screenshots? Upload them here:
[[[CAN WE PLEASE HAVE A NEW PASSWORD FOR THIS AS THIS ONE IS UTTERLY FUCKING ANNOYING]]]
File size limit is 128MB.
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]
[extension 3 header]
[hidden bitcoin miner]
[extension 4 header]
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.
Sometimes You Have To Be Awkward
When it comes to getting people to support new formats, you need both a carrot and a stick.
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.
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.
Just To Complicate Things
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.
For The Record I Still Like Preach’s Take On The Idea
It seems elegant despite my above misgivings
wouldn't it be simple to code into the engine a search for a md3(or md2) version of the same model name? So much like the high def textures for those who want to use them.
It would mean that so long as the person modelling had released a lower poly version of the mdl too it would be available and wouldn't break vanilla compatibility.
you could fall back to an existing entity in the pak. If I make a new monster md3 but the engine doesn't support it, fallback to an Ogre. Have that fallback mdl definable by the mapper.
^^^^ that's stupid
I still don't see how it would be possible to do the amazing effects (outside of full fledged particles a'la Maya or Blender) that Preach manages to pull off with the mdl format. I'm still at a loss on how to make polygons dissappear into themselves.
The trick is that you take each particle, and on the frames where you want it to be invisible you apply a scaling transformation with scale factor 0 (typing the value numerically is the surest way to do it). There are variations on this, like on some models I only apply the transformation on one axis, so that the particle collapses into a line rather than a point. But it's all about scaling - it's the easiest way to ensure that all the vertices align so the polygon disappears.
I Had No Idea...
and this is coming from someone who usually doesn't bother playing maps in bsp2 format
This is heartbreaking.
Is there anything that would bring cause for a bsp3?
I have now made an arc_ogre, but I am faced with the problem that my splines are converted into four on each clip node when converted. The result is that a q1 model with relative weight triangles is converted to two triangles in each square. I can only save them in squares, which are converted to two triangles.
If I import this to qmle, the ratio of internal triangles has almost doubled.
Would this make much difference to a model with only half of verts / tris? As long as it stays below 1000tris / 2000verts, it should make little difference.
Sepulcher allegedly came close to hitting the upper limits, and also it did something that required a change in Quakespasm, but I don't remember what.
The 3DRealms game has some gigantic maps, but IIRC they don't use their own map format.
I suspect Bal will be the first one to break bsp2 ;-) but at that point, adopting q3bsp would probably happen first.
Although strictly speaking some engines (e.g. unmodified GLQuake) do have a limit of 1000 triangles, the original software engines allowed 2000 triangles, and pretty much every custom engine at least restored the limit to that level. So you're probably OK to exceed 1000 if you need to.
In my case it is not the tri limit, but the question if I should simplify a working model with relative high counts into one with less for benifit of better performance.
It's quiet a lot of work doing this in Qmle.
Pictures, screen captures, screenshots, views of work in progress, ... come on, make us get an hard on, Quake style!
Trying to adjust maps by the hand of the first screenshots, with no dynamic light.
Sorry for the low resolution, old quake school.
Nothing Too Special
Temple Of Doom Final Beta
I've over worked my map and think its ready for release.
Hope that some of you can take a look on it and tell me if it works.
Thoughts On The Temple Again
Below you can find my demo with comments:
Having more guidance in the map was a welcome addition in this version. I also liked the little story texts. :)
I still think the map was a bit on the easy side. Especially the temple area with the yellow and red armors being so easily available, not to mention giving the player the quad damage. Maybe some of the stuff could be hidden behind secrets?
I wasn't able to exit the map this time around. I opened the map file in Trenchbroom, and it looks like the reason is because you haven't specified the next map for the changelevel trigger. You have to specify a map, or else the change level trigger won't work. (Didn't know that myself, actually. Well, the more I know, I guess.)
While having the map open in Trenchbroom I also noticed that you had used the wrong texture in the clip brushes that were supposed to prevent the player from jumping over the fence. You should use the "clip" texture, not the "trigger" texture.
Thanks again! :)
Ahh yes I forgot the armor.
Will It change something if I change the Level to normal or hard?
The exit thing is a little bit frightening cause I entert the start map for exit and never changed it? Yes it disapeared Hmmm. I changed that again.
Do you think after that last changes this is a map for release?
New DM Map Beta
I got an idea for a map last week, and probably 50+ hours later have a working beta of it. Wanted to pass this around for testing, for anyone who is interested.
I have played it with FrikBots, but not against humans yet. Even if DM isn't your thing, I'm open to feedback on the map build itself.
TEST RUN VIDEO:
Somewhat cheery style, if one can say that. Farily brightly lit (I usually say the opposite), though of course you don't want a DM map to be too dark, either.
There's something about the layout.. so many corridors, and the upper/outside part seems to be a little bit secluded from the normal flow? Possibly a misconception on my part as I didn't actually play it properly.
The light beam effect is cool, but I wouldn't use an engine-specific effect in a DM map, because it looks bad on older/non-QS/DM-focused ports: pic
The teleporter triggers should be a few units in front of the entire structure imo, to avoid getting stuck on the sides and dropping into the lava by accident.
Mandatory suggestion: consider putting in some single player stuff once the DM portion is finished and finetuned! ;)
The level seems to be SSG-focused by the looks of it. Very little in terms of nailgun ammo - they run out so quickly in a fight. I would suggest adding a little more, especially near the nailguns, and turn every small nail box into a big one. Testing with bots is tricky, because they are so dumb that low-tier weapons appear viable where in a real DM they are usually not (at least against players with RL/LG).
GL is very close to the RL, so the explosive-type of weapons are centered on the upper part of the map. Maybe put the GL somewhere in the lower part, or add a second one down there? In this sense, however, I have to quality my "upper part somewhat secluded" statement, since this way it's a bit of a king-of-the-hill setup where the teams can try to conquer/dominate the RL area. Especially with the RA being so close to the RL. I usually try to spread out the powerful items to encourage movement.
No LG at all?
A little pet peeve if you allow: please rotate the teleporter destination platforms so the runes are aligned to the direction the player appears on the platform. The arcane magic requires it!
@negke - the outdoor section did get a little out of hand during the build. Bigger than planned. During my tests (not that bots are a great test), the RL was sort of a fetch quest, get it and head back into the interior of the map. I might have to just chalk that one up to lesson learned, regarding layouts. It sort of violates some guidelines I'm trying develop for DM maps, too. So I should probably just be intentional about sticking to my principles, keeping things more tightly connected, and not have sprawling sections away from the rest of the space.
Good notes about not being port-specific with feature use. I can remove the beam of light for the final release. One other thing I learned with my last map is that DM servers which transfer maps automatically don't transfer the .lit file, which I forgot to test this time around. Is there a command to shut off colored lighting in QS so I can toggle that?
Re: Weapons... Will definitely up the ammo for nailguns. I'm sure I can figure out an alternate location for the Grenade Launcher to spread out the explosion stuff. The absence of the LG is a selfish point, but intentional. I play DM with my kid, and so far the LG seems to be a destabilizing element when we play, leading to frustration. But I can put one in the public release, I suppose. Suggestions on location for that?
Re: Arcane Magic... had I but known! Definitely will fix the runes. To be clear... does the proper alignment mean the bottom of the texture (as it appears in the texture window in editor) should be in front of the player as they appear, or should it be the top of the texture?
Re: Adding SP Stuff
So... I don't have a lot of experience with SP yet. So I have questions.
Do you think this map would be very interesting for a single player setup?
It is preferred these days to make a map that does both, or it is acceptable to rip out all the entities and do a separate release for an SP version?
Is this map big enough to contain a satisfying single player experience? Seems small. Do I extend it with changing elements within the same space or building out new areas? What are your recommendations?
I don't know the command to disable colored lighting, but you can rename or delete the .lit file before loading the map to test it.
LG should probably be as far away from the RL as possible (including lifts/teles). Usually there is one in a DM map, I think, but don't feel like you need to add one just because I said so.
Doesn't really matter if the runes point forward or backward. I mean, most player probably wouldn't even notice it if they are sideways. Only mappers may cringe a little bit. :)
As for SP mode, I would say it's always possible to have some monsters and specific progression like (key) doors, activatable lifts etc to add some extra flavor to the map. It won't be the best SP experience, but people who don't care about DM can still enjoy the map then. Check out the DMC maps for simple yet fun conversions.
Cool, I will give these a play. I've done a lot of digging since returning to the community, but there's always something new to find it seems.
Again- thanks for your feedback. Very good recommendations. Much appreciated.
Ok, this has been a good beta. Revisions include...
New wall textures, some fixed geometry, ammo adjustments, moved one weapon for spacial balance, teleporters triggers extended a bit, removed some graphical features that won't be available in minimal-feature clients commonly used for DM, and yeah... I think we're good.
Oh, and the teleporter pads are arrival-view-aligned for optimal ArcaneMagic(tm) performance.
Now thats my final release of "Temple of doom".
Thanks to Daz, Dumptruck_ds, Esrael, Reyond and Roman De Renard for Tips and testing. Hope you enjoy it.
You forgot to include your skymap files. Can't load your map.
Also please name your readme with the name of the map.
Can I delete the old file from quaketastic?
Final Release Second Try :)
Uuups! Sorry. skymap was missing.
Now it should work. :)
Any volenteers for testing a startrack demo
I'm still working in progress, and I could use some adfo about how the map feels.
I Love It
I hadn't noticed, it suits nice. For viewing it has a smooth look. A bit concerned about the UV files, as I never had chance to make use of it.
You should submit a news post with your Temple of Doom map. It's lost in the mix here! Click on the tiny Submit News link on the upper right hand side of the top post on the News Page. A mod will review your post and it will be featured in the news items.
Beta Map Release
Normal Difficulty Run
Hi nolcoz! Great job on completing your first map. I've recorded a demo of my blind run on normal mode (using Quakespasm).
In general, I found there was probably too much ammo relative to the number of monsters you have in the map. I was nearly always full on shells and spikes. I ran out of spikes once, but there were rooms nearby with tons of ammo.
For the encounter design, it looks that in general I'm only fighting one type of enemy at a time, and that they come in waves. This made most of the map quite easy to overcome, as there was also generally a lot of room to run backward or strafe around a room to stay out of the way of both projectiles and melee.
To break that up a bit, consider mixing encounters with various enemies. On normal mode, it's nice to feel like we're not running out of ammo, but there's no tension if player has plenty of room to move and are always fully stocked.
Conversely, the first encounter in a small, dark room with two Vores in it takes the difficulty way up. I would suggest: turning the lights up a bit in there, and only have one Vore on normal mode. Opinions may differ on that, but I if you want to keep the difficulty up, consider a Vore and some other monster to go along with it. Whenever a Vore launches a Vore-ball, that's basically another enemy in the room. Given how small the room is, I'm not sure that's appropriate for Normal mode.
As for archicture: love the progression. The rooms are simple, but you're using a lot of interactive elements and surprises. I liked running around in it.
There's one area (upstairs near the Shambler fight) where are a bunch of electrical devices. I'd love to see a little glow around those electronics that shed a tiny bit of light on the geometry around them. And it seems a missed opportunity not to put a little damage trigger on those, so that running around to avoid enemies isn't completely free. That could spice it up a little.
Once again, great job! Looking forward to the release :)
Demo link: http://rhoq.ddns.net/archive/demo/tsotm_rhoq.dem
Thanks for the feedback!
I will try to keep in mind what you said when modifing
Second Beta Release Of The Secrets Of The Mansion
I have finished improving the map according to what I have been told
Tell me what you think, and I hope you enjoy it :)
The updates feel good. Lot more challenge, and it increases steadily throughout the map. That's good stuff.
Finished with 1/4 secrets :)
If you haven't seen it already, dumptruck_ds's YouTube channel has lots of additional instructional videos on Quake Mapping. Here's one on steps for releasing you map. Good luck!
Thank you for testing the map and telling me what you think about it. :)
I do know about dumptruck_ds mapping videos, in fact I am subscribed to his channel.
I am gonna wait before submitting it to quaddicted to see if someone else can playtest it and give me their opinion about the map.
I'll try and load your new version up tonight.
I think I'm really done, but that's my own opinion.
It could be someone else is'nt.
So here's my humble request.
I have the next couple days off work so I will have the time to record a demo and write up any thoughts!
Motorcycle must be made tangible
The sounds are terrible, especially when they are on their own in empty corridors.
Orb hung in the air
Elevators without sound
Many different screens on the walls and it is not always clear where the screen is, and where the button
One of the dying monsters has the sound of a body breaking. Not very logical.
The big teleports looked very strange. Which of them worked can be guessed only by the sound. And it does not always work. You have to leave and come back again.
I was able to climb onto the roof of one of the elevators
I could not find the blue key.
In my opinion, the main problem in the sounds. I had a feeling that they live their separate lives.
Thanks for the respond!
I found myself whole night recording a demo and I just wasn't capeable. Oh my.., then I fixed the bouncing boxes of the monsters and suddenly they stopped shooting in wrong angles.
When I finely succeeded the scorpio blew out the game for having no throw_gib head. I never understood why this error ocured. Bad coding.
Where can I find motercycle
I replaced the orb several times but it won't fit, I know.
When it is not teleported it suits fine.
And yeh, the lifts are a mesh, I had to use one lift on multiple floors,
but couldn't catch the code.
It is like the sound channels overide eachother,
as only a first strophe is produced.
I'll have to oversee the ambient_sound.
Here's a new link
and a demo
Watching the demo I understand your concern.
The sidewalls of the teleporters hide the barrelgun and nailgun.
Now it's too obvious how to use them when the rangorder isn't clear.
I'l see a way to get around it.
Final Release Of The Secrets Of The Mansion
The final version of my map is now on Quaddicted.
Thanks to Rhoq for tips and testing.
Hope you enjoy :)
Sorry I didnt see it.
It has been a while since I entered the site and I didnt know that new maps get threads in the news section.
Thank you for telling me.
Skill 1 demo
- I got completely lost for a bit trying to find the silver key. I think it should be out in the open, or the shootable texture should look more...shootable.
- Eyeballs stuck in the ceiling.
- I agree with Digs that the buttons could be a bit more distinguished as buttoms, maybe with a prodruding keyboard or something.
I liked the rats! Once I realized they don't attack, I tried not to shoot them... unfortunately Quakeguy has to trouble stomping on them with his boots. :(
Thanks For The Advice
Orientation isn't my best part here, I know. Some arrows could relay better game flow. Don,t know what happens to the Orb, must have something to do with the bouncing box. Great you took some time for a demo, I'll see to it.
Gif's only show half, here are models I converted by scaling them down to 25% and then hussle with a frame to obtain a base file.
The texturing is not so good, but I think they would fit in an chasm/quake mod.
That's A Lot...
...of jitter. :^[
I could blame myself, but it is the damage that implies scaling objects to Quake dimension.
Silent Blood (WiP) - Announcement
(previous working titles: Transfusion, Bloody Hill)
Quake map with Silent Hill vibe and Blood textures.
I want to make a moody map with thick atmosphere. It has realistic design, reminiscent of Half-Life, and tons of fog. Monsters are scarse, but there are plenty of explaration (the fancy word I use instead of "walking") and... gulp... text messages (each book you see can be read).
I want to implement custom sounds, but they are not necessary (it'd be awesome to make phone ring). Also shooters came up to be much harder than I thought. I made the 1st half of the map and stuck on the 2nd.
I also think about making Nightmare difficulty infested with monsters (for those liking more action in their Quake), but it's just an idea.
P.S. Some textures got off.
P.P.S. I wrote "alpha" incorrectly >_>.
yes, this no monsters thing certainly isn't everyone's cup of tea
Looks pretty cool. I am not always into these types of maps that fall outside of the regular themes. BUT this does look very promising. I'd suggest you take a look at my progs_dump dev_kit for custom sounds and lots of other features. I am working on a new version but it is still weeks away. http://www.celephais.net/board/view_thread.php?id=61633
Are there new AI for the chasm monsters?
The Lizzard and Scorpion have, but that's because I made them myself first, before you aimed at the gl models.
The others are still to come, but the skin file is hard to obtain by finding a right pose for the base file.
Do you think the downscaling has a bad effect on them?
I'm such a bad coder.
Thanks, you're always so helpful.
Only around the mouth area of the faust and alien captain, improve the mouth and it will be fine.
Keep Q1SP WIP
Looks great! Love coagula maps.
That Looks Funky For Sure.
Some Wip Stuff
Use Quaktastic Mfx
Looks amazing! What is it??? Tell us more.
Just Doodles Advanced
maybe an episode?
mfx: love the Ikwhite shot, concept and style are great.
qmaster: Egyptian stuff is always epic, concept and style looks great here as well.
Upside-down temples ftw!
Your Coagula maps looks insanely intricate!
@qmaster & Mfx
honestly super stoked on the look of that rubicon2 themed thing most, never get tired of that theme!
|2 posts not shown on this page because they were spam|
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.