|
Post by sP1Sp0pD on Mar 16, 2016 10:07:35 GMT -5
I believe I've understood you correctly. Depending on your HTTP server it should be possible via symlink or some special configuration, like URL mapping in case of Apache for example. This, naturally, implies that you have control over your server (have rights to configure it).
|
|
|
Post by sP1Sp0pD on Mar 16, 2016 4:35:13 GMT -5
Probably the easiest way is to make gibrack/maps a symbolic link to ../baseq2/maps, assuming your server is powered by some kind of Unix or GNU/Linux, although NTFS supports symlinks (directory junctions) as well. However, lest you forget that every time you run a dedicated server on Windoze, God kills a kitten.
|
|
|
Post by sP1Sp0pD on Mar 16, 2016 3:04:49 GMT -5
Oh dear god, make me unsee it. Signatures which are not just a couple of lines of text are unholy and evil, and should be universally disabled. It's impossible to read your posts now macanah, sorry. Consider disabling it or at least make it less annoying.
|
|
|
Post by sP1Sp0pD on Mar 15, 2016 22:55:47 GMT -5
It would be nice if you could make releases/tags on GitHub more often. The last one is Release_1.1.1 from Sep 26, 2013 — that's 2.5 years ago.
|
|
|
Post by sP1Sp0pD on Mar 15, 2016 22:44:43 GMT -5
It would help if you could be a little more specific. What map (for which game) are you trying to port (assuming you're trying to make a Q2 map)? What editor are you using? Are you familiar with *.map file format for the games in question?
The first thing to do is to obtain and export map geometry (brushes) correctly. For Q3/QL you'd have to decompile original map (with tools like BSPC or Q3Map2) if you don't have the source for it (only *.bsp file). Note that result of decompilation will be very raw and require substantial amount of cleaning. For Q4 maps, you don't have to decompile them as they inherently come with *.map file. Converting maps from non-Quake games, e.g. Unreal series, is a lot more complicated process and I'd assume we're not talking about those here.
You'd then want to convert it to Q2 format. There are several ways for doing this, depending on your tools and preferences. Some editors have import/export features; another option is to use text-processing utilities, e.g. standard Unix sed(1) and perl(1) programs, and perform all needed adjustments in a semi-automatic fashion.
Once you have your map converted to Q2 format, you can open it in your favorite editor and work on it as usual, plus you'd have to retexture and relight it, and think what to do about patches and shaders (if there were any) since Q2 lacks them. Last but not least, expect to spend some time optimizing it (think r_speeds) — while you should always try to optimize your maps, even the ones you created from scratch, this is particularly important for converted maps because they usually contain lots of bogus and overlapped brushes.
As for a simple way, I don't think there is one (assuming you want a decent result), sorry.
|
|
|
Post by sP1Sp0pD on Jun 4, 2015 11:13:32 GMT -5
There were three leaks actually, not just one. They occur because brushes 12, 19, and 20 are not strictly adjacent to each other (nor they are aligned to the grid). Here is the quick'n'dirty patch I had to make to avoid the leaks and let the map to compile (you'll still need to further clean these brushes up and get rid of fractional coordinates): --- 2box5v5.map +++ 2box5v5_fixed.map @@ -117,14 +117,14 @@ } // brush 12 { -( 0 -256 0 ) ( 0 -256 -4096 ) ( -4096 -256 0 ) e1u1/grnx2_3 32 64 0 1 1 -( 944 0 0 ) ( 944 -4096 0 ) ( 1937 0 -3974 ) e2u3/rmetal6_1 0 64 0 1 1 -( 0 0 192 ) ( -4096 0 192 ) ( 0 -4096 192 ) e1u1/grnx2_3 32 0 0 1 1 -( 0 512 0 ) ( -4096 512 0 ) ( 0 512 -4096 ) e1u1/grnx2_3 32 64 0 1 1 -( 960 0 0 ) ( 960 0 -4096 ) ( 960 -4096 0 ) e1u1/grnx2_3 0 64 0 1 1 -( 0 0 256 ) ( 0 -4096 256 ) ( -4096 0 256 ) e1u1/grnx2_3 32 0 0 1 1 -( 0 -115 0 ) ( 0 -918 -4016 ) ( -4016 688 0 ) e1u1/grnx2_3 32 64 0 1 1 -( 0 371 0 ) ( -4016 -432 0 ) ( 0 1174 -4016 ) e1u1/grnx2_3 32 64 0 1 1 +( 960.125 -256 192 ) ( 897.375 -256 192 ) ( 960.125 -256 234.25 ) e1u1/grnx2_3 32 64 0 1 1 +( 896 512 192 ) ( 880 496 256 ) ( 896 -256 192 ) e2u3/rmetal6_1 0 64 0 1 1 +( 960 512 192 ) ( 896 -256 192 ) ( 960 -256 192 ) e1u1/grnx2_3 32 0 0 1 1 +( 960 512 254.75 ) ( 896 512 192 ) ( 960 512 192 ) e1u1/grnx2_3 32 64 0 1 1 +( 960 512 192 ) ( 960 -256 256 ) ( 960 512 254.875 ) e1u1/grnx2_3 0 64 0 1 1 +( 960 -256 256 ) ( 880 496 256 ) ( 960 511.75 256 ) e1u1/grnx2_3 32 0 0 1 1 +( 960.125 -256 256 ) ( 896.125 -256 192 ) ( 880.125 -240 256 ) e1u1/grnx2_3 32 64 0 1 1 +( 960 511.75 256 ) ( 880 496 256 ) ( 960 512 254.75 ) e1u1/grnx2_3 32 64 0 1 1 } // brush 13 { @@ -184,25 +184,25 @@ } // brush 19 { -( 0 -320 0 ) ( 0 -320 -4096 ) ( -4096 -320 0 ) e2u3/rmetal6_1 0 0 0 1 1 +( -128 -320 192 ) ( 896 -320 256 ) ( 896 -320 192 ) e2u3/rmetal6_1 0 0 0 1 1 ( -128 0 0 ) ( -128 -4096 0 ) ( -128 0 -4096 ) e2u3/rmetal6_1 0 0 0 1 1 -( 0 0 192 ) ( -4096 0 192 ) ( 0 -4096 192 ) e2u3/rmetal6_1 0 0 0 1 1 -( 0 -304 0 ) ( -4096 -304 0 ) ( 0 -1297 -3974 ) e2u3/rmetal6_1 0 0 0 1 1 -( 896 0 0 ) ( 896 0 -4096 ) ( 896 -4096 0 ) e2u3/rmetal6_1 0 0 0 1 1 -( 0 0 256 ) ( 0 -4096 256 ) ( -4096 0 256 ) e1u1/grnx2_3 0 0 0 1 1 -( -115 0 0 ) ( -918 -4016 0 ) ( -918 0 -4016 ) e2u3/rmetal6_1 0 0 0 1 1 -( 883 0 0 ) ( 1686 0 -4016 ) ( 1686 -4016 0 ) e2u3/rmetal6_1 0 0 0 1 1 +( 896 -320 192 ) ( -128 -256 192 ) ( -128 -320 192 ) e2u3/rmetal6_1 0 0 0 1 1 +( -112 -240 256 ) ( -128 -256 192 ) ( 880 -240 256 ) e2u3/rmetal6_1 0 0 0 1 1 +( 896 -320 256 ) ( 896 -256 192 ) ( 896 -320 192 ) e2u3/rmetal6_1 0 0 0 1 1 +( 896 -320 256 ) ( -112 -240 256 ) ( 880 -240 256 ) e1u1/grnx2_3 0 0 0 1 1 +( -127.75 -320 256 ) ( -128 -256 192 ) ( -112 -240 256 ) e2u3/rmetal6_1 0 0 0 1 1 +( 880 -240 256 ) ( 896 -256 192 ) ( 896 -320 256 ) e2u3/rmetal6_1 0 0 0 1 1 } // brush 20 { -( 0 -256 0 ) ( 0 -256 -4096 ) ( -4096 -256 0 ) e1u1/grnx2_3 32 0 0 1 1 +( -224 -256 256 ) ( -128 -256 192 ) ( -224 -256 192 ) e1u1/grnx2_3 32 0 0 1 1 ( -224 0 0 ) ( -224 -4096 0 ) ( -224 0 -4096 ) e1u1/grnx2_3 0 0 0 1 1 -( 0 0 192 ) ( -4096 0 192 ) ( 0 -4096 192 ) e1u1/grnx2_3 32 0 0 1 1 +( -224 -256 192 ) ( -128 -256 192 ) ( -224 512 192 ) e1u1/grnx2_3 32 0 0 1 1 ( 0 512 0 ) ( -4096 512 0 ) ( 0 512 -4096 ) e1u1/grnx2_3 32 0 0 1 1 -( -176 0 0 ) ( -1169 0 -3974 ) ( -176 -4096 0 ) e2u3/rmetal6_1 0 0 0 1 1 -( 0 0 256 ) ( 0 -4096 256 ) ( -4096 0 256 ) e1u1/grnx2_3 32 0 0 1 1 -( 0 -279 0 ) ( 0 -1137 -4005 ) ( -4055 -858 0 ) e1u1/grnx2_3 32 0 0 1 1 -( 0 535 0 ) ( -4055 1114 0 ) ( 0 1393 -4005 ) e1u1/grnx2_3 32 0 0 1 1 +( -128 -256 192 ) ( -112 496 256 ) ( -128 512 192 ) e2u3/rmetal6_1 0 0 0 1 1 +( -224 512 256 ) ( -112 496 256 ) ( -224 -256 256 ) e1u1/grnx2_3 32 0 0 1 1 +( -112 -240 256 ) ( -128 -256 192 ) ( -223 -256 256 ) e1u1/grnx2_3 32 0 0 1 1 +( -127.875 512 192.625 ) ( -112 496 256 ) ( -223 512 256 ) e1u1/grnx2_3 32 0 0 1 1 } // brush 21 { Complete (fixed) .map file is attached: 2box5v5_fixed.zip (25.75 KB). Note that it would appear different from your original version since I had to open and then save it in GtkRadiant under Unix (FreeBSD), which had shuffled things around a bit.
|
|
|
Post by sP1Sp0pD on Jun 3, 2015 20:41:01 GMT -5
You could've simply attached your .map file to this post instead of asking people to spam you via email.
|
|
|
Post by sP1Sp0pD on Jun 1, 2015 5:59:16 GMT -5
I'm not familiar with TrenchBroom, but I presume all editors allow to edit surface/face properties in more or less similar fashion. So, trying to answer your questions: 1. Indeed, normally those sky1 faces have surface flags of (SURF_NODRAW | SURF_SKY) = (0x80 | 0x04) = 0x84 = 132. Apparently that's what TrenchBroom is doing here. To make sky emit light, you have to set SURF_LIGHT (0x01) surface flag in addition to SURF_NODRAW and SURF_SKY, and also set some value. You should be able to do this in your editor's Surface Inspector or similarly named tool. Alternatively, you can modify your .map file with any text editor: search for those e1u1/sky1 faces and change last two numbers to "133 xxx" where xxx is your skybox light value, e.g. e1u1/sky1 0 0 0 1 1 0 133 200. 2. Technically, you do not have to put a light entity in those small ceiling lights: if you set their SURF_LIGHT flag and some pretty high value (e.g. 10000) they will emit enough light by themselves. Again, you should be able to see and set value field (which controls surface emittance when SURF_LIGHT flag is set, just like for the sky we'd just talked about). For bigger lights like ceiling fluorescent lamps you'd probably need a "helper" light entity to achieve better looking results though. Check the last paragraph of this tutorial for more information on the lighting in Q2.
|
|
|
Post by sP1Sp0pD on Jun 1, 2015 3:55:10 GMT -5
If by "java ported version of q2" you mean Jake2, some people had reported getting 267 FPS with it, perhaps there's setup or driver issue on your side? What about native OpenGL programs, do they run fine on your system? I'm a bit puzzled by this "versions [you] can use for Linux that [are] not in that format" phrase of yours. Do you mean whether there are Quake II clients for GNU/Linux that are not written in Java? Surely, plenty of them! There is classic port from icculus.org if you want pretty much vanilla v3.21 experience, there are more advanced clients like R1Q2, Q2Pro, Quake II XP (to name a few), then there are eye-candy oriented ports like EGL and Quake2Max (albeit the last two look like dead now). But their source code is still floating on the Internet, so it's not a problem to build it for your particular GNU/Linux installation. Quake II source code had been around for almost 15 years now, it is well studied and ported to any practically useful platform.
|
|
|
Im back
May 31, 2015 9:34:32 GMT -5
Post by sP1Sp0pD on May 31, 2015 9:34:32 GMT -5
GtkRadiant's shortcuts are widely documented on the Internet; quick googling reveals these three pages for example. Just mind the fact that there could be little differences between versions 1.4 vs. 1.5 vs. 1.6, so don't be surprised if something does not quite work as you'd expected. As a Radiant user, the most useful non-obvious shortcuts for me were Ctrl-Shift-Tab and mouse middle click (alone and with Ctrl) on a brush. Basically, the best way is to try all listed shortcuts and see what suits you in your common mapping routine.
|
|
|
Post by sP1Sp0pD on May 31, 2015 9:17:56 GMT -5
I guess the main reason why nobody is talking about it is because there are too little details available in public to talk about. Their website is little more than a mere landing page, there's no Wikipedia article, and even reddit discussions do not answer the simple question of what makes it better than Q3A/QL/Q2/QW/Warsow, you name it. Just like no one is talking about Reborn I guess... One can get some clues here, e.g. about what maps are cooking up so far, but that's about it. Personally I'm totally happy with Q2 in terms of the atmosphere, physics, weapon balance, and overall gameplay, then there's VQ3/CPMA for more demanding players which arguably is even closer to a perfect FPS than Q2, QW for those old die-hards of classic rockets and shaft, and there's QL for casual gamers who want FPS with modern features like matchmaking, more or less large community, and other social buzz. Sadly enough, Quake Live is becoming less of a classic FPS since recently, as it had been almost killed as we know it, to an extent of being currently on a life support. :-(
|
|
|
Post by sP1Sp0pD on May 31, 2015 6:06:35 GMT -5
Yes, related. Personally I think that using floating point coordinates to allow precise placement of rotated brushes does not warrant it enough. Even with fractional numbers, it is still an approximation, since practically any non-trivial brush transformation (like rotation) would involve irrational numbers. So you've always limited by certain precision which can differ between various editors and tools. Integers are universal, more readable, and just easier to work with. It is usually possible to find close enough integer values to adequately position rotated brushes, and the benefits of floating values IMHO are outweighed by all that nuisance that comes with them. Yes, you can modify brushes by simply editing your .map file by hand (with a text editor), as long as you understand how Quake brushes work. Even if you don't want to dig into these details (although I think anyone who's mapping for Quake II should understand how this stuff works), I guess it's fairly obvious that numbers like "41.9999" look better as "42". P.S. It's QuArK, not QuaRK by the way.
|
|
|
Im back
May 31, 2015 5:32:34 GMT -5
Post by sP1Sp0pD on May 31, 2015 5:32:34 GMT -5
Hi mattflute and welcome back. What makes you think that GtkRadiant sucks for Q2? That's what I use myself for Q2 mapping on FreeBSD (pretty much the same as GNU/Linux in this context) and it works almost flawlessly. Can you list particular problems you've encountered with it, maybe we can give some advice? Even if you don't like Radiant as an editor, QuArK is also actively developed and works fine under GNU/Linux via Wine.
|
|
|
Post by sP1Sp0pD on May 30, 2015 3:00:19 GMT -5
This 2011 article by n00k!e is definitely a must read, albeit it's written from a jumper's POV, not a mapper's. But certainly if I ever attempt to do my own research into this problem it will be listed in bibliography section. ;-)
|
|
|
Post by sP1Sp0pD on May 29, 2015 7:36:03 GMT -5
No, I was mainly talking about integer vs. non-integer brush coordinates, for example:
// brush 85 { ( 1024 -512 -16 ) ( 1024 -640 -16 ) ( 1152 -512 -16 ) giftdm8/mt_pv_m16bb 0 0 0 1 -1 ( 2304 256 0 ) ( 2304 384 0 ) ( 2432 256 0 ) giftdm8/mt_pv_m16bb 0 0 0 1 1 ( 384 -144 224 ) ( 384 -144 352 ) ( 512 -144 224 ) giftdm8/mt_pv_m16bb 0 32 0 1 1 ( 1018.0821533203 63.9999847412 -32 ) ( 1018.0821533203 63.9999847412 96 ) ( 890.0821533203 63.9999237061 -32 ) giftdm8/mt_pv_m16bb 58 32 0 -1 1 ( 1520 303.9999694824 512 ) ( 1520 303.9999694824 384 ) ( 1520 431.9999694824 512 ) giftdm8/mt_pv_m16l 0 48 -90 1 1 ( 1536 -448 0 ) ( 1536 -448 128 ) ( 1536 -320 0 ) giftdm8/mt_pv_m16bb 0 0 0 1 1 } You can see that some values are fractional, but still pretty close to an integer. This can be collateral effect of earlier brush transformation(s); it can also occur as a result of initial BSP→MAP decompilation. When it happens, I typically fix them in a text editor (too lazy to write a script).
Now, things can get worse. Take a look at aforementioned brush 1277:
// brush 1277 { ( 1617.0883789062 563.5979614258 125.6568756104 ) ( 1681.0883789062 627.5979614258 35.1472015381 ) ( 1681.0883789062 627.5979614258 216.1665344238 ) giftdm8/mt_pv_m16bb 18 27 54.7356109619 0.8660299778 -0.8165000081 ( 1707.5979003906 473.0883789062 125.6568756104 ) ( 1643.5980224609 409.0883178711 216.1665344238 ) ( 1771.5980224609 537.0883178711 216.1665344238 ) giftdm8/mt_pv_m16bb 14 0 54.7356185913 0.8660299778 0.8165000081 ( 1601.0882568359 547.5979614258 148.284362793 ) ( 1691.5979003906 457.0883178711 148.2843170166 ) ( 1665.0883789062 611.5980224609 238.7938995361 ) giftdm8/mt_pv_m16bb 27 41 45 0.7071099877 -1 ( 1585.0882568359 531.5980224609 170.9117126465 ) ( 1675.5980224609 441.0883789062 170.9116668701 ) ( 1521.0883789062 467.5980529785 80.4020080566 ) giftdm8/mt_pv_m16bb 5 41 225 0.7071099877 1 ( 1585.0882568359 531.5980224609 80.4020233154 ) ( 1675.5980224609 441.0883789062 80.4020690918 ) ( 1649.0883789062 595.5980224609 -10.1075744629 ) giftdm8/slight02 27 105 45 0.7071099877 -1 ( 1604.4019775391 550.9116821289 107.7156982422 ) ( 1694.9116210938 460.4020385742 107.715713501 ) ( 1540.4019775391 486.9116821289 198.2253875732 ) giftdm8/mt_pv_m16bb 43 41 225 0.7071099877 1 } The brush definitely needs some love! ;-)
P.S. I also do not share that cursing attitude towards clipping tool that some folks tend to exhibit. There's nothing inherently wrong with it, and it can come quite handy, although it makes sense to check the final result as you might want to adjust newly added brush face(s). Basically, any tool one might like is OK as long as resulting brush comes out sane. However, do not blindly trust your editor and always review the actual changes made to your map after applying them. Putting your map under version control system (e.g. Mercurial/Git/SVN/CVS, whichever you prefer) can be a huge helper in this regard.
|
|