View Issue Details

IDProjectCategoryView StatusLast Update
0004300The Dark ModMappingpublic28.06.2018 15:47
ReporterSteveL Assigned To 
PrioritynormalSeveritynormalReproducibilityalways
Status suspendedResolutionsuspended 
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: http://forums.thedarkmod.com/topic/17864-the-functionality-of-func-group/
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.

Activities

SteveL

SteveL

09.04.2016 18:53

developer   ~0008070

Last edited: 09.04.2016 18:55

View 2 revisions

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() );
         bs->SetPlane(p);
      }
   }
   else if ( pr->GetType() == idMapPrimitive::TYPE_PATCH )
   {
      idMapPatch* pa = static_cast<idMapPatch*>(pr);
      pa->TranslateSelf( groupOrg );
   }
   entities[0]->primitives.Append(pr);
}

SteveL

SteveL

10.04.2016 14:56

developer   ~0008073

Last edited: 11.04.2016 17:37

View 3 revisions

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.

Spooks

Spooks

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.
SteveL

SteveL

10.04.2016 18:31

developer   ~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.
SteveL

SteveL

11.04.2016 17:32

developer   ~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).
SteveL

SteveL

11.04.2016 18:07

developer   ~0008085

Last edited: 11.04.2016 18:19

View 2 revisions

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.

SteveL

SteveL

11.04.2016 18:26

developer   ~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.
Spooks

Spooks

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?
SteveL

SteveL

19.04.2016 22:22

developer   ~0008101

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

SteveL

20.04.2016 18:12

developer   ~0008106

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

SteveL

20.04.2016 21:42

developer   ~0008107

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

Spooks

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.
SteveL

SteveL

09.06.2016 17:53

developer   ~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.
grayman

grayman

07.07.2016 13:04

administrator   ~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.
nbohr1more

nbohr1more

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:

http://forums.thedarkmod.com/topic/18350-grouping-feature-feedback-discussion/?p=394528

perhaps this should be suspended or closed?
nbohr1more

nbohr1more

17.09.2017 20:42

developer   ~0009277

Moving to 2.07

Dark Radiant covers most of this use-case now.

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 View Revisions
10.04.2016 14:56 SteveL Note Added: 0008073
10.04.2016 15:32 SteveL Note Edited: 0008073 View Revisions
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 View Revisions
11.04.2016 18:07 SteveL Note Added: 0008085
11.04.2016 18:19 SteveL Note Edited: 0008085 View Revisions
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 =>