pwitvoet / mess Goto Github PK

I find the recurring need to disable/enable certain rewrite rules. I figure just invalidating the starting block e.g. @///mess ... would work but the dangling ending block @mess; ended up bypassing all subsequent blocks. So I had to invalidate the ending blocks as well e.g. @///mess;

I thought the parser would not match a block until it finds a starting block but apparently the parsing works some other way.

I'm writing this issue to take note of this behaviour. Preferably the parser should ignore dangling ending blocks, or in other words only start recognizing it after a starting block. Otherwise issue a warning a console.

Built-in compile runners in editors like Hammer and JACK can be made to check that a file with a particular extension is produced after a compile tool is run. This is to check whether the compile step succeeds or not, and whether to proceed with the rest of the compilation. Most of the time it's a requisite file for the next compile tool (e.g. portal file for VIS) and proceeding without the file will just make the next compile tool fail, so this feature stops the failure early.

I propose MESS produce a dummy file for this purpose. The presence of the file signals to the compiler that the compile succeeded and compilation can proceed, because as of this moment the compile continues even when mess expansion fails, and this can cause cascading failure that may produce a finished BSP but actually crashes the game when run. ATM MESS may exit with code > 0 but Hammer/JACK compile runner doesn't appear to check these.

I am developing brush prefabs that uses MESS. I find that the classic point entity size() bounds inadequate for true visualization of the prefabs positioning in a level as it does not rotate with the entity angles. So I decided to compile a static mdl of the prefabs and reference them in the .ted entity's studio() attribute.

File structure:

<location of mess>/template_entities/custom/
  ├ my_prefab.map
  ├ my_prefab.ted
  ╰ models/
      ╰ my_prefab.mdl

Entity definition in my_prefab.ted (yes, absolute path absolutely works in JACK!):

@PointClass 
	studio("<location of mess>/template_entities/custom/models/my_prefab.mdl") 
	= my_prefab : "a very cool prefab"
[]

Now, the very clear disadvantage of this is that there is no way to make this work unless the path is absolute, as the end-users could have installed MESS anywhere in their filesystem.

If there is a way to rewrite .ted entity definitions as it's copied to mess.fgd, with the same functions exposed to it as MESS rewrites, this could finally be made portable. Something along the lines of:

@PointClass studio("{ted_dir()}/models/my_prefab.mdl") = my_prefab : "a very cool prefab" []

...which then resolves to the aforementioned path in mess.fgd.

If this feature can be implemented expeditiously I would be truly grateful. Currently two of my prefab projects (one update, one new) would benefit greatly from this. 🙏‍🙏‍

I'd like to have a setup where I can verify that MESS is laying out mtl_* entities properly, before proceeding to expand the mtl_* entities. For this I had to repeatedly edit my .ted file to disable and reenable the rewrites which is tedious.

Having a command line switch to disable entity rewrites would be much helpful. From reading the docs such feature doesn't exist yet.

Thanks in advance. 🙏‍

MESS says ----- BEGIN MESS ----- like the compilers do, but it doesn’t say ----- END MESS -----, unlike the compilers, which isn’t consistent, makes it a bit hard to distinguish where MESS ends and HLCSG (or whatever is next) starts, and can make the user thinks MESS somehow finished unexpectedly.

New command line switch proposal -recurse n

Unlike -maxrecursion n that fails if more than n recursion is detected, this switch does what it says on the tin – recurse exactly n times and then stop.

This would be useful for map debugging by allowing mappers to observe the effect of each step of the mess inserts.

Say I want to use one keyvalue to store information in a bitwise fashion, just like effects (entity effects). Currently bitwise operators are not implemented in mess except for spawnflags, and you're left with only modulo (%) for reading bits.

Implementing the standard bitwise operators into mess would be of much benefit imo. I don't mind it to be a much later feature on the timeline since I don't plan on using it much to write bitflags, just read (which % can do). But that could change if more people uses mess, who knows.

As it is now, the entity's namespace scope is directly pointed to that that of the calling macro_insert & co. This creates a lot of duplication that opens the door to bugs.

Suppose the following setup:

