 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
There are lots of ways of doing it, if you know how to do it for hipnotic then that way still works. The external model supports allows for another way which I think is easier, and I'll explain that one now.
Create a new map file and build your rotating bsp model in it. Think about where you want the centre of rotation to be for your model, then move the brushes so that the centre of rotation is at the origin of the map (0, 0, 0). Then compile your map as rot_mdl1.bsp. Return to your main map and add a point entity with classname rotate_object_point. Set the model field of this entity to maps/rot_mdl1.bsp and then compile and run the main map*. You should be able to find the rotate_object_point you just added and see the rotating model you built in fullbright. All that remains is to open the rot_mdl1 map file in your editor and add some light entities around it, then recompile it. It's up to you to make the lighting believable, bearing in mind that your model will rotate, so keeping it fairly flat is advised. * Question for the floor: Is maps/ the right folder for external bsp models to live, morally speaking? The guide puts it there because it's simple, where the compile process naturally puts maps. This makes it easy to compile it, check the lighting in-game and then adjust and repeat. But I think there's a case for these models to belong in another folder for released maps, either progs/ or a new folder like mapobj/. I somehow forgot that you dont even need to seal the map for q1 light, unlike other games.
I'd say maps, even though logically it could go somewhere else - just because its the standard format that the majority of editors use.
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... 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? Tried it, doesnt work. Q3map2 assigns lightmaps coordinates regardless of diffuse textures coords or names.
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 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. 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 :)
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. I have a 'clean' install of worldcraft3 and wc3adaptor and when I'm opening a
screenshot WC uses Valve 220 texture protocol, or some jaz like that, and yeah - doesn't support standard
You need to find some Kinda sucks in that respect, WC. Is there a reverse-mapconv anywhere? One that takes Q1 format maps and spits out the valve version with the added texture info?
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. 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?
OK. All the
Now, the modern compilers we use support Half-Life texture protocol (because awesome people made us awesome tools since '96). The original id1 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 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(!)). 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 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. 1) Install WC1.6a, and WC3.3.
2) Load an original 3) Save it as 4) Load then new 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. 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. 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 ;)
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |