Comments

I noticed a few things while looking into the various .rmf file versions:

• VIS group colors appear to be stored as RGB, not RGBA - the 4th byte is always 0 in my test files.
• In v1.6 and v1.8 files, colors are stored as BGR, not RGB.

An entity can be marked as 'primary' by giving it a _mess_merge_entity_master attribute. If a group has no master then the attributes of the first entity will be used, but it would probably be better to issue a warning if that group contains entities with different attributes.

As for the future of MESS, the big step with v1.2 is that instead of macro entities and a scripting language that is geared towards technical users, there is now a set of template entities and automation scripts that anyone can use. I intend to add and improve template entities when new things come up, such as Erty's func_illusionary + hlt_noclip 1 discovery. But I've also got ideas for new features, such as a geometry API that lets you generate brushes, and support for reading textures and models. Think of automatically covering brushes with thin extruded overlays with additive textures, or generating clip-brushes for prop models, or maybe even generating models from entities. Other ideas are things like issuing a warning if a func_ entity with a transparent texture doesn't have the right render mode or FX amount, or if a map transition uses an uppercase map name. Oh well, we'll see.

@The WON Guy: that's strange. Could you send me one of the images that's giving you trouble so I can have a look?

Instead of manually placing all these entities, I have written an automation tool named MESS that can generate this entity setup from a single mtl_trigger_random template entity. It also uses less entities than the setup in this tutorial by giving the func_buttons carefully placed origin brushes, so there is no need for info_targets.

Note that the 'Random strike' flag is not required for random targeting - it randomizes the time between strikes.

An alternative to manually placing all these entities is to use mtl_trigger_random, a template entity that comes with MESS, an automation tool that can generate entities for you. One added benefit is that mtl_trigger_random produces less entities by giving the func_buttons a carefully placed origin brush, which removes the need for info_targets.

Hey Windawz, just wanting to let you know that this tutorial inspired me to add a brush-merging mechanism to MESS: https://pwitvoet.github.io/mess/covering-terrain-optimization.html#merging-props - so thanks for writing it!

Ah, more tools!

A few notes though: texture extraction doesn't extract anything if no pattern is provided, and I'm a bit puzzled as to why sprite decompiling produces a sprgen .qc file - is anyone still using that nowadays? As for easy-to-use sprite/texture tools, what about Half-Life Texture Tools and WadMaker/SpriteMaker? They both support sprite and texture extraction.

Good job!

I wanted to point you to https://github.com/LogicAndTrick/sledge-formats/tree/master/Sledge.Formats.Map/Formats , but it looks like Penguinboy already started updating some of the wiki pages. He knows more about the various .rmf file versions and figured out the meaning of several more .jmf fields.

Regarding wad files, as far as I know palettes are always preceded by a color-count int16, and the color-count + palette colors should be padded so they're 4-byte aligned. In practice most if not all palettes just contain 256 colors, so I'm not sure whether textures with smaller palettes would even be accepted by various tools. But yeah, `Palette[width][height] palette` should be `char[colors_used][3] palette`, and each mipmap is 4x as small as the previous one.

A few years ago, the author, Dave Johnston, posted some corrections about these tips on his blog: https://www.johnsto.co.uk/blog/51-editing-tips-errata/

That's a very nice showcase map!

This competition was a lot of fun, with a lot of great entries. There's something about having a deadline (and an extension!) that spurs creativity I guess.

Half-Life texture sizes must be multiples of 16 (16, 32, 48, etc.), that's simply how it is. However, it might be safer to stick to powers of 2 (16, 32, 64, 128, 256, 512, etc.) to avoid scaling/performance/mipmap issues on certain GPUs (I don't think such issues will be very significant, but hey).

Also note that the maximum texture size is 512x512 (1024x256 and 2048x128 also work, so the actual limit is probably something like '262144 pixels').

A happy belated birthday to you!

The brushwork/geometry looks impressive, but the texturing is somewhat bland. Maybe that rock texture works better when it's scaled up so that it complements the geometry instead of making it look repetitive? Or perhaps you can find a rock texture with different layers, like the real mesas such as here or here. The center of the map could also use some changes to make it more 'readable' - a couple of big boulders separated by patches of sand should be easier to navigate than a big mass of brown rock.

