View Issue Details

IDProjectCategoryView StatusLast Update
0004300The Dark ModMappingpublic19.01.2021 19:15
ReporterSteveL Assigned ToDragofer  
Status closedResolutionsuspended 
Product VersionTDM 2.03 
Summary0004300: func_group doesn't work
Descriptionfunc_group is an editor feature that lets you manipulate a cluster of worldspawn primitives as an entity group in the editor (like an FS) but which in game reverts to worldspawn.

Is has to be activated by adding a spawnarg to worldspawn: moveFuncGroups 1

Forum thread:
Additional InformationProblem in TDM:
DR writes the brush and patch coords relative to the entity origin, but TDM positions them relative to the world origin when spawning the map.

This can be fixed in idMapFile::Parse. The last section moves the func_group's primitives to the worldspawn entity. It also needs to adjust the plane distance for brushes, and the vert positions for patches
TagsNo tags attached.




09.04.2016 18:53

reporter   ~0008070

Last edited: 09.04.2016 18:55

I'll paste the fix since I can't commit it right now:

// SteveL 0004300. This was broken. Primitives in entities are written in the map file
// relative to the entity origin not the world origin. This needs correcting for as
// the entities are copied.
// entities[0]->primitives.Append( mapEnt->primitives ); // Old code pre-0004300
for ( int x = 0; x < mapEnt->primitives.Num(); ++x )
   idMapPrimitive* pr = mapEnt->primitives[x];
   idVec3 groupOrg = mapEnt->epairs.GetVector("origin");
   if ( pr->GetType() == idMapPrimitive::TYPE_BRUSH )
      idMapBrush* br = static_cast<idMapBrush*>(pr);
      for ( int y = 0; y < br->GetNumSides(); ++y )
         idMapBrushSide* bs = br->GetSide(y);
         idPlane p = bs->GetPlane();
         p.SetDist( p.Dist() + groupOrg * p.Normal() );
   else if ( pr->GetType() == idMapPrimitive::TYPE_PATCH )
      idMapPatch* pa = static_cast<idMapPatch*>(pr);
      pa->TranslateSelf( groupOrg );



10.04.2016 14:56

reporter   ~0008073

Last edited: 11.04.2016 17:37

To do:
1) suppress the console warning, that the entity has no spawnclass. It's not supposed to spawn. It might be worth formalising this in 2.05, e.g. with a "spawnclass" "noSpawn" spawnarg in the def, so it's clear that the lack of a spawnclass isn't a bug.
2) test with rotated entities

EDIT 2016-04-11: Yes it works with rotated entities. The brushes must still be using world orientation even though they are not using the world origin.



10.04.2016 17:54

reporter   ~0008075

For whenever it gets implemented - a reminder to update the entityDef for func_group, I think it still contains Doom 3 defaults.

    "editor_color" "0 0 0"
needs to be changed to a neutral color, either same as func_static or something similar. Currently the black borders make it impossible to see for DR users with the black background color scheme.

    "editor_usage" "Used to group brushes together just for editor convenience. They are turned into normal brushes by the utilities."
may also need to be changed, stating that you have to set moveFuncGroups 1 on worldspawn for the entities to appear (will that still be needed?).

In general, it might be nice to toggle that spawnarg per entity basis, rather than an on/off switch for the entire map. If the mapper imports a prefab containing func_groups and his worldspawn doesn't have moveFuncGroups set to 1, they'll be surprised to find their prefabs don't show up in-game.

If moveFuncGroups (or a similar acting spawnarg) can't be set to 1 as default, per entity, it should at least be set to 1 as default on worldspawn.


10.04.2016 18:31

reporter   ~0008078

Color fix noted.

I agree we should remove the moveFuncGroups spawnarg entirely. It was broken by the time Doom3 came out, apparently, so it must have been there for testing back in Quake days. If you want an individual func_group to stop being merged for some reason, you just need to change it to a func_static. You can do that in DR for multiple entities at a time.


11.04.2016 17:32

reporter   ~0008084

Neither "func_group" or "moveFuncGroups" are referenced in any published map or in the game files (other than in the def for func_group itself).


11.04.2016 18:07

reporter   ~0008085

Last edited: 11.04.2016 18:19

Instead of simply suppressing the warning, I've added func_group to the list of blocked entities in idGameLocal::InhibitEntitySpawn()

We can't let mappers turn off collision models for a func_group without a more major code overhaul. The "solid" and "noclipmodel" spawnargs don't work. Worldspawn doesn't have spawnargs for individual brushes, so it relies on the material to determine solidity. That test -- whether a brush is solid or not based on its materials -- comes later than the map parsing where func_groups are handled, so it's not possible to pass information about solidity spawnargs onwards. Not without bigger changes anyway.



11.04.2016 18:26

reporter   ~0008086

I've set the color in func.def to a darker version of the func_static colour, so between the FS colour and worldspawn colour (black by default). Not sure we can include the colour change in 2.04 but I'll check.


17.04.2016 16:19

reporter   ~0008100

