FreeGameDev

qreeves {l Wrote}:I suggest you only post textures which you are actually going to use in a map. I won't include textures just for the sake of doing so, as a large number of textures are unused, they just take up space in our download.

qreeves {l Wrote}:

4rson {l Wrote}:Some way of copying textured geometry to a library of primitive objects. To be useful this would require textures to be automatically offset and rotated to accommodate for translation and rotation of the stored geometry.

Will possibly be coming to the Cube Engine in general soon. See: http://cubeengine.com/forum.php4?action=display_thread&thread_id=2542

TristamK {l Wrote}:And if CFG of map have to much textures , map creator can delete textures that he never use on this map from them .

So textures are stored in map cfgs? Because, correct me if I am wrong, they are not. They're in Red Eclipse/data.

4rson {l Wrote}:A fog material might be nice to allow variable amounts of fog in different areas of the map. Perhaps this might be a bit difficult to use with other materials.

4rson {l Wrote}:Have the fog affect the skybox. Currently it looks a bit strange if you have a non-cloudy skybox but a reasonable amount of fog in the map.

restcoser {l Wrote}:1. An "Link inverter" entity. Relativly simple, inverts the input(s) it gets from the linking and outputs it inverted. The possibilities with this are huge, i.e. you could make an AND- logic gate and combine different inputs.

qreeves {l Wrote}:

restcoser {l Wrote}:1. An "Link inverter" entity. Relativly simple, inverts the input(s) it gets from the linking and outputs it inverted. The possibilities with this are huge, i.e. you could make an AND- logic gate and combine different inputs.

Could you elaborate on this one a bit more? I don't quite understand what you mean, maybe give me an example?

restcoser {l Wrote}:Being able to link playerstarts. Playerstarts would give a short ON/TRUE signal in the moment a player is spawning at that playerstart, allowing you to do extra spawn effects, like particles rising upwards as the player spawns. At the moment you have to use a Proximity trigger at the player spawn to archieve a similar effect. I don't think this would be difficult to code, either.

qreeves {l Wrote}:

restcoser {l Wrote}:Being able to link playerstarts. Playerstarts would give a short ON/TRUE signal in the moment a player is spawning at that playerstart, allowing you to do extra spawn effects, like particles rising upwards as the player spawns. At the moment you have to use a Proximity trigger at the player spawn to archieve a similar effect. I don't think this would be difficult to code, either.

Indeed, pushers already do the same thing.

wowie {l Wrote}:I think what he meant was that pushers already send a signal when activated (e.g. to a linked sound entity) so it wouldn't be too much work to allow spawnpoints to do the same thing because most of the code involved could just be copy/pasted with little to no effort involved....

• The ability to kick, and punch, all the time. Right now you can only kick with impulse enabled, and can't punch.
• Ability to mod in more than the 9 weapons.
• Ability to change the death messages (for mods)

Iridium {l Wrote}:- Ability to simplify death messages (eg. from bot [1] was filled with shrapnel by Iridium to You Fragged bot [1])

Dratz-_C {l Wrote}:I know I am not supposed to post again but I think this request is important enough to merit it.
According to my reading here, 1.2 does not transfer the waypoint file with the map. In order that bots behave as they should for all parties, in all situations, map transfers to and from a server should contain the waypoint file when it can be found. One might also want to implement the transfer of the mapname.txt license file when it can be found. That would mean that map authors would have to begin conforming to a mapname.txt naming convention but if we can get over this hurdle, I think it would be good for the game, be it 1.3 or after.
Cheers