|
Post by sP1Sp0pD on Nov 18, 2019 4:28:14 GMT -5
Hi there, apparently it's time to necro this post again. :-) Previously (long time ago), there was this 114MB file all_q2_textures_07_17_2006.zip available for download from justjim's personal page at University of Michigan. Several years later (ca. 2010?), directory structure was reorganized, and that file was replaced with a different one, apparently more complete, 377MB q2_textures.zip (without embedded date in the file name, but should be 04-12-2009). I also have another version of those textures, textures_05-06-2008_tga.zip (200MB). Google didn't turn up any working links or mirrors. If anyone still has that original file from 2006 on their harddrive somewhere, I'd appreciate if you could upload it somewhere, at least for a short while. Hosting 114MB should not be a problem these days, but if you need help with space, tell me and I'll arrange something up. For the record, below are the relevant metadata to verify file's identity: - SIZE (all_q2_textures_07_17_2006.zip) = 119631164
- MD5 (all_q2_textures_07_17_2006.zip) = 04ad930517f9af082c25caf8490141a8
- SHA1 (all_q2_textures_07_17_2006.zip) = 1784e60bd86f5cc186f15cc8f711ec0438705293
- RMD160 (all_q2_textures_07_17_2006.zip) = c9647d372dd3ba332205ef6540f3cbff269bd8b3
- SHA256 (all_q2_textures_07_17_2006.zip) = af741dc4637693f9804fc8d6fc59604317033f3e436671bda028d3ce81f8910f
|
|
|
Post by sP1Sp0pD on May 6, 2018 22:34:06 GMT -5
It is quite possible, but is in no way straightforward and would take considerable effort. I haven't seen any ready-to-use tools; at least few years ago when I was playing with the idea of converting some of the Unreal maps (.t3d, conversion to/from .obj is easy so this example probably applies here) I had to craft a quick'n'dirty Perl script for that. Unfortunately I had never finished it, let alone making it production quality.
You probably won't find general solution that would eat any *.obj file, but for a particular one it should be possible to come up with some hackish, ad-hoc solution.
|
|
|
Post by sP1Sp0pD on Apr 12, 2018 2:42:08 GMT -5
You clearly didn't understand the original question quakelover; perhaps you would reread the first message more carefully, not just the subject (which is indeed somewhat confusing).
|
|
|
Post by sP1Sp0pD on Mar 27, 2018 2:47:12 GMT -5
You can try to make them yourself, actually, it's not hard. Start from here and here (those are for Quake Live, but you'll get the idea, procedure should be essentially the same for Quake II).
|
|
|
Post by sP1Sp0pD on Sept 18, 2017 10:37:42 GMT -5
I haven't tried it, but watched a bunch of games from the past QuakeCon. It generally left me favourable impression despite all the circulated controversy on sites like ESReality; QC is still a Quake. The idea with heroes with different abilities, picks thereof, five-minute games, etc. seems to work out. I liked that QC managed to jeopardise the world's players top: old stars no longer dominate by default, but must adjust their playing styles and learn again in order to win (at the same time not being thrown way too back down the ladder like in OW, a Quake is still a Quake). It was nice to see many old names in the lineup. Some of the new maps are also nice; particularly, I'd like to port Corrupted Keep to Q2 after we know how to extract map geometry out of those *.pak files and their contents. Update: Some food for thought: www.esportsheaven.com/articles/view/6147
|
|
|
Post by sP1Sp0pD on Dec 1, 2016 13:00:31 GMT -5
It's always nice to see some of the old folks around. Q2C is one of the last places on the Internet for us Q2 mappers, so just keep it alive, it's all I personally need. Kudos!
|
|
|
Post by sP1Sp0pD on Apr 28, 2016 9:36:48 GMT -5
These messages could come from functions CL_Download_f() and CL_CheckOrDownloadFile(), defined in client/cl_parse.c. Usually, Quake will attempt to download resources that are missing on your computer, but if their path contains reference to upper directory (that is double dot, ".."), I would guess it suspects that something fishy might be going on, and refuses to proceed for security's sake.
You should make sure that your map does not use or reference any textures with those kind of bogus names. On Unix-like systems, an easy way to check this is by using grep(1) over the .map source file, or grepping strings(1) output from the compiled .bsp file.
|
|
|
Post by sP1Sp0pD on Apr 27, 2016 7:19:54 GMT -5
But let's say you build up a sufficient array of relays, would it be possible to have the lasers/lights do morse code? I don't see why it wouldn't be (assuming we're talking about transmitting some constant, predefined message at least).
|
|
|
Post by sP1Sp0pD on Apr 24, 2016 5:54:10 GMT -5
You most likely forgot to set your timer's start_on property (spawnflags = 1), so it never fired. However, this combination still wouldn't work as expected: trigger_relay will trigger first at X+Y+X seconds (as expected), but then continue to trigger every X seconds (that is, not X seconds after every X+Y seconds, just after the first one). With func_timer kicking in (every X+Y seconds), new independent X-periodic trigger_relay loops will be spawned, eventually leading to event avalanche.
|
|
|
Post by sP1Sp0pD on Apr 23, 2016 9:56:17 GMT -5
> ... trigger_relay without a delay seemed a bit superfluous to me. All that should be needed is one timer to control another with different timings.
I'm afraid that's too technically vague for me to give substantive commentary. Can you show us how exactly (well, more or less) those two timers should look like, in your opinion? And why would trigger_relay without a delay be superfluous? Relays are used for one-to-many distribution of events; optional delay is completely orthogonal to this (although no doubt very handy).
After giving it more thought I am now more inclined to believe that func_timer approach is suboptimal here. Also, my earlier analysis of those triggers in security.bsp was inconclusive. Eventually I've come up with the following (working) triggers for a laser parametrized by X (on time), Y (off time), Z (initial delay aka phase shift, may be zero):
// laser entity skipped; assumed to be initially OFF (starton = 0) ... { "classname" "trigger_always" "target" "mult" } { "classname" "trigger_multiple" "targetname" "mult" "target" "relay" } // this trigger turns the laser ON { "classname" "trigger_relay" "target" "laser" "targetname" "relay" "delay" "Z" } // this trigger turns the laser OFF after X seconds { "classname" "trigger_relay" "target" "laser" "targetname" "relay" "delay" "X + Z" } // this trigger refires the main loop, leaving laser OFF for Y seconds { "classname" "trigger_relay" "target" "mult" "targetname" "relay" "delay" "X + Y" } I hope this is clear enough, so I wouldn't have to upload new version of that laser2.map (tell me if it is not). What's still unclear though is why did they forward initial trigger_always event through trigger_once... Perhaps this is some kind of optimization, as trigger_once is destroyed after being fired?
|
|
|
Post by sP1Sp0pD on Apr 22, 2016 10:21:16 GMT -5
knightmare is right, trigger_relay is the way to go. It works because several relays can share the same targetname which can be targeted from e.g. func_timer, and you can emulate independent on and off times by using different delay values of those relay entities (note that you need two relays). I'm attaching a simple map, laser2.map (5.69 KB), which has a laser that is turned on after 4 seconds into the game, fires for 3 seconds and sleeps for one (3 + 1 = 4). It can probably be optimized further by removing initial X+Y delay. What's more interesting, however, is that apparently security.bsp (aka Grid Control) implements this differently, by using trigger_always -> trigger_once -> trigger_multiple -> ( n * trigger_relay) -> target_laser chain. I've tried to play around with it, but most likely didn't find correct spawnflags, got bored, and stopped. It would be nice to figure out how exactly this approach works though.
|
|
|
Post by sP1Sp0pD on Apr 10, 2016 6:12:39 GMT -5
Did you read Panjoo's old tutorial on lasers? Particularly, there is example.map with four of different kinds of uses of target_laser (and func_timer) which you might find helpful to study.
|
|
|
Post by sP1Sp0pD on Mar 25, 2016 1:23:43 GMT -5
It's pretty straight-forward actually. Fire it up; it will present you with a startup screen, split in two vertical halves, with "New map" and "Browse" buttons on the left and a list of recently worked files on the right.
For a new map, or if TB cannot determine game type of a map you're trying to open, you'll be presented another screen where you should set your system's game path(s) there, e.g. I had Q2 point to /home/danfe/.quake2 as that's where I keep all its resources, download demos, develop maps, etc.
Unlike in Radiant, you can immediately use ASDW keys to navigate around the map, but having to actually press+hold the RMB to be able to change viewing angle (that is, mouselook it not toggable like in Radiant) is a bit annoying (YMMV). There lots of other differences obviously, but one should find herself comfortable with TB after a few hours I think. Mouse and keyboard settings are quite customizable, check the Preferences menu.
It does not seem to support map compilation from within itself, so you'd have to call q2map by yourself (or even better, write a Makefile).
|
|
|
Post by sP1Sp0pD on Mar 17, 2016 21:43:13 GMT -5
Does QuArK produce any error message when it fails to load your map? If you suspect the problem is in your entities (easy to check: just remove them in a text editor and try to reopen the map in QuArK), you might try to iteratively remove them (think binary search) and locate the bogus one(s).
You could also attach your *.map file so we can take a look.
|
|
|
Post by sP1Sp0pD on Mar 17, 2016 10:57:37 GMT -5
Hmm, perhaps you should check your info_player_deathmatch entities and see if any of them is outside the map (albeit I'm not sure a map with such a bug could be even compiled).
|
|