• a macro_insert with following keyvalues
• • brushtemplate = 1
• a func_door with following keyvalues
• • targetname = {'brushmodel' if brushtemplate else ('brush' + iid())} (Expr. 1)
• • target = {'walltogglemodel' if brushtemplate else ('walltoggle' + iid())} (Expr. 2)
• a light_shadow that targets the func_door. it has to duplicate the exact same expression:
• • target = {'brushmodel' if brushtemplate else ('brush' + iid())} (Expr. 1 repeated)
• a func_wall_toggle
• • targetname = {'walltogglemodel' if brushtemplate else ('walltoggle' + iid())} (Expr. 2 repeated)
• repeat with as many entities that may need to target each other

The proposal is to add another namespace scope that precalculates all the unique values that entites in the template might need. Suppose we add this support to macro_template itself, or a new macro_keyvalues inside the template with the following keyvalues:

• macro_template or macro_keyvalues
• • doorname = {'brushmodel' if brushtemplate else ('brush' + iid())}
• • walltogglename = {'walltogglemodel' if brushtemplate else ('walltoggle' + iid())}

These will be evaluated first before any entity in the template. The entities in turn can reference these keyvalues:

• func_door
• • targetname = {doorname}
• • target = {walltogglename}
• func_wall_toggle
• • targetname = {walltogglename}
• light_shadow
• • target = {doorname}

Now the expressions in the entities are much cleaner and less prone to bugs, because we calculate the values once per instance.

I think it’d be best if macro_insert entities had the standard 16x16x16 size. As of now they take quite some space and stick out of the others, which doesn’t look tidy with complex entity setups.

Let's say I pass a keyvalue to a macro_insert whose value is the name of an entity. Then inside the template a custom mess point entity, or a _mess custom keyvalue, takes that value resulting in an entity already present in the map, with that name, being "pulled" into the instance and replaces the point entity.

A use case of this are templates having ambient_generics or env_sprites. Rather than exposing every keyvalue and flag for those entities to a .ted entity or a macro_insert's keyvalues for maximum customizability, you just give those a name of an external entity to be used in its stead. A sort of BYOB but for entities, if you will.

Just reposting previous suggestion in TWHL as GitHub issue: https://twhl.info/thread/locate-post/345813

• Make the macro_insert scale property a vector, so you could stretch one axis, and flip another axis.

When used inside a template, the id() function should return the targetname of the macro entity that is creating an instance of that template. id() should only return the numerical ID of the current instance if that macro entity does not have a targetname. However, it currently always returns the numerical ID.

Workaround: instead of {id()}, use {targetname}, or {targetname or iid()} if the targetname may be empty and you need to fall back to the numerical instance ID.

on some not very rare cases an entity might be missing the angles property and that breaks expressions that read it or its component e.g. angles.yaw.

my suggestion is to always have implicit default value for angles of 0 0 0. This is what the game engine already does in a way, both origin and angles are implicitly 0 0 0 if absent.

I've used two macro_brushes that should combine into one entity using _mess_merge_entity_id. For one of them I passed a merge_entity_master = 1 to mark it as master. then on the brush entities in the template I have _mess_merge_entity_master = {merge_entity_master} but apparently this doesn't make this work. I had to redo the parent template so that the one not being master is a later entity in the .map's entity list.

It seems to me that the existence of the keyvalue makes it a master even if the value is none. So I had it rewritten to {merge_entity_master ? '_mess_merge_entity_master' : ''} = 1 though I dunno if it is the intended way since I've solved my problem another way.

The docs don't have an example on how to do this. A clarification is appreciated.

When trying to use a cs_trigger_roundstart entity, the following error is thrown, causing MESS to fail:

Failed to process macro entities: EvaluationException: 'A function call requires a \<function\>, not a \<none\>.'.

This can be solved by replacing the contents of template_entities\cs\cs_trigger_roundstart.ted with the following:

// This entity will trigger its target when a new round starts.
//
// @MESS REWRITE:
// "classname": "macro_insert"
// "template_map": "{ted_dir() + '/cs_trigger_roundstart.map'}"
// @MESS;
@PointClass size(-8 -8 -8, 8 8 8) color(255 127 0) = cs_trigger_roundstart
[
    target(target_destination) : "Target"

    spawnflags(flags) =
    [
        1 : "Skip first round" : 0
    ]
]