PsYkO wrote:The way fortress is set up, it can reach a point where you can not get into a defense [...]
since it is a lot easier to play sumo in the opponents zone, i would prefer always to attack despite the fact that it may seem more difficult than playing def
sooner or later, defense will be down, people can't play it for ever
PsYkO wrote:The way fortress is set up, it can reach a point where you can not get into a defense [...]
since it is a lot easier to play sumo in the opponents zone, i would prefer always to attack despite the fact that it may seem more difficult than playing def
sooner or later, defense will be down, people can't play it for ever
most of the good defender's deaths are just mistakes on their part. what happens when the mistakes get fewer and fewer?
PsYkO wrote:
most of the good defender's deaths are just mistakes on their part
same comes for attackers
PsYkO wrote:what happens when the mistakes get fewer and fewer?
def gets squeezed and both players end up by playing sumo. if both players are at the same level of skill, the attacking one has a little bit more chances to win
PsYkO wrote:
most of the good defender's deaths are just mistakes on their part
same comes for attackers
PsYkO wrote:what happens when the mistakes get fewer and fewer?
def gets squeezed and both players end up by playing sumo. if both players are at the same level of skill, the attacking one has a little bit more chances to win
You gotta admit that the ratio of deaths by mistake is far higher for a defender than an offensive player. I can manage my box pretty well without getting squeezed, some can do it even better.
PsYkO wrote:You gotta admit that the ratio of deaths by mistake is far higher for a defender than an offensive player.
when does not happen you die by a mistake? if you play perfectly, you do not die. fortunately nobody can play perfectly.
also, just look defenders score at the end of a match. usually they get the higher score, that means someones else made some mistakes...
EDIT: again, please explain why you did say the scoring i thought should aim to lower score possible. it wasn't really clear to me.
I didn't read the whole replies. so no wonders, if im repeating anything what was posted be4.
- you should try the idea with the tighter holes. if its not good you can remove it later.
- scoring system is different, but maybe it makes yourself drive more carefully, because its the whole team which would get mad at you, when you die too often
- what about a moving base from left to right? not over the whole length, but a shorter route would be nice. or a base which starts moving, when enemies enter it.
- another idea could be the following: every team will be splitted into two groups (for example: team has 6 player, so there are 2 groups of 3 players). after every match, the playing team changes, the other one is going to spec mode (more fun?).
- what about mixing up capture the flag (ctf) and fortress? you also need teamplay and defending is necessary. you could position the flag in the center of each base. respawn could be handled by driving into your homebase, just like in ctf.
actually cycle_explosion_radius is set to 1. try it out for one week.
psyko: if you would like to explain better your idea, then we could try it for one week and see reactions/advantages.
about fair rubber: im still looking for how to calibrate rubber to answer in a more fair way for every ping.
CYCLE_PING_RUBBER (3 by default) controls the "bonus" of rubber given to higher ping players, but it is not clear what "higher ping players" means. how does it select who is a higher ping player? is there a specific ping since where the bonus starts? or are just choose a # or % or players in a server that have the higher pings?
well, actually, considering fortress, the best ping to play with is around 45-50. i cannot remember if i already posted that, but surely high pings generate bad lags, but very low pings make the rubber impossible to control. it is a question of human reaction time, for this reason both very high and very low pings are bad.
then, how do i calibrate rubber for a more (in possibilities of program commands) fair setting?
what about shrink?
maybe, could z-man or someone else explain us better how these commands work?
meantime, from settings.cfg:
CYCLE_RUBBER_WALL_SHRINK: With finite length trails, the used rubber is multiplied with this value and subtracted from the wall length. A value of 1 lets the trail receed at constant speed. All values are supported, but negative values may degrade performance and cause false positives from the topology police if that is enabled.
CYCLE_DIST_WALL_SHRINK: Distance multiplier in wall length calculation. All values are legal.
CYCLE_DIST_WALL_SHRINK_OFFSET: Distance offset in wall length calculation.
all set to 3 by default.
what about CYCLE_WIDTH? could we give it another try?
what about CYCLE_RUBBER_MINDISTANCE? (The minimal distance rubber code keeps cycles from walls). could anyone explain the use better?
thx and kisses
EDIT: i set CYCLE_ACCEL 25 and CYCLE_SPEED 25 under newbie suggestion. speed is more dynamic, i found it very interesting. try it out.
Rain wrote:CYCLE_RUBBER_WALL_SHRINK: With finite length trails, the used rubber is multiplied with this value and subtracted from the wall length. A value of 1 lets the trail receed at constant speed. All values are supported, but negative values may degrade performance and cause false positives from the topology police if that is enabled.
I didn't think the engine could cope with negative values. Normally walls are kept behind you in their entirety until there's no longer any bit of 'visible' wall in them, at which point they're quickly deleted (something you'll learn when coding a map). I suspect shrink works by decreasing the 'visible' bit, but a negative value might increase it into the void, which obviously shouldn't happen.
CYCLE_WIDTH kills you if you enter a tunnel no wider than that, based on acceleration sensor readings (these point diagonally backwards).
Mindistance: try gCycleMovement.cpp if the descriptions are not good enough.
That's why negative wall shrink causes performance problems Usually, if a piece of wall is gone, it stays gone, so it can be removed. With negative wall shrink, it can reappear and thus needs to be kept longer, and lots of invisible walls that can intersect and can't be deleted yet are a bit of a problem.
For the rest, please ask specific questions; the descriptions in the config files are the best short descriptions I can manage (note that there are some blocks of text before blocks of config options telling how they work together).
effectiveness *= ( max + player->ping * sg_rubberCyclePing )/max;
Where ping is in seconds, max is CYCLE_RUBBER, and the effectiveness can be thought of as a factor to CYCLE_RUBBER to get the effective rubber.
That formula can be somewhat simplified:
For negative rubber values, your ping*CYCLE_PING_RUBBER is added to the rubber. But that's probably not what you want.
An example: at default settings, a player with 50ms of ping gets 5 + 0.05 * 3 = 5.15 rubber, and a player with 300ms of ping gets 5 + 0.3 * 3 = 5.9 rubber.
Btw, the effective rubber can be thought of the distance a cycle would drive if it wasn't facing a wall before it explodes.
"I've read on http://armablogtron.wordpress.com/ that wrtlprnft thinks to shut down one of FTS or 4TF. indeed i agree with him that it is becoming laggy. since i dont want any problem with both wrtl and durka, is anyone interested to host Fortress Test Server? i don't mind to have any power on it, just to have it online. i think it is an important server for fortress evolution. so, last thing i want is to create troubles to wrtl. would be great to have some help from the community. otherwise, if nobody is really interested to FTS but me, well, better to shut it down then, instead of somewhat else, maybe more interesting for the community. thanks."
well, the meaning is not to fix the server like it is at the moment, but to continue to try new things in there. indeed it is a test server. those test could surely help, as they already did, to suggest to café (the actual fortress standard) new settings, but they will be just tests. nobody wants to damage fortress style, just trying new solutions, have some dreams and test them. who knows, maybe we will create another way to play fortress, a better one, a worse one, doesn't matter. but since no server is perfect, we would need one dynamic, IMHO.
Usually, if a piece of wall is gone, it stays gone, so it can be removed. With negative wall shrink, it can reappear and thus needs to be kept longer, and lots of invisible walls that can intersect and can't be deleted yet are a bit of a problem.
