Latest Github Events

[FF_Team]

caesyum commented on issue fortressforever/fortressforever#216 ('Examine possibilities for a 3rd offense class in competitive play'):

As background, I like that the pyro currently has to get up close and personal (i.e. within flame thrower range) to deal large damage and think whatever happens that concept should remain and preferably be extended. I also think that the pyro should be devastating to front-line defense if he can...

View on Github

[FF_Team]

squeek502 closed issue fortressforever/fortressforever#181 ('Add Lua function to get armor absorption of a player')

View on Github

[FF_Team]

squeek502 commented on issue fortressforever/fortressforever#181 ('Add Lua function to get armor absorption of a player'):

Done by #194

View on Github

[FF_Team]

squeek502 merged pull request fortressforever/fortressforever#214 ('Update func_button:ondamage lua callback to use parameters instead of global vars') from squeek502 to beta

View on Github

[FF_Team]

squeek502 merged pull request fortressforever/fortressforever#213 ('Add global callbacks intermission() and restartround()') from squeek502 to beta

View on Github

[FF_Team]

fpsmoto opened issue fortressforever/fortressforever#218 ('SG cannot be damaged by engineer who built it once sabotaged.')

View on Github

[FF_Team]

fpsmoto opened issue fortressforever/fortressforever#219 ('Make sniper deck ladder in ff_aardvark team-only or remove it altogether')

View on Github

[FF_Team]

fpsmoto opened issue fortressforever/fortressforever#220 ('ff_warpath rework')

View on Github

[FF_Team]

squeek502 commented on issue fortressforever/fortressforever#218 ('SG cannot be damaged by engineer who built it once sabotaged.'):

Is this a problem specifically with the engineer? You're saying an engineer cannot damage his own SG if it has been maliciously sabotaged (the sab was activated by the spy)?

Or is this a suggestion to make it so that everyone can damage an SG when it's been passively sabotaged?

View on Github

[FF_Team]

FDA- commented on issue fortressforever/fortressforever#220 ('ff_warpath rework'):

I think the main reason warpath doesn't get played is because it's poopy. I think it's pretty easy with larger player numbers for the map to come into gridlock between midpoint and point 2. I think this is because the points are too far apart, the main path is a very long choke (where it might be...

View on Github

[FF_Team]

AfterShockFF commented on issue fortressforever/fortressforever#220 ('ff_warpath rework'):

I agree that the map becomes gridlocked too easily. I think it would benefit from stronger push/pull mechanics so that capturing a point really gives your team a chance to push forwards. One thing I've noticed is that if you capture a 4th point, it's only locked for 10 seconds which is barely...

View on Github

[FF_Team]

fpsmoto commented on issue fortressforever/fortressforever#218 ('SG cannot be damaged by engineer who built it once sabotaged.'):

It's an issue with the engineer only. Anyone else (including other teammate engineers) are able to damage a Sabotaged SG, just not the engi who built it.

View on Github

[FF_Team]

fpsmoto commented on issue fortressforever/fortressforever#220 ('ff_warpath rework'):

That's a good idea shock, if you get killed near CP3 right after the enemy team caps CP2, it becomes difficult to take back that CP, though I think the lock times for each cap should be the same for that,

It should also be more difficult to capture a CP the more you've captured. I rarely see...

View on Github

[FF_Team]

TrepidJon commented on issue fortressforever/fortressforever-scripts#40 ('Reduce max rockets for soldier (50 -> 30) and demo (50 -> 40)'):

I feel like a "subclass" of each class could be defined here, in a currently simple form O/A v D. A soldier or demo on the attack could use the extra ammo, meanwhile they could rely on resupply while defending, expanding the idea beyond ammo.

Those kinds of tweaks could be done for every class....

View on Github

[FF_Team]

TrepidJon commented on issue fortressforever/fortressforever-scripts#41 ('Tweak railgun charge sounds'):

When I played again recently after a hiatus (what), I thought the railgun sounds needed tweaking.

They sound kinda ridiculous from the thirdperson and also not informative enough from the firstperson.

The charge needs to be more obvious audio-wise beyond a volume change, that was just me...

View on Github

[FF_Team]

AfterShockFF opened issue fortressforever/fortressforever#221 ('Get FF compiling on more recent Visual Studio')

View on Github

[FF_Team]

AfterShockFF opened issue fortressforever/fortressforever#222 ('Fix cl_spawnweapon_spy tranq')

View on Github

[FF_Team]

AfterShockFF commented on issue fortressforever/fortressforever#222 ('Fix cl_spawnweapon_spy tranq'):

Code that breaks is here

CBaseCombatWeapon *pSpawnWeapon = Weapon_OwnsThisType(weaponSpawn);
if(pSpawnWpn && pSpawnWeapon)
{
if(Weapon_Switch(pSpawnWeapon)) // this will be false because you can't switch to a weapon you're already holding, and won't break...

View on Github

[FF_Team]

DexterHaslem commented on issue fortressforever/fortressforever#221 ('Get FF compiling on more recent Visual Studio'):

I've also been wanting to do this, and have tried in the past. another issue was luabind not building. newer version of luabind worked, but needed newer version of boost and I got stuck somewhere else I can't recall

View on Github

[FF_Team]

DexterHaslem commented on issue fortressforever/fortressforever#221 ('Get FF compiling on more recent Visual Studio'):

oh yea, only tier1 can be build from sources (in everything project), so screwed on tier0, 2,3 being built on older versions (lib\public & lib-vc7\public) as far as i know. I'm not super familiar with the ABI changes over the yhears

a licensee could try to rebuild them but trying to build on...

View on Github