 |
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); } |
|
|
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. |
 |
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. |
|
|
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. |
|
|
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). |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
Yes that's right, func_groups will not bump the entity count. |
|
|
Code changes committed at rev 6582 DR colour changes and help text updated at rev 14482 |
|
|
reopened because I forgot this bit: we should remove the moveFuncGroups spawnarg entirely |
|
|
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. |
|
|
@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. |
 |
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. |
 |
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? |
|
|
Moving to 2.07 Dark Radiant covers most of this use-case now. |
 |
DR's grouping feature does an excellent job already, I see no reason whatsoever to expend time to restore func_groups. |
- Anonymous
