You don't want textured clips. You want to map for cube 2.
It's weird - I thought, there were at least timestamps on xmaps, but apparently, there are none. We do have timestamps on backup files, though. Of ac_desert_1429805894.BAK, the number is the time, the backup was created. A timestamp inside the cgz would be for informational purposes only - the "newer version" (for example on a server) would still be determined by the revision counter.
I'm bringing this over from the other thread...
Would map options to disable certain features be of use? For example, setting a maximum value for waveheight could help maps like ac_desert, where the only water is in a well, and waves look a bit weird. Some map environments may call to disable water reflection and refraction as well. It would be ugly to implement, so I'd like to know, if it would be of actual practical use...
Is that mod available somewhere? The question is mostly, how should the shadow entity behave. Regular light entities throw shadows at map geometry - I'd guess, a shadow entity would not need to do that ;)
Would a circular shadow area, with a core radius of constant darkness and an outer area of decreasing darkness be sufficient? Uninflicted by map geometry and rendered after all regular lights? (That would mean, a shadow would reach through walls.) Would a shadow need coloring, or should it be "white"? Should the shadow decrease the light by absolute numbers or as a percentage?
You are right: the implementation of shadow entities is fairly simple. But to design them to be easy to use is a bit harder :)
Currently, light calculation starts with the ambient light value as a start value and then all lights add to those values (up to a max value of 255). If we add shadow entities to subtract from that value, we also need to clarify, if a shadow should be able to cause a cube to be darker than ambient light - or if ambient level should stay the lowest possible value.
It's weird - I thought, there were at least timestamps on xmaps, but apparently, there are none. We do have timestamps on backup files, though. Of ac_desert_1429805894.BAK, the number is the time, the backup was created. A timestamp inside the cgz would be for informational purposes only - the "newer version" (for example on a server) would still be determined by the revision counter.
I'm bringing this over from the other thread...
(08 May 15, 09:31AM)Mr.Floppy Wrote: I understand why some mappers ask for more control over client graphic settings and such, since it might open opportunities to circumvent some of the given limits. Though, as I have said already, it is not acceptable to allow mappers to change the users' personal settings in first place. Those methods are most likely going to make things less stable, because no mapper will be able to foresee the actual outcome on all those various clients. After all it's the mappers' job to deal with this boundaries, at least that's my opinion.
Would map options to disable certain features be of use? For example, setting a maximum value for waveheight could help maps like ac_desert, where the only water is in a well, and waves look a bit weird. Some map environments may call to disable water reflection and refraction as well. It would be ugly to implement, so I'd like to know, if it would be of actual practical use...
(08 May 15, 09:31AM)Mr.Floppy Wrote: The only feature I can think of which could be implemented rather easily and would bring great benefit are negative light entities, which then will be effectively shadow entities. There has been a mod around quite some time ago.
Is that mod available somewhere? The question is mostly, how should the shadow entity behave. Regular light entities throw shadows at map geometry - I'd guess, a shadow entity would not need to do that ;)
Would a circular shadow area, with a core radius of constant darkness and an outer area of decreasing darkness be sufficient? Uninflicted by map geometry and rendered after all regular lights? (That would mean, a shadow would reach through walls.) Would a shadow need coloring, or should it be "white"? Should the shadow decrease the light by absolute numbers or as a percentage?
You are right: the implementation of shadow entities is fairly simple. But to design them to be easy to use is a bit harder :)
Currently, light calculation starts with the ambient light value as a start value and then all lights add to those values (up to a max value of 255). If we add shadow entities to subtract from that value, we also need to clarify, if a shadow should be able to cause a cube to be darker than ambient light - or if ambient level should stay the lowest possible value.