 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
You'll need a Quake1 entities.def for making Q1SP maps. I'm not sure where you can get one online right now.
I'll see if I can get SPoG to start reading this thread, since there are some GTKRadiant 1.5 questions that he would be most suited to answering. Episodes are pretty much only defined as a looping set of maps. I.E. at the end of each map, have a trigger_changelevel that has a "map" "nextmapname" key/value pair. If you want to have full out episodes like Quake did, then you'll need a start map with func_episodegates blocking off various episode teleporters, and the appropriate spawnflags for each episodegate. Then each map links to the next in the trigger_changelevel, and at the end of each episode you need an item_sigil with one of the spawnflags checked. And the trigger_changelevel in last map of each episode should link back to the start map. I don't remember a "print" spawnflag for any Q1 entities. i wrote a little guide a while ago that should have everything you need to map for q1 with gtkr1.4
since you're using 1.5, you can still download the http://www.planetquake.com/necros/gtkrq1.html What do you mean by "didn't seem to do anything", didn't it run the vis program with its parameters %1 %2 %3 etc at the specified thread priority? Maybe you forgot adding the parameters to the batch file command?
It's not hard to implement, but I see no reason since this utility does the same job without any cost at all. If you still can't get it to work, please send me the batch file and a description how you call it. are there any fgd files for worldcraft 2.0 or maybe hammer that would let me map for heretic2? im so used to worldcraft im too lazy to learn the one that comes with the game, and i have no idea how to make a fdg for worldcraft. :(
Yeah, I got your original mail. Please note that I have very limited net access and I'm a bit snowed under with content, so I tend not to reply instantly to emails.
thought I would post this here too, can't figure this out. Didn't feel like reformating this post, go to the link below.
http://www.quake3world.com/ubb/Forum6/HTML/028166.html? No problem, I just don't trust Internet email much anymore. To avoid both parties waiting for responses that never come, I'd rather run the risk of being a bit repetitive.
Btw, I've been running a fullvis on the terrain map for about 78 hours now. It has reached 88%, claims that there are 13 hours to go and half an hour ago it even crashed my RVis /me consults the good Dr Watson the line in the batch file:
privis.bat: priority below vis %1 %2 %3 %4 %5 command line: privis -level 4 map starts vising the map, but when i check in task manager, vis.exe is assigned the 'normal' priority. that's what i meant by "does nothing"... any suggestions? BTW, anyone using GTKRadiant 1.5 may want to check out SmallPileofGibs' docs on the subject:
http://zerowing.idsoftware.com/radiant-files/nightly/1.5.0/docs/ I've asked him to keep an eye on this thread, so hopefully he'll see when a new question is brought up, and he can let us know when the docs are updated. every point in the 'transition' section has convinced me not to switch to the newer version.
'select complete tall' was one of the best features of gtkr, because you could size the selector brush to exactly the right size before selecting the other brushes. Holding shift and dragging LMB will create a selection area in the 2D views. Not exactly the same functionality as Select Complete Tall, Select Partial Tall, Select Inside, and Select Touching, but it's better than none.
Thanks for the clarification. You can't use NT/2K/XP Task Manager for checking the thread priority; it only shows the process priority which is of a higher magnitude than the thread variant.
Changing the process priority is actually pretty dangerous if you make a mistake; setting the priority High or even worse Critical for a process like RVis and you'll most likely have to use the power off button to access your system again (or wait until RVis finishes). Setting the thread priority like my utility does (or via the qbsp option), is much safer and most of the time gets the job done just as well. Either you'll have to use another instrument for checking thread priority (e.g. TaskInfo http://www.iarsn.com/index.html ), start another CPU intensive process and confirm that it will now take over the CPU completely or just take my word for it. Btw, in the upcoming versions of RVis/Light, there'll be a -priority option Just as a good example of Internet email reliability, I just received another copy of your Aug 4th email
I'm not mapping, only testing a Q1 map for Kell. 78 hours is not that much; I've a personal record of 350h (2 weeks) on a P4 1.7GHz and Scragbait has run a 550h (3 weeks) session on an even faster machine.
Open maps are slow to fullvis lol.. i think thats why I didn't like Q1 mapping, spent longer compiling than mapping. I love me detail brushes, my current Q3 map which consists of about 3000 brushes and is of decent size currently fullvis is 19 seconds. :)
didn't someone have some sort of experimental bsp compiler with detail brush type support for q1? Or am I imagining things...
Yeah, just for kicks when you guys started mentioning this in here, I changed a running vis of sm82 to something ridiculous like high or realtime. Didn't make it go any faster, but rather sent my system to 100% cpu use rendering it unuseable until it finished. Won't be doing that anytime soon.
See here: http://openquartz.sourceforge.net
Heh, you just had to try it, right?
Task priorites are often a cause of confusion, some even seems to think it's some kind of gas pedal. For best results, always lower the priority of a process, especially if it's hogging the CPU, like RVis or Light. Raising a priority should only be done for processes that often block on external I/O events, like disk or network. Most of the time it's also only useful to raise it just a little bit. If you e.g. try running an RVis session in normal priority and at the same time copy a big file over the network, you'll probably notice that the copy process is much slower than usual. In this case, it would significantly speed up the copy operation if that program/process/thread had a slightly higher priority than normal without the RVis session suffering much of a slowdown. For the record, I was pretty sure it would make no difference. Although if there was some internal thread-yielding, that would make more of a difference I'd imagine.
A question I've been considering for a while to you, mister aguire the quake tools master. What is the feasibility of making a networked vis tool? I know tools like netvis have existed for other games (halflife in particular), so I'm wondering if its possible for quake1. I don't know much of the mechanics of how visibility is processed but I've done enough tcp/ip programming that I think I could handle that side of things. Note: I'm not talking about a cluster of computers sharing processes and memory and stuff, just N number of computers running a client, with one master initiating the process and handling dispatching data to be processed. Thoughts/comments? It's certainly possible (most things are). Vis originally had a threading capability to utilize multiprocessor systems (I think id had dual Sparcs).
IMO, it would've been much more beneficial for most people if they'd concentrated more on the algorithms, memory handling etc. Qbsp had ridiculously many memory leaks and Tyrann has shown that the algorithms could be improved quite a bit, especially in worst case scenarios. If id had implemented the "meta-leaf" (i.e. clustering small detail leafs into bigger ones) variant of vis, it'd would probably be a lot faster in big maps and most likely much faster than any parallel computing method with a lot less hassle. Since most people don't have multiprocessor systems or even lots of LAN-connected machines, pretty few would benefit from multithread/netvis solutions. I even doubt that HyperThreading would help much. There are a lot of other factors (heap, disk etc) in the machine that serialize the processing. In any case, it would add quite a bit of complexity to vis.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |