Closed snake-biscuits closed 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
Any
editor.ent
/ Internal Entities would need to be hard-coded into MRVN-Radiant So maybeeditor.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
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)
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 Keepingeditor.ent
up-to-date withremap
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.
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
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
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)
Earlier today I copied
simulacrum/
into MRVN-Radiant'sinstall/gamepacks/
(locally) While making sure I wasn't replacing anything defined in the previousentities.ent
for each game, I noticedfunc_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 movedfunc_occluder
toeditor.ent
to preserve it Shortly afterward I realisededitor.ent
could holdprop_static
,func_detail
, maybe evenfunc_instance
[^vdc]MRVN-Radiant would detect these entities in
remap
[^remap_r1o][^remap_r2][^remap_r5] & compile them into the appropriate.bsp
lumps Anyeditor.ent
/ Internal Entities would need to be hard-coded into MRVN-Radiant So maybeeditor.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