News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
Zylyx_ 
that's still very very slow for something which todays machine should be able to compute in minutes.

I would say yes and no: the limitations come from the VIS algorithm itself that is a recursive algorithm, so with very huge and complex map that has tons of volume to inspect (VIS is based onto volume rendering) the runtime becomes very high...

Also, a big processor, not to say a multi core processor, does not help that much. First because most of VIS tool are not coded for multi-core processor, and also compared to what I have, it would only save 20% of the runtime best case I guess (i.e i have an AMD Athlon 2600+), and the bottleneck is not only the CPU only but the motherboard fequency and peripherals access (i.e to memory particularly)

Anyway, when a process run for thousand of hours (more than a month) you have to be patient, so 2 or 3 days less will not make the difference there IMHO... as I don't have any manager pressure to sort out my map ;) 
Intersting... 
This is very interesting. We were just talking about the saturation of CPU speeds in my computer and graphics architectures class today, especialy things like how the cpu works with fetching instructions (particurarly in terms of arithmetic processing dependacy and parallelism). It would be cool if there is a way to make this whole VIS process faster , actualy the entire compilation process, without having to sacrifice detail in the 3D model of the level. But I guess that would require re-writting a lot of things from scratch.

My interpretation of this is that the build tools such as the BSP, CSG, VIS and RAD perform a lot of heavy computations, which require CPU level ALU's (arithmetic logic unit) to compute. Seeing as todays dedicated graphics cards hold a lot of processing power, especialy when it comes to floating point calculations, and fully programmable rendering pipelines, I'm guessing it would possible to re-write and optimize the code to work the GPU's, which I'm assuming would speed things up dramaticaly. But who would want todo all that work :)? 
All That Work? 
The Old One. 
Model Mesh 
what makes the Q1 model files so irritating incompatible to handle...argh!

repeated message, i know but I almost learned Max3d manual on importing and exporting them.
They keep dragging on verticejumps and triangle catches.
Finally had my model boned and animated then it turned out rejected.

Starting from scratch won't mind, but manipulating excisting files can be a doughnut. 
_Zylyx 
I'm guessing it would possible to re-write and optimize the code to work the GPU's, which I'm assuming would speed things up dramaticaly.

Indeed, I know some application prefers to use GPU instead of the CPU, because of the ALU performances, but it needs to adapt the software to be adaptable to the GPU... though...

Anyway, Quake standard does not like big map. It has not been built for what we are asking today. The community is constantly asking for bigger / better / more detailed maps, even if the VIS tools have made impressive progresses (thanks aguirRe !), the overall runtime is suffering... but this sacrifice is worth supporting it, as it enables fabulous maps and projects...

I think I'll try to contact aguirRe to get his point of view about using GPU instead of CPU, maybe he would accrpt to try the porting... who knows ? 
Monster Statue 
Is it possible with Quoth to have monster statues, that will wake-up on trigger event ? 
Lighting Question 
#1 I use WC 1.6 it supports a color picker. The format is Quake2 0-1,0-1,0-1 for RGB. What is considered the standard 0-1 or 0-255 for RGB.

#2 What modern tools support the 0-1 format? (not Hmap2).

#3 Must obey the use of _color so as not to screw with Quoth's light entities. 
Jpl 
i'm thinking this: func_wall with model key set to the monster and appropriate frame (like you set up for a monster corpse).

then a trigger that kills the func_wall model and spawns in the correct monster.

maybe some debris spawners for effect and a func_togglewall on top of the func_wall to make it 'solid'. 
Necros 
OK, thanks, I'll try it.

I thought it was something available with Quoth. It may be good idea to add such feature BTW ;) 
What Do Dale Earnhardt And Pink Floyd Have In Common? 
You will probably run into a problem with the func_wall, "SOLID_BSP with a non BSP model". You can use mapobject_custom to similar effect, although you'll have the non-solid problem. 
Oh Sorry 
yeah, my bad. for my original post, i should have said func_illusionary instead, since func_wall doesn't work, but i totally forgot you added in the custom mapobj entity, preach. :) 
But 
both fly a plane 
 
Dale Earnhardt : "I'd hit it like a wall!" 
Necros 
No problem ;) I'll test the method ASAP :D 
Close... 
The real punchline is For both, their final hit was "The Wall" 
LOL 
#8322 posted by Willem [24.199.192.130] on 2009/02/22 19:22:40
Dale Earnhardt : "I'd hit it like a wall!"


As for Dale Jr. I have seen him walk out of a bar with pair of fugly skanks on his arms. He'll hit on anything. 
No Log Exists 
When I run WC 3.33, it says the following for everything in the textures directory:

Error creating HLWAD: c:\program files\worldcraft\textures\id_base.hlwad ... details ...No log exists.

This is not such a big deal since I already have the Quake/Hipnotic/Raven etc textures converted and working. But if I want to convert new textures, it won't work.

Any ideas? 
Hmm 
Try using a program that can convert wc 1.6 wads to wc 3.3 wad files, wadconv.exe is a good one, but I dont know any links sadly. I think texmex can do this too, but I dont have a link for that either, sorry! :( 
Links 
http://www.doomworld.com/xwe/
http://www.quaketerminus.com/tools.htm

texmex is harder to find, but I'm sure it is there. 
TexMex 
Hexen Ii Styled Text Dialogue Boxes 
Hay guys,

I'm trying to do something pretty simple here for a series of Quake SP maps... and don't know the right way about going about this. If anyone remembers the dialogue boxes when you looked at a stele or obelisk etc. in Hexen II, it would bring up essentially a box with text describing it etc. and I'm trying to get the same thing in Quake without extensive coding and/or shooting pains in or around the anus. Normal triggers don't seem to work right w/ this due to the text remaining on the screen only for a set client-side amount of time :/

Any thoughts on getting multiple lines of text or a paragraph to stay on the screen longer, then resume gameplay? 
I Think You'll Have To Code It In 
Inside3d.com is the place to go, although there are some coders which are geniouses who may yet reply here...... 
This Is Func_read Or Somethin' Related 
you should ask tronyn about it (it was done in soe iirc) 
 
centerprint (entity e, string s);

is the function you want. it prints the string to the entity specified. the amount of time the center print stays on screen is controlled by an engine variable (scr_centertime, i think) which you can change in the console.

so you would need to circumvent that because you can't assume scr_centertime will be a constant.

what you can do is simply keep calling the function over and over at regular intervals (let's say ever 0.1 seconds) while you are looking at whatever needs a dialog box.
then, when the player looks away, stop and send a centerprint with "" to clear the screen immediatly. 
KamiKaze 
There should be a batfile called 'convtex' or something either in your WC3.3 textures folder or its root folder.

It worth noting that it converts all the texture wads, but if it fails on one for any reason then it stops converting - remove that one wad and the rest will convert ok.

If you've upgraded to Hammer then as far as I remember there's some other fuckup that stops you loading new textures in. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.