#290 should have been posted in Phone Thread :P 

for the explanation.

I changed six func_wall ents but for some reason the signon buffer keeps alerting.
Think I delete some entities as it seems the most simple solution. 

Talking to a friend about playing Quake on Linux

fitzquake has horrible issues with x86_64
namely using unsigneds to store pointers, VERY BAD PRACTICE

Thought whoever is going to be working on the next version might want to know about this... 

yeah, pointers are treated as 32-bit in various places. Maybe if 64-bit becomes important, I'll figure out what is needed to fix it. 

Since when did quake need to address more than 4 gigabytes of memory? 

For the sake of keeping FitzQuake 0.85 stuff where it can easily be found:

FitzQuake085_rotate.exe (with source)

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

Sample rotating object map (rotate.bsp and rotate.map compiled with LordHavoc's new version of hmap2)

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

Rotation support (avelocity) added from this tutorial:

http://www.quake-1.com/docs/quakesrc.org/129.html

YouTube video of spinning object in DarkPlaces, appears to work and look the same in FitzQuake085_rotate.exe:

http://www.youtube.com/watch?v=Bke3wPWsH38 

What the hell is going on in that video? :) I can't tell what's rotating ... the player? But why is the room turning ... I .. ARGH!! 

the player is not rotating, but the thing he's standing on is.

How is this different, in technical setup and/or mapper use, than Hipnotic's rotating stuff?

Could be a big boon if the texturing of these rotators is more sane. 

no func_movewalls 

I've been following the thread on i3D as you guys discussed this. The remaining things I think would be ideal:

- engine: rotate player orientation as the object they are standing on rotates.

- compiler: origin brush support for ease of use

- compiler: fixed texture alignment on rotating models (right now it's all wrong because the brushes are moved to the world origin during the compile process without locking the textures)

Also I believe the way collision is being done for this is not correct, rotating the collision hulls can have some pretty non-optimal results, especially if you rotate a bmodel onto its side, since player bounding boxes are taller than they are wide. But doing it correctly would be pretty hard. I think what quake2/3 do is, save the original brushes in the bsp file and expand them to collide as needed, and don't use hulls at all. 

Although there are many theoretical things that can be done with rotation and known issues with it in Quake, I only care about rotating doors. ;)

Maybe draw bridges that rotate down too.

Hip rotate doors kill me and otherwise are all weird. And if map authors want spinning things for show and level atmosphere, they can always put some clip around them ... to my knowledge the hiprotate objects have the same problems but at least these are FAR easier to setup. 

The hiprotation objects have some problems, but they are consistent - the movewalls themselves don't rotate, so they don't start colliding with the player differently depending on the rotation it takes. Score one for hipnotic I guess... 

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

Rockets and grenades appear to collide properly. ;) 

point-size entities will behave correctly, since a rotated point is still point-sized. It's hull1 and hull2 which are built around box-shaped entities which will exhibit inaccurate collision when the hull is rotated. 

I believe for legacy maps, and people who simply want to keep using them, hiprotate will not go away... Quoth supports it nicely, RMQ will keep supporting it as part of its backwards compatibility effort etc...

For those of us who would like to do it in a more sane way in the future, the avelocity based rotation will be a gift of the gods.

Meaning, with RMQ and other forwards-compatible mods, you'll be able to have what you prefer. 

what does it mean:

it's from a console log
-------------
]quit
VID_Gamma_Restore: failed on SetDeviceGammaRamp
------------- 

ATI sucks. 

i got nvidia 

Well, I think it says something about not being able to restore the original gamma (of the OS versus the one ingame). 

it means restoring your desktop gamma setting didn't work, but i'm not sure why -- windows doesn't give any useful error messages when that happens. 

That's what it means.

A piece of shit geared towards your needs, the users needs.

I can't be arsed - but imagine I'd just gone on for a while about how magical a piece of shit can be, but at the end of the day is still something that won't fuck off no matter how many times you flush. 

also, after talking to somebody by email (baker, jpl, or spirit, or maybe someone else)... that person told me he was getting the message even int cases where the gamma change actually worked! So sometimes the "failure" isn't actually a failure, from that one user's report. 

Post failed! 

They fall true the map.
In all the other engines they hang on the wall, but in Fitz ver .85 they either appear normal, throwing meat at you, or they fall true the map.
I don't get it.
If I start the start.bsp map, they are all hanging nicely on the wall, but in my own (nearly done) map, they don't. 

Can't delete my previous post.
There was something wrong, but it was because I was using an alternative pack.

Sorry ...