Thnx Preach
I somehow forgot that you dont even need to seal the map for q1 light, unlike other games.
Preach
#11463 posted by ijed on 2011/11/19 14:02:02
I'd say maps, even though logically it could go somewhere else - just because its the standard format that the majority of editors use.
#11464 posted by necros on 2011/11/19 17:15:07
i just leave them in maps because i'm lazy.
Also...
#11465 posted by metlslime on 2011/11/19 21:44:40
id software put their item boxes in /maps
Q3map2 Issue
How to force q3map2 to keep samplesize at 16 on huge planar surfaces?
No, tessellating them wont help, it still bakes all them into one 128x128 lm texture. Cant make the slices non-planar (think of a square, it must be flat). Not using -meta is not an option (or other stuff wont work).
-samplesize 16 doesnt do anything either.
If its possible at all...
#11467 posted by metlslime on 2011/11/27 19:31:41
How about tiny differences in texture alignment? Like 0.0001 unit shifts to prevent merging?
Ikbase To Hlwad
#11468 posted by KamiKaze on 2011/11/28 03:42:50
Using worldcraft 3.3 I'm trying to convert ikbase to hlwad but I'm getting an error saying "texture too big - shrink it".
Not sure why since none of the textures are larger than 256 pixels?
Could the fact that worldcraft has to be in the program files folder which in Vista has strict rules about creation new files?
Metlslime
Tried it, doesnt work. Q3map2 assigns lightmaps coordinates regardless of diffuse textures coords or names.
#11470 posted by necros on 2011/11/28 19:57:44
maybe it's just a wonked out error message, and it's actually stumbling on the small 16x128 textures?
apart from that, are you trying to directly convert it from .wad to .hlwad or are you exporting then re-importing?
if you're doing one, try the other, etc...
i think hl wads, each texture is supposed to have it's own palette? not sure about that one.
#11471 posted by KamiKaze on 2011/11/29 03:59:10
Thanks. Exported the textures then imported them into a wad that worldcraft was already using and the textures show up fine. Didn't have to do that in my old installation of worldcraft with ikbase... but whatever :)
KamiKaze
#11472 posted by ijed on 2011/12/02 12:55:51
The error message it pops up typically doesn't have anything to do with the error - there's a log folder inside that tells you what really went wrong.
Lots of people have problems with that tool.
Worldcraft!
#11473 posted by Moon[Drunk] on 2011/12/04 08:36:12
I have a 'clean' install of worldcraft3 and wc3adaptor and when I'm opening a .map from the Quake map sources in Worldcraft I get misaligned textures! Anyone have a clue what might cause this?
screenshot
Yeah
#11474 posted by RickyT33 on 2011/12/04 13:35:28
WC uses Valve 220 texture protocol, or some jaz like that, and yeah - doesn't support standard .map texture format.
You need to find some .rmf sources, or use WC's awesome texture alignment to align the textures......
Kinda sucks in that respect, WC.
3.4
#11475 posted by Preach on 2011/12/04 14:26:05
Is there a reverse-mapconv anywhere? One that takes Q1 format maps and spits out the valve version with the added texture info?
#11476 posted by gb on 2011/12/04 21:21:47
Couldn't he use an earlier version of Worldcraft?
Hmm
#11477 posted by DaZ on 2011/12/05 00:40:10
could try select all and then open the face edit box and align all to bottom left, as a quick and dirty fix.
There might be a few faces you then have to edit by hand to get looking right, but that should fix most surfaces in the id maps as they are not too complex.
if you can find yourself a copy of worldcraft 1.6, that will load the map files with correct texture coordinates as others have mentioned.
#11478 posted by Rick on 2011/12/05 16:37:43
That's weird, but if there is nothing actually wrong with the map and the alignments are "fixed" to look correct in this editor, will they still look right when seen in the game?
Hmmmm
#11479 posted by RickyT33 on 2011/12/05 19:50:28
OK. All the .map file texture info has to be passed on to a compiler before the map becomes a .bsp.
Now, the modern compilers we use support Half-Life texture protocol (because awesome people made us awesome tools since '96).
The original id1 .map sources have id1 texture protocol info inside them. If you compile those sources with a COMPILER then they will come out just fine.
BUT
If you load those sources into WC3.3, it doesn't know how to handle the id1 texture info, so all of the textures just become misaligned, or aligned to a 0,0,0 world grid.
If you then export a new .map file from WC3.3, then you are overwriting the original source. Just to clarify, when you import a .map file into WC3.3 you are changing it's format to .rmf. WC3.3 has to export from .rmf format, back into .map format so you have something which the compilers can then make into a .bsp.
The reason for WC3.3 having different texture protocol is because it allows a much more functional texture-lock feature (i.e. the texture lock actually works(!)).
To Clarify:
#11480 posted by RickyT33 on 2011/12/05 19:58:06
If you use 1996 vanilla qbsp.exe to compile your map, and it is id1 texture protocol, it will work fine.
If you use 1996 vanilla qbsp to compile a WC3.3 .map, it will throw an error (Erk! I dont understand Valve220 texture protocol)
If you use Y2K+ qbsp (e.g. txqbsp, treeqbsp, hmap2 etc), then they look FIRST at what the protocol is, and then they will compile accordingly.
An Experiment For The Less Busy Than Me:
#11481 posted by RickyT33 on 2011/12/05 20:03:14
1) Install WC1.6a, and WC3.3.
2) Load an original .map file into 1.6a
3) Save it as .rmf
4) Load then new .rmf into WC3.3
5) Have a look at the textures in the map
Are they still misaligned?
I don't know the answer to that question, hence the need for the experiment.
Experiment Success!
#11482 posted by Moon[Drunk] on 2011/12/05 22:33:00
Above steps worked Ricky, thanks :)
Couldn't install wc1.6a on win7 though.
Model Limits Exceeded
#11483 posted by Rick on 2011/12/05 23:11:15
256 Models exceeds standard limit of 256.
My current map just generated this error.
4820 brushes, 1476 entities.
Exactly which entities count toward this limit?
Is it only brush based entities like doors and such or does it include some of the point entities like path_corner or trigger_relay.
I don't have a lot of doors and lifts, but there's a lot of triggers and counters and relays.
Models Are:
#11484 posted by RickyT33 on 2011/12/05 23:19:57
Triggers
Buttons
Doors
Trains
Func_walls
Basically anything which is an entity, which is made from brushes.
I think that func_illusinaries are NOT classed as models, but I could be wrong.
I think that the map also counts as one.
I forget.
Fitzquake 0.85, Darkplaces, AGlQuake, DirectQ etc all allow for more than 256 bmodels. My current map has well over 500 ;)
Models...
#11485 posted by metlslime on 2011/12/05 23:53:58
every entity made out of brushes in your map is a unique model and counts towards the total. This even includes triggers since they have a brush.
On top of that, every unique external model file used by the level (*.mdl, *.spr, and *.bsp for the ammo boses) is counted once. So 10 ogres that use ogre.mdl, will only count once. (But then there is the ogre head too, so that's two unique models.)
A Tip
#11486 posted by DaZ on 2011/12/06 00:02:02
for func_wall or func_illusionary etc bmodels, you can have multiple brushes inside the single entity. So for example if you have say 20 brushes in a room that you want to be func_illusionary, you can select them all and create a single func_illusionary that will count as 1 bmodel. Instead of 20 seperate func_illusionary that will count as 20 bmodels.
|