Wishlist for 1.3

[TristamK]

This website http://opengameart.org/textures/ have a filter . When i press cc-by-sa in check box all textures with this lisence will showed . But here i see only few good textures
1 http://opengameart.org/node/10927
2 Mmmm .Maybe this mevieval textures can be used too .
http://opengameart.org/node/8728
http://opengameart.org/node/8727
http://opengameart.org/node/8726
http://opengameart.org/node/8729
3 Maybe this pack
http://opengameart.org/content/29-groun ... -1024x1024
But i am not sure about lisence
4 http://opengameart.org/node/9285
5 http://opengameart.org/node/9286
6 http://opengameart.org/node/7081 - ?
I think that the textures have required license ...
And that all that i find at this moment

[qreeves]

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.

[TristamK]

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.

I can use all textures that i post . Without maybe some ground textures .
At this moment on my maps i use 60%-70% of textures that RE have . But other map's creators can use this 30%-40% that i isn't use .
And if CFG of map have to much textures , map creator can delete textures that he never use on this map from them .
Later if i will find more textures - i say what textures will be a good to include in RE .

[Dratz-_C]

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

This is an appropriation whose progress I am following. There's a few other exciting projects in the thread which I recommend mappers read about. I am grateful to Quin for bringing it up.
Cheers

[Remilia Scarlet]

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.

~1~Variable model quality. Some people don't have slow computers, it would be a shame not to use higher poly models if they are available. Those with slower computers could reduce the quality of models in the options menu.

~2~Realtime map geometry and lighting updating (including during games, for map destruction(*gulp*))... This would probably take some work though...

~3~Material "variable". allows mappers to set individual characteristics such as particle collisions for the material, per map. Eg. on a map, a laser will bounce of variable material set geometry, on another it may not etc.

~4~Rifle rename to laser, or get rid of "lasershocked"... However overused it may be, laser 'rifles' do not make sense... Btw. I don't have a real problem with it, it would just... Add realism...

[TristamK]

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

CFG files have way for textures . If you delete a way for texture from CFG file of map as a result this texture will isn't load in next time when you load map . Also command /texturecull help with faster map's loading .

[4rson]

Two more thoughts:

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.

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.

[qreeves]

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.

Not possible due to engine design limitations.

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.

Use the /fogdome* variables.

[Remilia Scarlet]

I apologise...
The way I interpreted quin's post is that he meant the total file-size of Red Eclipse when downloaded from, say, sourceforge...
If he meant uploaded to the server your post makes perfect sense...

~3.1~Map maker could add multiple 'variable' materials, each with their own properties. Properties could include:
Collision for particles, as with weapon variable partcollide;
%var damage per %var ms, where %var is a user changeable variable. Denotes the amount of damage the player takes while inside the material and in what increments, eg. 1/1000 is 1 point of damage every second, 15/250 is 15 points every quarter second.This would also allow for non instant kill damage via terrain;
Incendiary, if the player is touching a variable material with this property enabled they are set on fire;
Colour, denotes what colour the variable volume should have;
Name, self-explanatory;
Liquid. The material behaves like a liquid with 'underwater' fog and physics;
Fogrange. Changes the view distance when submerged in the material;
etc.

~5~Entity 'flame'. The player is set on fire if touching this entity.

~6~Entity 'emitter/cannon'. Emits a particle upon activation (via interactive, linked zone, etc.) that can be set, such as rockets or a laser. Basically a cannon.

[restcoser]

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.

2.Different default weapon names. There is the option to name the weapons in the svn, but it is not used yet by default. Weapon names like "smg" are just uncreative, some different names can add here much.

3. Make the smg's primary fire a bit more powerful. I've seen the suggestion before, and i support it.

[qreeves]

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]

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?

A link inverter is an entity that outputs TRUE if all inputs are FALSE and that outputs FALSE if at least one input is true.
As a practical example, you could create a door that closes when you approach it :P
Even more useful stuff could be made by combining several Link Inverter/NOT-Gates. AND-Gates can be made, so that you have to pull a lever as well as approach the door.
I'm afraid i didn't explain too well what I basically mean, bu I hope I get the point across. Entity linking is very powerful, and this could enhance it.

Maybe another wishlist point:
*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]

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.

[restcoser]

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.

Now a bit more explanation on your side would be good

[wowie]

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... but then again I know next to nothing about coding so I could be completely and totally wrong in the worst ways possible.

...correct me if I'm wrong.

[qreeves]

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....

Yep, exactly.

[BioHazardX]

My wishlists:

- cool weapon models like the new pistol. Shotgun, submachinegun and rocket launcher are not very good;
- add a proper bull's eye viewfinder for the sniper when you zoom;
- add the 2d targets in the menu and add more options in the GUI;
- add "no weapon bobbing" and "no sound ambient" client settings ;
- customizable HUDS.

[archmint]

• 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]

- Weapon models improved
- Character model improved (I have some ideas)
- Flamer removed (replacement?)
- Rifle's primary fire made more powerful OR the ammunition per round increased
- Improve the viewfinder when you zoom in w/the rifle
- Ability to simplify death messages (eg. from bot [1] was filled with shrapnel by Iridium to You Fragged bot [1])
- Customizable HUD
- Better mod integration
- More teleporters in new maps

[wowie]

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

+1 for this as a menu option. I prefer the current style but to each their own.

[Dratz-_C]

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

[qreeves]

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

I agree, please put it up on the tracker for me (posting from a mobile device).

[Dratz-_C]

I've submitted a ticket on the tracker.
Cheers

[Remilia Scarlet]

Optional server variables that prevent those with spawnprotect from catching the bomb in bomberball...
Possibly another variable for shooting while spawnprotect is in effect...

[Dratz-_C]

Already fixed.
(According to my experiences playing bomberball in 1.2, those who join midgame with the ball in play can hear the ball being passed but cannot see the ball until someone scores or the ball is reset. I think that this should be fixed in 1.3 so players who join midplay can see the ball immediately. I've submitted a ticket on the trac.) However, now I see thanks to pskosinski that it's already fixed so I've changed the ticket to fixed and closed it. That's what I get for not looking through the trac first. Please accept my apology.
Cheers