Compiler Suggestions Part 2
venomus
Join Date: 2002-11-16 Member: 8951Members
Join Date: 2002-11-16 Member: 8951Members
<div class="IPBDescription">oh no, he's at it agian...</div> I have been experimenting with the zhlt 2.5.3-1.7 source, though my knowledge of c++ is rudimentary so I'm a bit limited in what i can achieve for the moment.
I was using a lot of func_illusionaries in my map to simplify the clipping hulls, the obvious problem with this is it adds to the entity count. Therefore I made of few of the textures, special textures in my build of the tools, in that they were all 'noclip' textures. This system is also far from perfect, you sometimes have to use two identical textures in the map, one that clips and another that does not.
The ideal solution, I thought, would be if world brushes could somehow be specified to be non-solid. Most editors (including WC/VHE) do not allow you to give properties to world brushes (just as you cannot add a different property to a specific brush in a func_wall, world brushes are really just brushes in the worldspawn entity).
I thought up a system which, from a mappers point of view, would be very satisfactory. How you would code it is beyond me (not unless I spent a lot of time study c++ and the tools source when I should be working on my map <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> ). Hear me out, maybe it is possible, and maybe one of you has the coding skills to pull it off:
A new brush entity type, lets call it func_specialbrush, is the key to the whole system. A func_specialbrush would not actually be a unique entity at all, just a placeholder for information pertaining to its component brush(es). These component brushes could either belong to the worldspawn entity (ie: a world brush) or to any entity such as a func_wall. The func_specialbrush has two keyvalues (give them whatever name you wish) which allow you to specify to whom it really belongs. By entity number (a default of zero would mean it belongs to the world, conviently). Or by targetname, which is more useful for a func_specialbrush belonging to a 'real' entity. Targetname would have to override entity number, so that if you leave the entity number key at zero (but specify a targetname to belong to) it would not automatically belong to the world.
Now here is the point of the whole system. The spawnflags of a func_specialbrush give its component brushes special properties. At the moment, the obvious one is a noclip flag, excluding the brushes from the clipping hulls. Maybe another spawnflag could specify the brushes as detail brushes which don't take part in vis, etc. This sounds a lot more difficult in concept, but it could eliminate the need to turn half you map into func_walls.
The compiler, upon encountering a func_specialbrush (presumably at the start of hlcsg, but after everything has been numbered) exports the func_specialbrush to its real entity (or worldspawn). It would then probably have to renumber everything. For the properties of individual brushes to be 'remembered' between the tools, some kind of external list would have to be built.
So there you have it, the answer to your entity count nightmares. Well, if its do-able anyway. You will notice that the system, as well as allowing you to give ordinary worldbrushes properties which they would normally have to be entities to perform, could make something like a partially solid func_wall. The use of this is not obvious, admittedly. Maybe you could use it to control the bounding box (and origin) of func_trains more easily.
I was using a lot of func_illusionaries in my map to simplify the clipping hulls, the obvious problem with this is it adds to the entity count. Therefore I made of few of the textures, special textures in my build of the tools, in that they were all 'noclip' textures. This system is also far from perfect, you sometimes have to use two identical textures in the map, one that clips and another that does not.
The ideal solution, I thought, would be if world brushes could somehow be specified to be non-solid. Most editors (including WC/VHE) do not allow you to give properties to world brushes (just as you cannot add a different property to a specific brush in a func_wall, world brushes are really just brushes in the worldspawn entity).
I thought up a system which, from a mappers point of view, would be very satisfactory. How you would code it is beyond me (not unless I spent a lot of time study c++ and the tools source when I should be working on my map <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> ). Hear me out, maybe it is possible, and maybe one of you has the coding skills to pull it off:
A new brush entity type, lets call it func_specialbrush, is the key to the whole system. A func_specialbrush would not actually be a unique entity at all, just a placeholder for information pertaining to its component brush(es). These component brushes could either belong to the worldspawn entity (ie: a world brush) or to any entity such as a func_wall. The func_specialbrush has two keyvalues (give them whatever name you wish) which allow you to specify to whom it really belongs. By entity number (a default of zero would mean it belongs to the world, conviently). Or by targetname, which is more useful for a func_specialbrush belonging to a 'real' entity. Targetname would have to override entity number, so that if you leave the entity number key at zero (but specify a targetname to belong to) it would not automatically belong to the world.
Now here is the point of the whole system. The spawnflags of a func_specialbrush give its component brushes special properties. At the moment, the obvious one is a noclip flag, excluding the brushes from the clipping hulls. Maybe another spawnflag could specify the brushes as detail brushes which don't take part in vis, etc. This sounds a lot more difficult in concept, but it could eliminate the need to turn half you map into func_walls.
The compiler, upon encountering a func_specialbrush (presumably at the start of hlcsg, but after everything has been numbered) exports the func_specialbrush to its real entity (or worldspawn). It would then probably have to renumber everything. For the properties of individual brushes to be 'remembered' between the tools, some kind of external list would have to be built.
So there you have it, the answer to your entity count nightmares. Well, if its do-able anyway. You will notice that the system, as well as allowing you to give ordinary worldbrushes properties which they would normally have to be entities to perform, could make something like a partially solid func_wall. The use of this is not obvious, admittedly. Maybe you could use it to control the bounding box (and origin) of func_trains more easily.
Comments
Clip texture brushes currently do the opposite of what you suggest with clipping -- they are removed from the vis hull before BSP runs and remain in the other hulls.
I'll keep this in the list of items I'm currently considering implementing.
The question is this: in Hammer, if you select a bunch of world brushes at the same time and then turn them all into an entity, and then go to Entity Report, it will list the whole bunch of them as one line in the list, suggesting that you have just created one, single, lonely entity which is composed of all those brushes. Now, is this actually what has happened, or is it just something Hammer does that is misleading but maybe makes it easier to manage the entities? I mean, will the compiler see one entity and count it as one entity towards the limit, or will it see a whole bunch of entities (one for each brush you selected) that just all have the same properties?
It seems to me like it would be the latter case, since otherwise I don't see how anyone would ever run into the entity limit - simply make EVERY glass texture brush part of one entity, EVERY rail (func_wall/solid/255) part of another entity, and you end up with like 10 entities for the whole map (plus things like triggers, origins, point entities, etc).
So, since that can't be right, how DOES it work? <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
-tal
The question is this: in Hammer, if you select a bunch of world brushes at the same time and then turn them all into an entity, and then go to Entity Report, it will list the whole bunch of them as one line in the list, suggesting that you have just created one, single, lonely entity which is composed of all those brushes. Now, is this actually what has happened, or is it just something Hammer does that is misleading but maybe makes it easier to manage the entities? I mean, will the compiler see one entity and count it as one entity towards the limit, or will it see a whole bunch of entities (one for each brush you selected) that just all have the same properties?
It seems to me like it would be the latter case, since otherwise I don't see how anyone would ever run into the entity limit - simply make EVERY glass texture brush part of one entity, EVERY rail (func_wall/solid/255) part of another entity, and you end up with like 10 entities for the whole map (plus things like triggers, origins, point entities, etc).
So, since that can't be right, how DOES it work? <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
-tal <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
All the brushes that you select for an entity are indeed a single entity against the cap, but as Kage noted, there isn't any vis information for entities, which are drawn in all-or-nothing fashion. There's a thread <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=26307&st=15' target='_blank'>here</a> that talks about why making large visible entities is a bad idea.
I'm curious to know how detail brushes were going to be implemented as they would be very useful and should be fairly simple to code. Maybe I'll take it on after my current project.