That's Weird
#13736 posted by killpixel on 2014/04/18 17:26:48
so far I've got 2161 entities and no warnings or errors.
I'm using TxQBSP 1.13 and Light 1.43, release 2, the one modified by MH for colored lights and multithreading. Can't remember which vis.
KillPixel
#13737 posted by mfx on 2014/04/18 17:53:07
As far as i know, lights are count as ents by light.exe, but they don�t add to the edicts.
#13738 posted by - on 2014/04/18 18:20:22
lights are not edicts, unless they have a targetname.
KillPixel: don't worry too much, modern engines handle well above 600 edicts. It's just that the standard id engines can't go over 600.
Edicts
#13739 posted by ijed on 2014/04/19 02:39:38
Are things that do stuff during runtime.
A light without a target name is effectively deleted before runtime, and so not an edict.
#13740 posted by necros on 2014/04/19 03:15:13
i believe light.exe actually delete them if they don't have targetnames?
Oddity I've Yet To See...
#13741 posted by ionous on 2014/04/19 06:33:47
I use Worldcraft 1.6. Working on a Quake level, I compile to check my latest round of progress. Oddly, the batch file I'm using to run TXQBSP returns 28 warnings.
Checking back with the rmf. file, it claims that I have 28 instances of invalid structures. Which is odd since I've been careful about my vertex manipulation. When I zoom to the problem, it's a shapeless object at the grid's top view origin. It's a solid with one face, larger than the grid itself. 28 of them.
I deleted them all, and progress continued, but I'm wondering if anyone's ever come across this before. And what it may possibly mean...
#13742 posted by necros on 2014/04/19 07:47:03
probably just a bug with the editor. i've seen that kind of thing is just about every editor i've used at one point or another.
Lights And Other Entities
#13743 posted by Preach on 2014/04/19 11:16:00
A blog post on when light gets removed and how to remove other things. Save entities, save the planet!
http://tomeofpreach.wordpress.com/2014/04/19/saving-entity-tricks/
Custents
#13744 posted by killpixel on 2014/04/19 19:28:12
Ok, can anyone out there spoon feed me some literature on custom entities and how to make gtkradiant see them.
I've asked someone on quakeone to make me a couple and he compiled a new progs.dat for me as well as gave me some cut/paste stuff to put in a radiant file.
I've got several more things I need but don't wanna harass the guy every time I need a new entity.
Currently, what I'm looking for is a way to arm/disarm triggers, silent spawns (that is, remove the "thud" that models make when the teleport in). I'd also like to be able to trigger any sound, i.e type a path to a sound file to be played. That way one could make a pretty dynamic and awesome sound scape.
My QC knowledge is nill at the moment, I know, I know...
@Ionius
#13745 posted by Qmaster on 2014/04/29 04:27:07
The empty object error is something that occurs in Worldcraft or Hammer.
How to Reproduce:
Create a brush.
Tie it toEntity (eg. make it a func_door)
Create another brush.
Select both brushes.
Tie them toEntity.
Oops, now there's a func_door without a brush.
What is going on:
The editor when it creates an entity from a brush, takes the brush data moves it out from under worldspawn and puts it under an entity like this:
Was:
"classname" "worldspawn"
{###....1}
Now
"classname" "worldspawn"
"classname" "func_door"
{###....1}
So what happens when the brush is already within an entity as above, the brush data gets moved/stolen from under the entity it's already in (worldspawn is an entity!), then put under the new entity. Like this:
Was:
"classname" "worldspawn"
{###....2}
"classname" "func_door"
{###....1}
Now:
"classname" "worldspawn"
"classname" "func_door"
"classname" "func_door"
{###....1}
{###....2}
Notice that there is nothing under the first func_door. And that is why the editor puts in at 0 0 0 and it looks like there is one superbrush covering all of reality. But really, there's nothing.
Best Practice: NEVER create an entity out of brushes that are part of an entity.
Source: I've been a mapper for Quake for over 10yrs. Also, the .MAP file format.
@Qmaster
#13746 posted by killpixel on 2014/04/30 23:54:29
this happens in gtkradient 1.5 as well, took me a while to figure wtf was going on.
"Best Practice: NEVER create an entity out of brushes that are part of an entity."
now I know...
This Can Happen In Pretty Much Every Editor
#13747 posted by negke on 2014/05/01 01:00:56
Best to keep it in mind and check the map for it before release. BJP's Glquake prints a warning if it detects a rogue brush entity, but none of the other ports do.
Not In TB ;-)
#13748 posted by SleepwalkR on 2014/05/01 08:09:48
#13749 posted by Spirit on 2014/05/08 13:02:15
Also, For Negke
#13750 posted by Spirit on 2014/05/08 13:02:54
http://web.archive.org/web/20030219113111/http://www.planethalflife.com/davej/detail_versus_design.htm
What I'm desperately trying not to suggest is that complete mis-alignment of textures is the way forward. That is underkill. I've almost said aligning of textures to edges isn't important. That's a lie. It is. What is important however is knowing when to do it, when it is worth the time, and when it isn't.
Awesome
#13751 posted by killpixel on 2014/05/08 16:06:47
very helpful/informative links!
Whatever
#13752 posted by negke on 2014/05/08 16:45:48
I see where he's coming from, but I feel patronized by the article. There's a point about putting too much focus on "unnecessary" (debatable notion to begin with) detail at the cost of gameplay. Yet, just because the players may not see or appreciate certain details, or because they may not add to the gameplay, it doesn't mean it's bad practice. Besides, the On A Rail chapters doesn't work as a general example for all kinds of games and maps like he seems to be doing.
It's Pretty Badly Written And Incoherent.
#13753 posted by ijed on 2014/05/08 17:02:02
In a nutshell, the point he's trying to make is that details shouldn't interfere with the overall theming of a level's design.
But he focuses on pointless detail (funny considering that's what he's trying to write about) and doesn't resolve the topics he's bringing up.
Yes ok, On A Rail was bland but it worked. You could say that about most of Half Life. Why not mention that software improvements allow us to have better graphics without sacrificing game play?
Yes ok, LDs shouldn't waste their time sticking doorknobs on things. Why not discuss using prefabs or other tools?
#13754 posted by Joel B on 2014/05/08 18:26:21
It's worth noting though that the page was written in 2001. Some angst from back then about aesthetic fiddling getting in the way of playability is understandable (especially from someone working against commercial deadlines).
I Refuse To Accomodate Empathy
#13755 posted by ijed on 2014/05/08 18:32:53
Damn You
#13756 posted by ijed on 2014/05/08 18:33:12
#13757 posted by Spirit on 2014/05/08 18:44:37
There is also a follow-up at http://johnsto.co.uk/blog/116
Yeah
#13758 posted by ijed on 2014/05/08 19:23:57
That's better.
#13750
#13759 posted by metlslime on 2014/05/08 20:57:46
I remember this when it first came out, and it was definitely controversial because it's hard to accept what he says if you believe in cleanly built maps.
The non-controversial part is that an increase in visual detail does not always cause an increase in quality of experience -- an obvious example is high-res replacement textures in quake. The harmony of many different ingredients is more important.
The controversial part is "misaligned textures can be better." I think the best way to re-state this so that I can accept the idea, is to say "impressionism can be better" -- this could be because the "magic" of quake and doom is the low-res, low-poly filter that we see that world through, which gives the player room to imagine the rest. It's hard to do this in high-res, high-poly. At low res, 8-bit lighting, there are so many filters that muddy everything up that you can't always see the texture misalignments, they are hidden by dithering and aliasing and palette banding. These filters help the player experience the whole and not focus on the details, since you can't see the details very well anyway.
Well Put
#13760 posted by killpixel on 2014/05/08 21:30:46
The higher fidelity and realism of the graphics the more visible the flaws, not only technically, but artistically.
Maximum realism is the goal of most modern games, but I don't think we're quite there. IMO, it would better better if designers worked within the boundaries of the tech and made cohesive, artistic interpretations instead of attempting realistic duplication. "pushing the boundaries" is not the safest route, as I feel people push them too far.
|