I also feel that this map needs a clear landmark to make it more memorable and to prevent all sides from looking too similar. Maybe a radar tower or some other man-made structure, something distinct.

"It happened again." - "Just one of those days I guess."

Happy resonance cascade birthday!

That picture is obviously an abstract representation of a tile-based platformer game. One of the most well-known platformers is Super Mario Bro(mine)s, which was released in 1985. However, there is no sign of a level exit, so the blue protagonist is clearly lost. This leads us to Super Mario Bros: The Lost Levels, which was released in 1986. Happy 35th birthday!

Oh, nice! I really like your idea of of using _dev entities for test builds. I'm sure your script would be useful for some people.

This is giving me some ideas for improving MESS, a compile tool I made a while ago. Automating and speeding up the level-design process is an important reason why I made tools like MESS and WadMaker (and SpriteMaker, soon), and I'm thinking about making a 'smart' compile script that only runs csg with -onlyents if it does not detect any brushwork or lighting changes since the last compile.

It turns out that the only color in the palette that has any effect is the last one (it determines the overall decal color). All other colors are irrelevant - there's no need for black-to-white or white-to-black gradients, although gradient palettes can be useful for certain workflows, and helpful when viewing decals in Wally or Hammer. What really happens is that Half-Life uses the image data as an alpha channel, instead of a set of indexes into a palette.

WadMaker, a command-line wad-making tool that I made, can turn 32-bit images into decal textures if the output wad name is 'decals.wad'. It'll use their alpha channel to create the decal, and the average color of the image to set the decal color. To add textures to decals.wad, first drag decals.wad onto WadMaker.exe - this will extract all decal textures and store them as png files in a 'decals_extracted' folder. Rename the folder to 'decals', add your own images, then drag the folder onto WadMaker.exe - this will update decals.wad with your new images.

I think the small, square layout is fine - it's guaranteed action even with a small number of players. I like how some weapons are put in vulnerable spots (top of the crane, inside containers), forcing players to take risks, and how the water pool warns nearby players when someone picks up the AR2. The map also feels like a believable place.

What I like about the outer wall is how you chose a distinctive color to mark the boundaries of the playable area. But it's too thick for sheet metal, and there's an invisible wall above it. Putting barbed wire on top of it would make it clear to players that they can't jump across.

I'm not sure about the underground hallway. It's a bit too disconnected from the rest of the map, and with a charger, infinite ammunition and only 2 entrances that offer no cover, it's probably an overpowered camping spot. If only other players could flood that room to discourage such behavior...

