I'm having a hard time thinking of good uses for those. Conveyor belts aren't enough.

Skies and water don't need regular scrolling textures in my engine. And scrolling whole background environments as in the train level of Soldier of Fortune is too restricting.

:\ I just can't think of regular environment details that would be improved by scrolling textures. 

Flowing water? That seems like a really commmon thing a mapper would want to do. 

Molten mapping already takes care of that, in a much better way. 

Have always been an edge case thing, used for weird tricks here and there, like machinery, visual effects and the classic 'train rushing through a tunnel but not really moving' effect.

Someone will always be able to think of something to use it for. 

Molten mapping already takes care of that

I'm tempted to say "a-whu-what now?" but I actually do remember some postings of flowing lava - had no idea that was your engine - cool beans. 

I just can't think of regular environment details that would be improved by scrolling textures

On the other hand I am attracted to them, as they can improve the environnement. I would love it to see a map with more then four sky types, or animating monster skin textures.

Set me on the train if I can unlock the button. 

I would love to make a speeding train level. I have a few ideas on how to do it. 

Slightly unrelated, but yesterday I've raised the BSP texture frames limit to 100, and added support for the +number naming convention anywhere. This allows for textures like {fencepants+18b , for example. 

I need animated fences!

About scrolling, remember those Q3A scrolling neon trims? 

Great you're upgrading the bsp compile code!
I've made a map with four turning skyboxes, in the way that it are large static entities. It perfomes some kind of changing period within one map.

Only min point is that I can't overcome the 240 frames on 0.1 sec so it still some kind of fast movement. If the frame limit of 256 could be passed it would look like the original Q2 standard. 

On an unrelated request, I really think you should reconsider colored lights. Warm hearted. 

MadFox: It's in-engine only, actually. But indeed, the BSP compiler would need some changes to include all extra frames without manually applying each frame in the map editor.

Adib: It's been a very long time since I've played Q3A. I gotta remember to take a look at it again.

I'm slowly thinking about colored lights, and should implement them after figuring out an optimal way. I already have a good idea that may work well, and will try it when possible. 

I think a func_wall with the .avelocity field set may work way better for what you're doing.

A proper solution would be a more flexible skybox system. Mine is full of bugs yet. 

That's what I also thought, but the func_wall acts rather bumpy compared to the static_entity. 

mankrip, that reminds me. an absolute must for all engines is full floating point for angles and not shorts! 

That doesn't look like shorts. This reminds me that the FitzQuake .85 protocol still uses single bytes for some kinds of angles, but I can't remember which. 

yeah sorry, they are unsigned bytes. either way, it ends up that there are actually less values (255) than angles which... ok, I know they were trying to pack in a lot of date into as small as they could, but it looks baaaad. :( 

The func_wall rotation goes with a info_not null avelocity "0 1 0", while the static_entity turns 240 frames self.nextthink = time + 0.1;.

I think the func_wall only counts degrees while the static entity rolls more smoothly.