Didn't Think Of That.
#10982 posted by jt_ on 2011/04/08 19:38:28
But any other time it seems silly.
#10983 posted by rj on 2011/04/08 19:54:17
that does sound handy. the other way is to go to the given line number in the map file (in a text editor) make a note of the coords and find it that way, which is a bit long winded
Neg
#10984 posted by necros on 2011/04/08 21:38:51
sikkpin's radiant has alt+x, alt+y and alt+z to the different axis regions and then alt+o for region off. nothing like that in gtkr/netradiant?
Regions
#10985 posted by SleepwalkR on 2011/04/08 23:55:07
Did I understand it correctly that a region will only display what's already in the view? Is that only a performance enhancement? Or does it reduce visual clutter in any way?
#10986 posted by necros on 2011/04/09 00:26:17
it reduces visual clutter, yes. when you turn a region on, everything outside the region isn't shown.
But What
#10987 posted by SleepwalkR on 2011/04/09 07:38:11
defines a region? How is it then different from a visgroup?
#10988 posted by negke on 2011/04/09 10:32:43
necros: Not by default anyway. Only for turning brushes into a region, not for deactivating it.
SleepwalkR: You select a bunch of brushes (=a certain region of the map) and the rest will not be displayed. For example, if you have a multi-story building but only want to work on the upper floor, you can make that a region so the 2D top view is less cluttered. It's like a negative hide function.
Cool
#10989 posted by SleepwalkR on 2011/04/09 10:56:49
Thanks for explaining.
#10990 posted by Spirit on 2011/04/09 11:53:35
QuArK's system is the best though. You can organise your map in a "folder tree". You have folders in which you can put your brushes and entities. Those you can then make ignored on building, hide, gray out, make unselectable etc. Could not be easier to organise complex maps.
#10991 posted by Spirit on 2011/04/09 12:00:27
How Do Those
#10992 posted by SleepwalkR on 2011/04/09 13:02:35
get stored? Are they hidden in comments in the map file? Or is there an extra file next to the map? Or does Quark have its own format?
#10993 posted by Spirit on 2011/04/09 13:27:10
It has its own map format, .qkm (binary I think). When you tell it to build, it saves a .map file. You can also always save as .map but then you lose those groups and some other features.
Hmm
#10994 posted by SleepwalkR on 2011/04/09 18:28:23
I wonder why they don't just save their extra info as comments in the map files.
Yeah
#10995 posted by necros on 2011/04/09 19:34:28
quark really has the best way of organizing stuff. from what i remember when i worked on hl2 stuff, the wc visgroups are ok, but they aren't as easily managed as quark groups are.
#10996 posted by gb on 2011/04/10 05:36:23
I use groups only if I really have to. Otherwise I use Cubic Clip.
Heh - I Just Dont Use Them
#10997 posted by RickyT33 on 2011/04/10 05:39:44
Sometimes I have to grab half of the map and hide it, but there's no control over it really, I just use rectangle select and hide half of the map.
#10998 posted by Spirit on 2011/04/10 10:09:41
Does anyone know how to compile maps right from the Netradiant menus? Is that even possible for Quake 1?
#10999 posted by negke on 2011/04/10 11:03:55
You need to edit the default_build_menu.xml file in the q1.game folder.
#11000 posted by Spirit on 2011/04/10 11:46:30
No output in the console thing. Is that possible with hmap2 or any of the linux build tools?
QC Error In Coop Mode
#11001 posted by negke on 2011/04/13 19:08:37
I'm stumped here. In coop mode (or to be more precise anything with maxplayers > 1) one of the hacks in Mappi2 causes an error that crashes some engines. The culprit is a customized notnull door entity (of the generator cables - the purpose was to make it nonsolid) which becomes erroneous when more than one player slot is active, because this change in the edict list invalidates the entity's owner field.
I worked around it by changing the entity in question to "use" "func_wall" with "owner" "1" so that it only appears when triggered and is nonsolid at least for the first player. This setup works fine in coop mode.
However, for a reason I don't understand it still causes an error in coop if the berzerker mode (=axe only) is enabled. Not only when the entity is triggered, but already on mapstart. The game displays then a "door_fire: self.owner != self" and the cable doesn't appear.
Any ideas why that could be? Does the removal of the shotgun for the first player mess with the edict list, too? It seems so as there's also a 'walkmonster in wall' warning from a vore inside a func_wall (set to be his owner). But why only with maxplayers > 1?
mappi2tmp.zip
"owner" "1|2"
#11002 posted by jt_ on 2011/04/13 19:10:51
Just throwing it out there. Probably won't work.
Hmm.
#11003 posted by Preach on 2011/04/13 19:44:36
You've got yourself a tough one there, but the question that I'd want to investigate first is not why it's breaking in berserker mode, but how you're getting away with it in the other modes. There is no way that you can run door_fire if owner is anything but self. Have you assigned door_fire to a particular field yourself?
#11004 posted by negke on 2011/04/13 19:57:49
I didn't use door_fire anywhere. However, could it be related to the other (now only) door hack in the map: the water from the bucket puzzle? For the warning message does not appear on Easy (where said entity is flagged out). When the maps starts in bezerk mode, a script is run that activates and removes a whole bunch of entities including the water door.
Not that it would be any less strange.
#11005 posted by negke on 2011/04/13 20:04:08
Yes, it's indeed related. If the door isn't triggered, everything works as it should. But why?
Fire In The Hole
#11006 posted by Preach on 2011/04/13 20:58:51
door_fire expects to be called from the master door in a set of doors. Just make sure that the hacked door entity has owner set to itself - you may need to include a copy for each skill configuration which includes the door if the entity number changes in different configurations.
Two comments on setting that field right. Firstly, the higher up the list of entities you can put the hacky door the better, since there's less chance the entity number will change that way.
Secondly, there's a good chance you'll be screwed over for coop by this. Single player reserves only 1 entity for players, but coop has to reserve up to "maxplayers" entities even if that many have not connected yet.
Best thing to do might be to create two version of the door, one for a server with maxplayers 1 (the single player version) and one for maxplayers 16 (the maximal coop version). One door would have an owner 15 greater than the other. Then killtarget off whichever one will crash the game using the coop detection trick as soon as you can. People who want to play coop would have to set maxplayers 16 for it to work - I don't think there's a way to detect server capacity through qc.
Good luck!
|