The fenced area next to the crane is a bit confusing to navigate - it's a bit of a dead-end and the 'exit' isn't easy to spot due to the low contrast between fences and the dark wall behind it. The nearby shed is also a bit too dark for my taste, especially because the wall behind it is also dark, so players silhouettes won't stand out against it either. The ladder to the top of the crane isn't clearly visible and it doesn't extend all the way to the bottom, so it doesn't look climbable. The crane base is also hard to get onto, as you can only crouch-jump onto it from a few specific places. Either make the platform visibly unreachable, or make it reachable from everywhere. The platform and its sides also disappear when you look at it from certain angles (because it's a single brush, and its faces are one-sided). It also looks like you could crouch underneath it. Maybe make it darker and put some concrete underneath it, to make it more visibly inaccessible.

Finally, about the 3D skybox, I'm a bit worried about an oil refinery being located in the middle of a residential area. It would be more believable to have residential buildings on one side of the junkyard, and some factories on the other side, with a refinery further away in the background.

Sounds like you'll be working on some pretty cool projects. Congratulations!

So... that nuclear sign in The Core Decay's logo... getting 3DRealms' attention was the plan all along, right? ^_^

I really like this map from a technical point of view. Excellent use of models! The 3D skybox with moving clouds, the sun reflection on the mosque's domes, the breakable awnings, all the other props... especially the skybox makes this map look a lot more modern. What was your workflow? Did you export the map to a modeling tool and then create the skybox around it? Why did you combine several props into one model?

I'm not really a CS player, but it looks like all those extra nooks and crannies will result in more cautious and campy gameplay. I think the rooftops will play a bigger role in the HLDM version, where the longjump and gauss make them more accessible. The hidden weapons in both versions are a fun touch.

As far as performance goes, r_speeds range from 2K wpoly's to 5-6K in certain areas, but it runs fine on my (fairly new) system.

My only 'complaints' would be that the exact boundaries of the playable area are sometimes unclear (invisible walls), especially in the _se and HLDM versions, and that the crispness of the shadows in the 3D skybox doesn't match the more blurry shadows in the rest of the map. And in the HLDM version, a lot of the pickups are off the beaten path, often requiring several crouch-jumps, which might hinder the gameplay flow and will probably also make the map harder for new players. On the other hand, even the strongest weapons can be found in multiple places, and with all the connections between areas action should never be too far away, so it looks like a fun map to play in.

I really like the whimsical setting of this map! It's like falling down a rabbit hole and ending up in the underground botanical gardens of a mad scientist. Speaking about rabbits, it reminded me of the 'Fanolint' levels in the first Jazz Jackrabbit game.

I agree that, in its current form, it's not really suitable for DM. The layout is too linear and the doors, narrow doorways and various protrusions hinder fast movement. If you want to make a 'proper' DM map, I'd suggest creating a 'blockout' level that focuses entirely on layout and gameplay. Keeping it visually simple allows you to make gameplay tweaks more easily. Once you're satisfied with the gameplay, start decorating it, using this map as a style guide.

As for optimizations, maybe you know some (or all) of this already, but just in case, here are some of the things that you can do:

• reduce texture scales on large, far-away surfaces (faces are split every 240 texture units)
• use func_detail instead of func_wall (entities are drawn entirely even if only a small part is in the visible area, whereas func_details become world geometry)
• replace certain details like plants and stones with models (model rendering is more efficient and allows for finer details)
• use the gl_wireframe 1 console command to look for areas with lots of face splitting (typically near rounded shapes), and see if you can reduce that with a func_detail or some other trick
• use less faces on rounded shapes, especially ones that are never seen up-close (such as the blue overhead pipes)
• if you start a 'blockout' map, use gl_wireframe 2 to see which areas are visible at any given moment, and adjust the layout to ensure that not too much it visible from any given position (maps often use U-bends in corridors to block visibility between areas)

Hao jiu bu jian, haha!

Thanks! She's 2.5, old enough to talk all day long, do jigsaw puzzles and make abstract art. It's a joy.

Happy testing day! I mean birthday!

But... how old do you expect you will become if you felt the need for leading zeroes?

@Hardian GT: for questions like these it's better to make a topic in the forums, or to ask on the Discord server. Be sure to explain exactly what you're doing, or upload your map so others can have a look at it.

DC4... DCIV... congratulations with your... 604th birthday?
What do you mean, 'you're off by a factor of [RECORD SEPARATOR]'?

@Hardian GT: see the notes at the bottom of the monster_osprey entity page: you'll need a monster_osprey that targets a path_corner (which needs to be part of a cyclic route of path_corners), and at least one monster_human_grunt.

Your son is doing a good job, but you... I think you're getting older.

Now I wonder whether I'll have the same 'problem' with my daughter 10 years from now, heh.

@Masta_Frank01: thanks! Gravity is set to 0.5 with a trigger_gravity that covers the entire playable area.

@Saw: those includes must be put in the same file as the rest of the code, so if you've created a new .cpp file for your NPC, then yes, they should be put at the top of that file.

Note: I made this example based on a forum question by mahagon.

Nice! I noticed that zhlt_usemodel also ensures that the 'template' entity whose sprite or model is used will be put before the entities that use it, so the map won't crash because the sprite or model hasn't been loaded yet. If you use model instead you'd have to be careful to create the sprite/model entity first.

That's a lot of high-quality maps! Some interesting gameplay mechanics and ideas, and the level of detail in some of the maps is just excellent. I've tried to summarize my thoughts on each map:

Warm welcome: I like how the gameplay mechanics were communicated through visual clues (red lasers + red glow on turrets, orange pipes).
Pest control: The cubicles combat area setup was nice, with vorts being able to flank the player. Standard HL gameplay but nicely done.
Phantom lab: Visually very nice, good use of available space, also good use of satchels/tripmines. I wasn't expecting a hidden item search and found the G-man sequences a bit too long, and the intro was weird, but a great map nonetheless.
The tomb: Fun introduction and great atmosphere, especially the 'artifact grab' and the cheesy 'ending'. Instakill traps were a bit frustrating, but still a fun map.
Cargo specimen #798: Interesting monster use. It wasn't always very clear how to proceed though. The start and end 'sequences' were a fun touch.
Food court: Finally, after all these years, Gordon gets to eat something besides medkits and morphine...
Half-Pint: Fantastic! Manages to be both predictable and surprising at the same time. Definitely one of the highlights of this mappack.
Memories: These kind of maps aren't really my cup of tea.
Orange corp: Nice visuals and 'storytelling' that builds up suspense before the final 'discovery'.
Tele office: Visually more basic, but the combat and especially the 'finale' were actually quite fun.
Training course: Refreshingly different in style. Combat was maybe a bit too though but it was never dull.
Smash & grab: Very well done. Visually appealing, distinct mechanics that were clearly explained, and not too easy either.
Saviour?: Good sense of place and level of detail. Interesting use of windows and layout, so the player can see the AI taking initiative, which makes them look smart.
Xen garden: 1/10 would never relax here again. 'domesticated' headcrabs, yeah right... But seriously, this one looked very pretty.
Apartments: I don't like horror maps so I skipped this one.
Not much of a turnabout: That's a cool little detective story. Very nice!
Headley & Crabb: Not bad visually, but not the most interesting combat-wise. I'm not sure why Barney was hostile?
Darkwoods penitentiary: Not really my style, but I'm glad I stuck around to see the ending.
Flippant: An interesting idea, but enemies were rather difficult to hit (due to a hitbox issue?) and combat was too hard overall for my taste.
Von Braun: This floor felt like a different game altogether. Very well done. The hint system was a good idea, given how little 'room' there was to introduce the different gameplay mechanics.
Cupid's queue: A bit rough around the edges, with some rooms not making much sense. I did like how it gave you a glimpse of the secret cd.
Trial by fire: More horror, so another skip for me.
Hard inferno: Nice idea about exploration versus direct confrontation. Ending was pretty frantic.
Repechage: Visually very pleasing, interesting gameplay mechanics, chock-full of secrets, but above all, great fun to play. One of my favorite maps in this mappack.
All foyered up: Visually very nice (chrome tv effect!), but the final room felt a bit too cramped for a grande finale.
Cenodrome XL: I'm not sure whether I'd be able to beat this without cheating, but it's an interesting idea for sure. The connection with Repechage is a nice touch.

...

What's with all these weird comments on decade-old journal entries?

That's a nice piece of work! Going back to low-res HL textures was a bit rough, but the improved architecture and overall character of the map more than made up for that. There's a much better sense of place now compared to the more generic warehouse style of the first version.

I especially like how the first grunt encounter was redesigned. You can now sneak up on a grunt, only the be caught by surprise by grenade-launching grunt on the other side. Gave an interesting dynamic to that fight. The area also looks more like a real functional place than v1.

Some of the other enemies felt a bit dumb though, just passively waiting around a corner until you show up. It would've been nice if the grunts in the control room had acknowledged your presence in the bridge room somehow - a 'Freeman!' shout, a gesture, one or two grunts running around. The fan obstacle setup was better in v1, because the obstacle was visible before the solution was. In v2, I first pushed the button, then found the vent, and wasn't entirely sure what that button had done.

But other than those minor issues, it's an enjoyable map and it shows good attention to detail. I like how you create ladders - much better than the standard single-brush approach. Also, '86 was a good year indeed! Now I wonder whether there are any other easter eggs to be found...

So basically, instead of the CSG/BSP/VIS/RAD pipeline, you're only using a VIS process, at the expense of having to manually set up visibility areas? That's an interesting idea. I wouldn't be surprised if applying this to HL would result in similar performance to what you'd get from the 'traditional' approach.

VISPORTALEXIT seems similar in purpose to HL's SKY texture, with anything outside a VISAREA basically ending up as part of a 3D skybox. As for portals, can't you derive those automatically from where two VISPORTAL brushes are touching or intersecting? That would simplify the level-design process somewhat.

Congratulations with your I have no clueth birthday!

Thanks for the kind words. That waterfall is actually on purpose - it distracts players so others can activate the trap in that room! Nah, I think I just forgot to put a rock there.

Turns out I still had the map somewhere. Download is fixed now, have fun.

Happy (...counts number of ridges...) 119th birthday!

The 3-point format takes more space and requires more work to load (for the CSG tool) than the normal+offset format (which is what CSG uses internally), and it's a plain-text format, so I'm not convinced that saving space was much of a concern in this case (not for .map files anyway, .bsp is a different matter). Both of these are about equally bad for a map editor - I don't think there's a way to derive vertices that's better than O(n^2). Fortunately most brushes have a small number of faces so it's not as bad as it sounds, but still, there's a reason why editor-specific formats do store vertices.

Oh, I just found out why brushes are called brushes: Carmack felt that CSG was like painting with a geometry brush. I never thought about it like that.

I ran into this when I started working on MESS - .rmf files store a nice list of vertices for each face, but .map files only give you a bunch of planes to work with. Which is annoying, because you need to have vertices if you want to check whether a brush is inside another shape. But once you have those vertices, the convex nature of brushes makes things easy: anything that's on the 'outside' of even a single face plane is outside the brush. With concave shapes that is (a lot?) more complicated.

But did they really choose planes to save on storage space? If that's the case then why didn't they store them as a normal + offset? I think they used planes because it more naturally fits the CSG and BSP processes.

Ah yes, the lesser known Shakira single.

Yeah! That, and Jenny from the (cinder) block, those songs were solid.

The holes in those carefully arranged bricks... you must be... 38!

That means your biography is 20 years out of date, so you must've written it 16 years before joining. That... makes total sense. Yeah. Bricks don't lie!

Thanks! Yeah, I definitely want to get this done.

I just finished integrating the scripting system and implementing transformation of template contents based on the scale and angles of a macro_insert entity. Here are 9 instances of a recursive template, each with a random direction and scaling factor:The template only contains a single brush, a light entity and a macro_insert entity that's wrapped inside a macro_remove_if entity, to prevent the template from expanding indefinitely. I don't think the other compile tools will handle this sort of brushwork gracefully, but hey... it works!

To stick with the Minecraft theme: happy dandelions day!

Well, that was fun! I found all but 6 on my first run. Then I cheated with the R_speed Epoly Detector (tm), but still couldn't find all of them...

One thing I noticed was that the detailed nature of the map and the gameplay made me expect the environment to be much more interactive than it was. I think it would really add to the map if those lockers and file cabinets could be opened, and if those soda-machines would actually work.

There were two rats that felt a bit unfair: The cupboard doesn't look like it has doors, they're difficult to open (they don't react to the use key, and can only be touched by crouching), and almost nothing else of that scale is interactive. The two destructible vent grates in the machine room look solid, but all other solid grates are indestructible.

But all in all, a good-looking map with unique and enjoyable gameplay.

When you gotta go you gotta go.

I wish I knew about this when I picked a nickname all those years ago, but oh well. That's what happens when your first name starts with a P and English isn't your native language. Fun fact: the place where I live used to be part of a separate kingdom, hundreds of years ago, and it still has its own anthem. The most popular parody on that anthem (the only version I can remember) is - indeed - about having to pee. So there's a connection after all, huh.

"Shotgun lessons are next."

Plush shotgun shells? Those pack quite a punch. Either way, nice headcrab there. And wow, your son is growing up fast.

@Rimrook: Welcome. Welcome to ModDB.com. It's safer here!