The inline spawnarg makes func_statics into non-solid brushes so I think it should cover that shortcoming, should one wish to get a world brush with no collision. Noshadows still won't work however, that's still gotta go on the material.

By the by, you can "go over" the entity limit with func_groups, right? Say you have 10k ents and 5k of those are func_groups, they'll be handled before the game checks if the entity pool is full and potentially returns the "no room for entities left" error at map start, correct?


19.04.2016 22:22

reporter   ~0008101

Yes that's right, func_groups will not bump the entity count.


20.04.2016 18:12

reporter   ~0008106

Code changes committed at rev 6582
DR colour changes and help text updated at rev 14482


20.04.2016 21:42

reporter   ~0008107

reopened because I forgot this bit: we should remove the moveFuncGroups spawnarg entirely


21.05.2016 21:50

reporter   ~0008158

I've discovered an oversight in how func_groups handle textures. Any texture's horizontal/vertical shift and rotation is relative to world origin, which is a nasty problem.

This has the weird consequence that if you move a func_group's origin point, it will move the texture. I assume this is because func_groups are all moved to world origin with their own origin points as the point of alignment before being distributed to their proper places.

It's harder to test this with patches, but the bug doesn't seem to affect them, just brushes.


09.06.2016 17:53

reporter   ~0008204

@Spooks: confirmed, good catch and it's pretty ugly when you do it with a tiled texture.

Ugh, now I have to work out how to translate and rotate texture matrices.


07.07.2016 13:04

viewer   ~0008241

I'm moving this to 2.05.

For the most part, it's been fixed in 2.04, but there are some unresolved issues that we didn't have time to address in 2.04.


19.09.2016 15:45

developer   ~0008321

It seems that Greebo added new Grouping functionality to Dark Radiant which covers the use-case for func_group:

perhaps this should be suspended or closed?


17.09.2017 20:42

developer   ~0009277

Moving to 2.07

Dark Radiant covers most of this use-case now.


19.01.2021 19:15

developer   ~0013484

DR's grouping feature does an excellent job already, I see no reason whatsoever to expend time to restore func_groups.

Issue History

Date Modified Username Field Change
09.04.2016 18:50 SteveL New Issue
09.04.2016 18:50 SteveL Status new => assigned
09.04.2016 18:50 SteveL Assigned To => SteveL
09.04.2016 18:53 SteveL Note Added: 0008070
09.04.2016 18:55 SteveL Note Edited: 0008070
10.04.2016 14:56 SteveL Note Added: 0008073
10.04.2016 15:32 SteveL Note Edited: 0008073
10.04.2016 17:54 Spooks Note Added: 0008075
10.04.2016 18:31 SteveL Note Added: 0008078
10.04.2016 18:31 SteveL Target Version TDM 2.05 => TDM 2.04
11.04.2016 17:32 SteveL Note Added: 0008084
11.04.2016 17:37 SteveL Note Edited: 0008073
11.04.2016 18:07 SteveL Note Added: 0008085
11.04.2016 18:19 SteveL Note Edited: 0008085
11.04.2016 18:26 SteveL Note Added: 0008086
17.04.2016 16:19 Spooks Note Added: 0008100
19.04.2016 22:22 SteveL Note Added: 0008101
20.04.2016 18:12 SteveL Note Added: 0008106
20.04.2016 18:22 SteveL Status assigned => resolved
20.04.2016 18:22 SteveL Fixed in Version => TDM 2.04
20.04.2016 18:22 SteveL Resolution open => fixed
20.04.2016 21:42 SteveL Note Added: 0008107
20.04.2016 21:42 SteveL Status resolved => assigned
21.05.2016 21:50 Spooks Note Added: 0008158
09.06.2016 17:53 SteveL Note Added: 0008204
07.07.2016 13:04 grayman Note Added: 0008241
07.07.2016 13:04 grayman Fixed in Version TDM 2.04 => TDM 2.05
07.07.2016 13:05 grayman Fixed in Version TDM 2.05 =>
07.07.2016 13:05 grayman Target Version TDM 2.04 => TDM 2.05
19.09.2016 15:45 nbohr1more Note Added: 0008321
22.11.2016 20:42 nbohr1more Status assigned => suspended
22.11.2016 20:42 nbohr1more Target Version TDM 2.05 => TDM 2.06
22.11.2016 20:43 nbohr1more Resolution fixed => suspended
15.02.2017 04:35 grayman Assigned To SteveL =>
15.02.2017 04:35 grayman Status suspended => new
17.09.2017 20:42 nbohr1more Note Added: 0009277
17.09.2017 20:43 nbohr1more Target Version TDM 2.06 => TDM 2.07
17.09.2017 20:43 nbohr1more Status new => suspended
28.06.2018 15:47 nbohr1more Target Version TDM 2.07 =>
19.01.2021 19:15 Dragofer Assigned To => Dragofer
19.01.2021 19:15 Dragofer Status suspended => closed
19.01.2021 19:15 Dragofer Note Added: 0013484