textures2quake, next bounty claimed

« The Lingering Legacy of id Software’s Quake: A Glimpse Into Thirteen Years Of Darkness || Your favourite map in 2009! »

## textures2quake, next bounty claimed

Baker has released a tool to convert image files to Quake textures. It adjusts the length of the filename if needed and keeps a log of those renamings. Converting “modern” texture sets to use with Quake and engines that support external textures has never been easier.

Baker declined the bounty and instead proposed a new one: Provide whatever is needed in QuakeC to use origin brushes. Please read through this thread if you are interested. We are both not sure how to properly phrase the goal.

24.01.2010 in quaddicted.com | 17 Comments »

### 17 Responses to “textures2quake, next bounty claimed”

1. Baker Says:
   25.01.2010 03:05

   The QuakeC for origin brush support would probably be:

   1. func_rotating_door
   2. func_rotating

   Raw thoughts:

   Probably not all of this, but some of it for sure:

   http://developer.valvesoftware.com/wiki/Func_door_rotating
   http://www.superjer.com/learn/func_door_rotating.php

   And …

   Probably some of that …

   http://developer.valvesoftware.com/wiki/Func_rotating

   And the ability for sure to make a func_rotating come down as a drawbridge.

2. jdhack Says:
   28.01.2010 07:32

   Funny coincidence: I was working on a similar rotation thing just a few weeks ago (if I’m understanding this challenge).

   Here’s how mine works:

   1) mapper sets up a single entity, just like func_door but with a few extra fields set

   2) bsp gets built as usual (qbsp,vis,light), then gets processed by a new custom util

   3) this util does the repositioning, which means entity is lit & textured in its proper position

   4) a bit of QC: this could be a simple wrapper around the Hipnotic stuff, or (in my test case) could even create the necessary clip brushes

   Is this sort of what you’re talking about?

3. jdhack Says:
   28.01.2010 10:00

   Hmm, guess I should’ve read the entire Inside3D thread first :) Similar goal, different methods.

   But still, is an origin brush any easier to use than an info_rotate entity? And without engine support, you still have to do all the clip-brush movewall crap. But if anyone mentions engine change over on func, it gets shot down pretty quick…

4. Baker Says:
   28.01.2010 18:37

   jdhack here is a modified FitzQuake 0.85 with rotation support:

   http://www.quake-1.com/docs/rotate/fitzquake085_avirox.zip

   Here is a sample rotating map with map source:

   http://www.quake-1.com/docs/rotate/rotate_map.zip

   The map source was compiled with LordHavoc’s hmap2 …

   http://icculus.org/twilight/darkplaces/files/hmap2build20100113.zip

   Currently, the origin must manually be specified in the entity such as “origin” “0 0 0″. Eventually I hope we end up with origin brush support in one or more compilers … the idea is that with the Quakec to support func_door_rotating and func_rotating that this will fuel momentum to the map compiler changes done ;)

   [The map compiler changes are part of a bounty item too]

5. jdhack Says:
   29.01.2010 09:28

   So then, we’re talking about something that requires engine support? (For the record, I believe that’s the simplest way, and my engine has it already.) But my impression is that the mapping community is wary about using features that behave differently from engine to engine.

   IMO, the best implementation would be QC that uses the DP_SV_ROTATINGBMODEL extension if it’s available, but otherwise falls back on the func_movewall clip brush workaround. I think something like that would stand a better chance of actually being used. Just my 2 cents.

6. Baker Says:
   29.01.2010 18:09

   Warpspasm requires engine support. A Roman Pain of Wilderness requires engine support. Soul of Evil Indian Summer requires engine support. Fort Driant requires engine support. APSP2 requires engine support. Masque of the Red Death requires engine support. Vertical Base requires engine support.

   Most maps don’t run with GLQuake.exe nowadays.

7. Baker Says:
   29.01.2010 18:39

   Maybe another way to think about it is that 3 years ago most engines didn’t have .alpha support and now essentially all of them do.

   A feature doesn’t gain acceptance without being tested or piloted.

   The Quake Remake guys want this feature and the demand for rotating doors and such has been growing ever since Avirox released the Quake-Life mod for Quakeworld.

   Prior to Warpspasm — which requires double gamedir support — no one said they’d download a custom engine to play a single player release. Warpspasm was hugely popular.

   A new feature’s success is more a function of demand, what it adds to the map author (hipnotic is mega kludge).

   Origin brushes are a standard feature of Half-Life and Quake 3 and such.

8. Baker Says:
   29.01.2010 19:12

   Might as well add since I’m already being chatty. This is not only compatible with the rather easy engine tutorial Avirox wrote up at Inside3, but runs in DarkPlaces as well.

9. mh Says:
   30.01.2010 22:41

   Has anybody looked at the HexenII QC for rotating brushes? Seems like it might be a logical place to start.

10. Baker Says:
    01.02.2010 03:36

    I kind of like jdhack’s idea of falling back to something else if rotation isn’t available as an eventual “like to have” goal.

    I have a growing feeling I’ll probably be writing the QuakeC for door rotation, I’ve look through enough qc to get a mental picture of how it should work.

11. Ron Says:
    01.02.2010 10:35

    I (still) don’t know if it would be possible, but I would love to have texture flags for Quake, like Quake II has. Light, Slick, Trans, Flowing, etc.
    It could lead to a drastic graphical improvement of the game, I see some great ways to implement them in new levels/mods.

    The func_rotating_door project is cool though.
    Good luck working it out.

12. Baker Says:
    01.02.2010 13:31

    Ron, that’s on my list too. Maybe not as in-depth as you listed, but if mine happens then yours happens almost by default ;)

    More or less all that needs to occur is a function in the engine that identifies the texture name that is being walked on. Darkplaces/FTE might even have this currently.

    A somewhat related thread @ Inside3d on this topic:

    http://forums.inside3d.com/viewtopic.php?t=1885

13. Ron Says:
    03.02.2010 16:02

    Sounds great, Baker.

14. Ron Says:
    07.02.2010 14:49

    What also maybe could be solved is the lava not hurting monsters. It’s really annoying, because you can’t always get a 100 % score if one falls into the lava, as you can not follow or even see him.

    Also, the falling down always hurts player the same, no matter how high you fall from. It’s not too bad, I guess, but a pain ratio attached to the distance of the fall would be nice, if do-able.

15. Baker Says:
    07.02.2010 14:58

    Those are both easy QuakeC fixes.

    The RQuake mod … a very popular multiplayer NQ mod has monsters explode when they fall in lava (why waste time with the inevitable, they are too dumb to get out) …

    Likewise, more realistic falling damage is easily achieved in QuakeC. Nehahra did this, for example. Play Nehahra and jump off somewhere high and see what happens …

16. Baker Says:
    07.02.2010 14:58

    Oh yeah, Nehahra had monsters killed by lava too.

17. gb Says:
    18.02.2010 23:34

    I think the mapping community is changing.

    Anyway, I was meaning to say that RMQ has relative fall damage, as well as burning and drowning monsters (water escape AI is on the list).

### Leave a Reply

Name

Mail (will not be published)

Website