AguirRe
#1887 posted by glassman on 2004/05/07 13:02:03
What are the mapper specific features in your version of glquake?
Aguire:
#1888 posted by necros on 2004/05/07 13:52:56
thanks man, this is awesome stuff.
first of all, the engine is a great idea. there are times when every engine i try to use packs up and leaves. i doubt i'll use it for much playing, because it doesn't look like you've made it any more efficient than the regular quake, and i doubt i'll make a map specifically for it either because of that, but this should help immensly with testing and such. at least now, when i hit a limit, i can keep building and testing while i try to figure out what's wrong as opposed to just stopping and searching and waiting and such. :)
also, i'm a big fan of delay 5. i didn't use many delay 2 lights in my maps after i started using fitzquake, because the overbright feature would make the lights way too bright, and i realised that this must be what it looks like in software... being able to specifiy a max light limit is great, and Kinn rocks hard for coming up with something like that. (but thanks for implementing it in your tools, aguire)
i haven't really experimented much with the new minlight setting though... i try to stay away from minlight as much as possible. :P
cheers on excellent work!
Glassman:
#1889 posted by necros on 2004/05/07 13:54:26
like he said in the readme, there aren't really any features for mapper, the only feature is that almost all limits that would normally crash quake before even letting you see the map are bumped way up (ie: edicts from 600 to 2048)
it's not really meant for normal play or for mapping specifically for.
Fuck, Triple Post...
#1890 posted by necros on 2004/05/07 14:48:52
one thing i forgot to mention, Aguire:
don't name your engine glquake.exe, because it's not meant to be a glquake replacement. glquakebjp is perfectly acceptable ;) besides, it makes unzipping it a pain, because now i have to unzip to another directory, rename then copy it into the quake directory. same me some steps, eh? ^_^
Glassman
#1891 posted by HeadThump on 2004/05/07 15:17:02
I have experienced the same problems. I've also reverted back to using the beta 1.3.11 because I find the changes in the interfaces of the newer versions iratating and counterproductive to what I try to accomplish.
GlassMan
#1892 posted by aguirRe on 2004/05/07 16:03:56
The "GLQuake Mapper version" just means that its focus is on loadability and viewing of large troublesome maps.
Since mappers at one time or another create maps that indirectly (e.g. via leaks) or directly exceed normal engine limits, I hope this version is of special use for them.
It's not meant as a replacement for FitzQuake or other engines, just a complement.
Necros
#1893 posted by aguirRe on 2004/05/07 16:14:55
I toyed with the idea of making up yet another engine name but decided against it, since all my other tools also kept their original names.
Since I don't plan to make that many more improvements to this engine (unless someone finds a reasonably valid bsp it can't load), I hope it won't be too cumbersome with the file renaming.
I'm glad you like the tools, let me know if you have problems with them.
Thanks AguirRe..
#1894 posted by glassman on 2004/05/07 18:44:01
Sorry I didn't spot the readme..it isn't in the zip. That sounds very useful.
Headthump..I fine with 1.4 but I definitely need to turn freelook on. I've reported it as a bug.
Your Huge Map
#1895 posted by aguirRe on 2004/05/07 19:39:53
Day of the Lords was one that I tested the engine capacity on. Sometimes when compiling that map you get a leak near the beginning of the map.
The resulting bsp is normally not loadable in any engine, but now it is. Just fly around and inspect the whole outside of the map when it's not removed by the compiler. Then load the pts file and you can find the leak spot immediately.
Even the old SoE map soe2m4 which was mega huge before Tronyn decided to split it can now be loaded and inspected for the leak trail.
Maybe the engine can also handle the upcoming project that Tronyn is working on.
I've Noticed
#1896 posted by HeadThump on 2004/05/07 20:38:10
with 1.4 the default settings uses the QeRadiant standard 'delete - insert' for the zoom-in, zoom-out instead of the 'shift mouse drag' that is second nature for me now. Changes like that are a bit irksome though I do have 1.4 set up for Half-Life mapping.
AguirRe
#1897 posted by glassman on 2004/05/08 04:02:37
Yes I had that problem intermittently - strangely I got it to compile (without a leak) by slightly moving one of the entities in the beginning outside area. Not sure why that would work other than perhaps reshuffling the entity order in the map file. Where is the leak?
HeadThump-shift RMB drag does work in 1.4 in the 2d windows.
It's The Same As
#1898 posted by aguirRe on 2004/05/08 05:00:26
we discussed before; the leak is in the rocks to the left of the entrance cave in the open area.
When inspecting the leak, it seems to be one of those that there really isn't any explanation of; all brush junctions seem OK (although a bit complex) in the area. By manipulating one of the brushes, the leak goes away.
My only guess is that it's the size of the map that finally puts the numerical errors in the float calculations over the edge.
Necros
#1899 posted by Kinn on 2004/05/08 05:43:47
Hi dude, I'm glad you like delay 5 (and massive thanks to AguiRe for implementing it in his light program). What I find looks awesome is to use it in conjunction with "wait 2", e.g. for a nice, dramatic walltorch, try:
light 600
delay 5
wait 2
Func_synch_trains
#1900 posted by madfox on 2004/05/08 20:39:26
I wated to synchroon func_trains, as I am using 5 related through eachother.
Found it somewhere at 3D-Inside, but lost it.
Can't find it...again.
Gtkrad Keys
#1901 posted by glassman on 2004/05/11 15:03:42
Anyone know if it's possible to change the keyboard assignments for gtkrad 1.4 upwards? Specifically I'd like to change the freelook camera move arrow keys to a wasd set up.
Jawohl
#1902 posted by Vondur on 2004/05/11 15:06:00
you can create your shortcuts.ini file with your key bindings. this file should be placed in your q3/rad1.4 dir.
Danke
#1903 posted by glassman on 2004/05/11 17:35:54
but..the freelook controls seem to be really buggy once I've changed them. They work fine using the default arrow keys but with a new set up (actually esdf) sometimes they work, sometimes not, sometimes the key off doesn't work so the camera carries on moving. I've changed the other shortcuts that clash. Any ideas?
Hmm
#1904 posted by Vondur on 2004/05/11 17:37:38
not really, cuz i avoid using freelook. sorry.
i use arrows and ctrl/shift modifiers to move in 3d view.
Ja
#1905 posted by glassman on 2004/05/11 17:48:49
I agree! (although I use RMB + ctrl)..but non-freelook in v1.5 (Spog's q1 branch) doesn't support it. If you feel like it you could encourage Spog to add support by commenting in this bug report:
http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=1005
See also:
http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=1004
Freelook
#1906 posted by necros on 2004/05/11 19:02:16
make sure caps lock is not on, because that will affect letter keys.
also, the key releases for the arrow keys are bugged as well. if you press up and then 't' or something that brings up a window, the view will continue to move forward, even if you let go of the forward key. you need to close the windows and press the same key to stop it.
Where Can I Get Q1 Textures?
#1907 posted by ToadWarrior on 2004/05/12 15:41:43
Where's the best site for Quake 1 texture sets? I've tried searching google but it's all QUake 3 stuff coming up with the occasional Q2 bits.
Look For Links
#1908 posted by aguirRe on 2004/05/12 17:30:42
Texture Dimensions.
#1909 posted by Kinn on 2004/05/14 08:31:06
A quick texture question. I have a texture that's 128 x 8 pixels, and it crashes Winquake. Keeping the width at 128, what's the smallest height for it to be valid?
16
#1910 posted by czg on 2004/05/14 08:50:20
Textures can't be smaller than 16 pixels in any direction.
Mmf
#1911 posted by Kell on 2004/05/14 10:18:30
I'm making a Q1 terrain map. All goes well until I'm adding the last sections of detail and refining gameplay when:
TreeQBSP v1.96 -- Modified by Bengt Jardrup
Input file: C:\quake\id1\maps\kellmet4.map
Output file: C:\quake\id1\maps\kellmet4.bsp
---- LoadMapFile ----
*** WARNING 06: No info_player_deathmatch entities in level
Title: "Blah"
18989 faces
3486 brushes
270 entities
39 unique texnames
271 texinfo
Building hulls sequentially...
Processing hull 0...
---- Brush_LoadEntity ----
*** ERROR 32: Face coordinate out of range (100000.000000)
1 warning
Elapsed time : 0:02
Peak memory used : 3.5 MB
The terrain mesh is 32x32, though I have a smaller section to generate separately and bolt on to one of the corners.
The terrain squares are 128x128 units. I was using 256x256 but it looks cack and makes traversing the terrain awkward.
There are three large bits of architecture on the terrain and several smaller ones. All of the large bits contain pseudo-curves ( domes and pipes ) only some of which I was able to make into func_illusionarys.
Compiling worked fine up until I added just a few more brushes for a small chunk of techy architecture and *wham*...above error.
I suspect I simply have too many surfaces in the map now and will have to prudently chunk some of my detail.
Is this the case?
|