<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Quick Groups &#038; Prefabs</title>
	<atom:link href="http://wantonhubris.com/blog/2008/03/30/quick-groups-prefabs/feed/" rel="self" type="application/rss+xml" />
	<link>http://wantonhubris.com/blog/2008/03/30/quick-groups-prefabs/</link>
	<description>My work on display for the world to see.  And possibly ignore.</description>
	<pubDate>Fri, 10 Oct 2008 21:12:16 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Warren</title>
		<link>http://wantonhubris.com/blog/2008/03/30/quick-groups-prefabs/#comment-606</link>
		<dc:creator>Warren</dc:creator>
		<pubDate>Wed, 02 Apr 2008 12:51:24 +0000</pubDate>
		<guid isPermaLink="false">http://wantonhubris.com/blog/?p=221#comment-606</guid>
		<description>It's -almost- like vis groups but not quite that powerful.  A brush/entity can only be in one quick group at a time so it has limitations.  I want to add a full on grouping system though at some point.

Cool idea about the light style template.  I don't think that would be too hard to implement.  I'll think about that.

Thanks!

Oh and BTW you can do anything you want with the basic MAP file format as long as you're willing to put it all into comment lines.  That's what I'm doing with saving viewport camera positions, bookmarks and quick groups at the moment.  The QBSP compiler just ignores those lines and ToeTag knows enough to look for them while loading.  I think the BSP editor did it this way as well.  You don't really need a special file format unless you're going to be doing something pretty complex.</description>
		<content:encoded><![CDATA[<p>It&#8217;s -almost- like vis groups but not quite that powerful.  A brush/entity can only be in one quick group at a time so it has limitations.  I want to add a full on grouping system though at some point.</p>
<p>Cool idea about the light style template.  I don&#8217;t think that would be too hard to implement.  I&#8217;ll think about that.</p>
<p>Thanks!</p>
<p>Oh and BTW you can do anything you want with the basic MAP file format as long as you&#8217;re willing to put it all into comment lines.  That&#8217;s what I&#8217;m doing with saving viewport camera positions, bookmarks and quick groups at the moment.  The QBSP compiler just ignores those lines and ToeTag knows enough to look for them while loading.  I think the BSP editor did it this way as well.  You don&#8217;t really need a special file format unless you&#8217;re going to be doing something pretty complex.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: than</title>
		<link>http://wantonhubris.com/blog/2008/03/30/quick-groups-prefabs/#comment-605</link>
		<dc:creator>than</dc:creator>
		<pubDate>Wed, 02 Apr 2008 11:53:09 +0000</pubDate>
		<guid isPermaLink="false">http://wantonhubris.com/blog/?p=221#comment-605</guid>
		<description>Sounds like you have implemented something very similar to Worldcraft's incredibly useful groups. One thing I hate about radiant is that to rgoup stuff you create func_groups, so basically you can only group brushes. Because worldcraft saves its own map format (rmf files) it can store groups, visgroups and cameras which are all really helpful when making big levels. Groups are pretty much what you have put into toetag, and make managing levels with intricate doorways, arches and such much easier. It's also useful for adjusting the light level of a whole room at once since you can group the lights and then come back, select the group and adjust the brightness of them all at once (though you have to ungroup them first, then group them again when done).

Actually, that makes me think that an editor based light styles property would be cool. You could set a template light, call it "small spotlight" or something, then set lights you create to have this property. Later if you want to change the value of all the lights you could just adjust the template. Still, maybe that kind of thing isn't really so useful in Quake as it would be with more up to date games since lighting is fairly straightforward in Quake.

Oh, visgroups in Worldcraft are just groups that any brush or entity in the map can belong to and are used to hide areas of the map. There is also a setting to use the colours assigned to visgroups in the editor views so that you can see what belongs to which group. I tend to use it mainly for hiding clips, trigger, entities etc. on small maps, and rooms in bigger maps. I'd kill for a filter for entities and special brush types like radiant or toetag though :/</description>
		<content:encoded><![CDATA[<p>Sounds like you have implemented something very similar to Worldcraft&#8217;s incredibly useful groups. One thing I hate about radiant is that to rgoup stuff you create func_groups, so basically you can only group brushes. Because worldcraft saves its own map format (rmf files) it can store groups, visgroups and cameras which are all really helpful when making big levels. Groups are pretty much what you have put into toetag, and make managing levels with intricate doorways, arches and such much easier. It&#8217;s also useful for adjusting the light level of a whole room at once since you can group the lights and then come back, select the group and adjust the brightness of them all at once (though you have to ungroup them first, then group them again when done).</p>
<p>Actually, that makes me think that an editor based light styles property would be cool. You could set a template light, call it &#8220;small spotlight&#8221; or something, then set lights you create to have this property. Later if you want to change the value of all the lights you could just adjust the template. Still, maybe that kind of thing isn&#8217;t really so useful in Quake as it would be with more up to date games since lighting is fairly straightforward in Quake.</p>
<p>Oh, visgroups in Worldcraft are just groups that any brush or entity in the map can belong to and are used to hide areas of the map. There is also a setting to use the colours assigned to visgroups in the editor views so that you can see what belongs to which group. I tend to use it mainly for hiding clips, trigger, entities etc. on small maps, and rooms in bigger maps. I&#8217;d kill for a filter for entities and special brush types like radiant or toetag though :/</p>
]]></content:encoded>
	</item>
</channel>
</rss>
