MRVN-Radiant / MRVN-Entities

MRVNs and Pilots writing fanfiction together
1 stars 1 forks source link

Editor-only entities #7

Closed snake-biscuits closed 1 year ago

snake-biscuits commented 1 year ago

Earlier today I copied simulacrum/ into MRVN-Radiant's install/gamepacks/ (locally) While making sure I wasn't replacing anything defined in the previous entities.ent for each game, I noticed func_occluder

This entity is not added to the .bsp's entities when compiled, but instead flags geo for occlusion meshes[^remap_r1o][^remap_r2][^remap_r5] I moved func_occluder to editor.ent to preserve it Shortly afterward I realised editor.ent could hold prop_static, func_detail, maybe even func_instance[^vdc]

MRVN-Radiant would detect these entities in remap[^remap_r1o][^remap_r2][^remap_r5] & compile them into the appropriate .bsp lumps Any editor.ent / Internal Entities would need to be hard-coded into MRVN-Radiant So maybe editor.ent might be better off as part of MRVN-Radiant directly

[^vdc]: Valve Developer Community - Category: Internal Entities [^remap_r1o]: MRVN-Radiant on GitHub - tools/remap/source/titanfall/titanfall.cpp:187 [^remap_r2]: MRVN-Radiant on GitHub - tools/remap/source/titanfall2/titanfall2.cpp:201 [^remap_r5]: MRVN-Radiant on GitHub - tools/remap/source/apex_legends/apex_legends.cpp:167

snake-biscuits commented 1 year ago

Whether or not we add this depends on #6 editor.ent could be populated by pilot/*.json with Block set to editor, as a special case

Though since Titanfall 2 has over 200 entities[^r2], adding more .json to pilot/r2/ would be a lot

[^r2]: MRVN-Entities on GitHub - Titanfall 2 Entities List

snake-biscuits commented 1 year ago

Any editor.ent / Internal Entities would need to be hard-coded into MRVN-Radiant So maybe editor.ent might be better off as part of MRVN-Radiant directly

@F1F7Y thoughts?

I think the tools in MRVN-Entities could be useful for copying some editor/compiler-only entity definitions But automating a build of editor.ent would be more work Keeping editor.ent up-to-date with remap from a separate repo would also be a huge pain.

Pretty sure maintaining a editor.ent for each game as part of MRVN-Radiant seems like the smarter move tbh. Just want to write out the thought process out in writing to see if there's other opinions.

If / when MRVN-Entities gets added to MRVN-Radiant w/ a pull request we can prob discuss this more

snake-biscuits commented 1 year ago

If / when MRVN-Entities gets added to MRVN-Radiant w/ a pull request we can prob discuss this more

atm I'm fairly confident I haven't removed any functionality, but I haven't done any serious testing. Compiling some zoos from MRVN-Resouce-Pack should do. The current entity definitions in MRVN-Radiant don't cover much more than mp_base rn anyway.

I should probably test ziplines and stuff first tho. Maybe even gather up a few .map files from the Northstar Discord

Since we can't really automate testing on compile maps I'll need to work out some kind of QA checklist. (Tho maybe npc_pilots & vscript could be used for some things)

F1F7Y commented 1 year ago

I think the tools in MRVN-Entities could be useful for copying some editor/compiler-only entity definitions But automating a build of editor.ent would be more work Keeping editor.ent up-to-date with remap from a separate repo would also be a huge pain.

The plan is to add MRVN-Entities to MRVN-Radiant and considering we ship game/entity definitions, radiant and remap together I dont think keeping entity definitions up to date with remap would be hard.

Theoretically all we need to do now is to verify entity keyvalues, no?

Also regarding editor support for special entities I'd like those to be plugins. Barebones radiant shouldnt have hardcoded game specific features.

snake-biscuits commented 1 year ago

I've decided to go with the filename radiant.ent (using "Block": "radiant" in .json) editor.ent was too close to the other filenames imo

Also wrote a quick & dirty func_occluder.json so we have definitions for all ents present in MRVN-Radiant rn

snake-biscuits commented 1 year ago

Might look into things like "changing brushes to func_occluder set texture to tools/occluder" etc. in Radiant later

Also regarding editor support for special entities I'd like those to be plugins. Barebones radiant shouldnt have hardcoded game specific features.

I was mostly thinking about env_cubemap & compiled worldlights etc. Entities that don't get compiled into entity lumps Texture streaming probes for .stbsp will probably fall into a the same category

func_instance will definitely be better suited to a plugin though (e.g. ItEndsWithTens/Quinstance) There's a lot that can be done with instances in-editor too.

For example, Hammer++ allows for the quick creation of instances without opening a new tab[^h++] And since Radiant only allows for a single map tab afaik, working with instances would be extremely difficult without this feature. I could be wrong though, CoD2's example levels (that ship with CoD2Radiant) use a lot of instances.

[^h++]: Hammer++ features

snake-biscuits commented 1 year ago

I would like to use func_instance to construct the sdk / zoos for MRVN-Resource-Pack. Could speed up things like blocking out ai frontlines for attrition etc. Or we do an Apex Legends and copy paste the same buildings from colony everywhere (eden does this in r2)