Negke
#8766 posted by JPL on 2009/07/09 10:07:03
Dunno actually, I've never tested such feature, manually at least... I'd rather prefer to stick to something I'm sure it is working ;)
Heh
#8767 posted by Spirit on 2009/07/09 12:02:17
One thing is very bad about Quark's texture handline though. It re-renders all the textures each time you open the texture browser. And it does not let you properly use it during that. This means that you will have to wait several seconds (for bigger wads) until you can select a texture.
#8768 posted by Trinca on 2009/07/09 13:00:26
Spirit put file links... mine is fast...
#8769 posted by Trinca on 2009/07/09 13:00:46
and i always have lots of wads instaled!
Hmm
#8770 posted by nonentity on 2009/07/09 16:09:34
key "wad", value "wad1.wad;wad2.wad" in worldspawn, put all the wad files in the same folder as the .map/compilers. Like negke said, it'll eliminate the possibility of it being misread paths...
(And manually specifying wads is a breeze compared to using an editor that has features you require missing (or has undocumented 'features' you'd rather avoid ;)
Hmm
#8771 posted by nonentity on 2009/07/09 16:09:44
)
(sigh)
#8772 posted by negke on 2009/07/09 18:51:58
What is with me and the slow portals all the time...
#8773 posted by LTH on 2009/07/09 20:14:35
Thanks for the help. Seems like I can add a "wad" key but the value field isn't long enough to fit the path of more than one wad! Even so, the .map file gets generated with another (presumably worldcraft-generated) wad key, with all of the .hlwads in it, which is clearly wrong.
So how can I get worldcraft to generate the correct .wad names instead of using .hlwad...? anyone?
WC3.3?
#8774 posted by negke on 2009/07/09 21:22:31
Text editor then. No idea how to change it permanently.
LTH
#8775 posted by Ankh on 2009/07/09 22:32:44
In WC go to Tools\Options\Textures Tab and add the wad files you need. They will show up in the map files automaticaly. Compile should work without problems. Maybe you have too long paths to the wads also.
#8776 posted by LTH on 2009/07/11 02:46:29
This is really dumb - I've had exactly the same setup working perfectly well before.
Ankh - I'm using WC3.3, so I have to specify .hlwad files in it - which are obviously incompatible with Quake. I thought that the quake adapter did some magic so that at compile time it would re-insert the correct wads, but apparently not (or at least, not in my case).
It Doesn't
#8777 posted by ijed on 2009/07/11 03:34:46
Because it's pretty direct what happens with WC.
But it's fucking irritating when things don't work as they should.
You should have a folder inside WC called textures with all your wads in there. Inside the editor you go to tools/textures and add the wads that are inside that folder manually.
And you're good.
Tech support isn't easy across a forum - but that should set you right.
The adapter does nothing magical, it's just a collection of tools - most of the legwork is still yours, so patience and experimentation is needed.
Also
#8778 posted by ijed on 2009/07/11 03:37:10
Quake does accept HLWAD - but worldcraft 3.3 doesn't accept wad. It's a big hack, but it does work, at leaast until the tex conversion tool refuses to do the business.
Is Full Vis Still Necessary ?
#8779 posted by Ron on 2009/07/11 10:22:40
I'm still working on my map, but when I run it true the Fitz or aguirRe engine with a fast vis only, it runs smooth as can be. Is full vis still necessary in this day and age ?
Another thing, if you get the "Excessive static entities" warning and just ignore it, do you get any real problems ? I don't care about warnings, but are there any consequences ?
#8780 posted by necros on 2009/07/11 10:40:02
it's a choice you make. if you go over limits and get warnings in fitzquake, then you have to accept that it won't run in some engines.
as for full vis, my opinion is that it's just sloppy not to full vis. it's free performance, since not everyone has a monster machine and the quake engine becomes a lot less efficient at drawing stuff. the performance loss is not linear.
#8781 posted by JneeraZ on 2009/07/11 11:18:40
I agree. It's a basic level designer skill to be able to seal your map and get a good VIS. And necros is right that it's not a linear thing - without a VIS, you're drawing the entire level with tons of extra lightmaps to boot.
#8782 posted by Ron on 2009/07/11 11:32:47
OK, thanks.
I thought it only had to do with speed, so gameplay doesn't become choppy.
#8783 posted by JneeraZ on 2009/07/11 11:57:34
Speed is a large part of the reason but there are other concerns, yeah.
Also
#8784 posted by ijed on 2009/07/11 13:59:04
There's lots of ways to build a map where full vis doesn't have to take weeks. Level of brush detail, turning details into func_walls, making LOS blocking 'doughnut corridors' putting clip brushes inside small holes and so on.
Its finnicky stuff to do, but it makes the map very easy to compile - which is important for betatesting, since not everyone has a powerful machine as mentioned. Some might be emulating in Wine or have other issues.
My Quake machine will have trouble on non-fullvised maps, for example - a decent incentive to keep my maps well built.
#8785 posted by JneeraZ on 2009/07/11 14:01:44
"putting clip brushes inside small holes and so on. "
I don't see how this would improve VIS times. Clip is a collision thing while VIS looks at the rendering side of things, right? If you meant plugging up holes with solid brushes then, yes, that would help...
Too Many Static Entities Is A Bad Thing
#8786 posted by RickyT33 on 2009/07/11 14:09:35
the consequence is that some static entities wont appear in game (like torches and stuff)
AguirRe's engine should tell you how many static entities you have and what the limit is (256 IIRC)
Take some out and replace them with other light sources (i.e. light textures)
Ok
#8787 posted by ijed on 2009/07/11 14:11:24
Not vis help, but general good building of the map.
For example putting a crate in the centre of the room on the floor or putting a crate in the centre of the room floating 2 units above the floor.
The second one is better (and invisible to the player) because it causes less subdivisions, which also helps compile time.
No. Wrong. Don't Do This.
#8788 posted by czg on 2009/07/11 14:39:28
Nevermind. I'm Wrong. But It's Still Dumb. And Makes Extra Portals.
#8789 posted by czg on 2009/07/11 14:50:47
Hmm
#8790 posted by nonentity on 2009/07/11 15:46:45
As CZG so eloquently explained, while this will indeed reduce subdivisions of the floor, the saving in VIS time/polycounts will be negligble when compared to the creation of many tiny, tiny vis portals under the crate (which'll slow down you VIS a fair chunk, especially if done with every crate in a level (there should be as many as possible))
|