Archive for October, 2011
So far, I’m loving Battlefield 3 – it’s great fun, and, I feel, an improvement on Battlefield Bad Company 2.
It’s not without its problems; though – here are my thoughts on what I’d like to see fixed:
Flares should be available by default
Flying is very difficult indeed, due to the fact that flares are an unlockable item, requiring you to score sufficient points in that type of aircraft to get them. So, you’ll take off in a jet armed only with its cannon, and no flares to shake off heat-seeking missiles; as soon as you’re airborne, people will be firing missiles at you, and, with no flares to throw them off, you’ll struggle to shake them, and will likely be shot down quickly, or spend your time in a series of desperate manoeuvres trying to shake off the missiles; you’ll not stay alive long enough to chalk up enough kills with the puny machine gun/cannon to score enough points to earn the flares
This means that players who have already unlocked the flares and missiles have a massive advantage over those players who haven’t yet, making it very hard for those who haven’t yet unlocked them to take part in jet/helicopter flying.
I’d like to see flares changed to standard equipment rather than an unlockable, so that you can at least have a chance of defending yourself while you try to get enough kills to unlock heat-seeking missiles yourself (something which, I believe, you’ll need to repeat for each individual type of plane in the game…).
Splitting parties on joining a game
Match-making can be a little shabby at times, too – invite friends to your squad, join a game, and you’ll quite often find you’ve been split up across different squads, and, often, even on opposing teams (even if there were only two of you) – a big failing for a game where teamwork and co-operation is important, in my opinion.
I think the match-making code needs to be able to look for servers with sufficient space to take all members of the party in a single squad on the same team without the game becoming unbalanced, and ignore that server if it’s not suitable.
(Note that I play on PS3; I do not know if the above points are valid for XBox / PC players)
EDIT: going by the number of people reaching this post with search queries like “battlefield 3 party join not working”, “battlefield 3 party problems”, “can’t join party battlefield 3”, it seems I’m not the only one annoyed by this.
EDIT 2: Looks like this is being worked on – EA blogged:
2) JOINING SQUADS AND STAYING THERE
Status: Fix pending in the very near future
Some people have experienced difficulties joining and staying in squads on console. We have identified the cause of this problem and will hopefully have a fix ready to roll out very soon. […] We will return tomorrow with an update on when this fix is live.
They also suggest following their guide to using the BF3 server browser. It’s not entirely clear, but it sounds like the filter settings chosen in the server browser apply also to the “Quick Match” feature, too.
M98B seems excessively powerful
The M98B seems to be excessively powerful compared to other sniper rifles in the game (although it may just be that I’ve just been unlucky and just seen it in the hands of very skilled players who managed a headshot every time – although I’ve been taken out with it in Canals was set up as an industrial harbor, featuring a mix of infantry, land vehicle, and boat gameplay. The attackers in Rush start out on an carrier ship and can reach the beachhead by amphibious vehicles, boats, and helicopters. All of the bases on the map hava single hit even whilst running a few times…)
You can’t quit after a round
When a match is complete, you see your stats, but there’s no option to quit – you have to wait for the timeout, then for the next map to load, and finally, when you reach the spawn selection screen, you can then quit. The most logical time to decide to quit is at the end of a round, so why not provide a quit option there? That would save a lot of wasted time, save the effort of loading the next map for no reason, and perhaps even give the server a better chance of making sure the teams are balanced, etc (it can have a clue who is planning to stay in the game, rather than doing balancing etc, only to see people drop out afterwards). Pure logic and usability would suggest allowing you to select to quit as soon as the stats from the completed round are displayed, I feel.
Just got a random spammy text message from +447873517718 reading:
Records passed to us show you are entitled to £3750 for your accident for details reply CLAIM
Googling for the number shows nothing of use, so thought I’d whack a quick post up for the benefit of anyone else Googling. Now, I wonder if I can report it, and whether it’ll make any difference?
Apparently, you can forward spam text messages to 7726, for Orange, O2, T-Mobile and Three customers, or 87726 for Vodafone (who I’m with), according to a few sites, but I can’t see that being too useful; for one, forwarded text messages, by default, do not include the originating number.
IRC (Internet Relay Chat) is a protocol for multi-server text chat between many participants in many channels, started back in 1988.
There are plenty of IRC networks out there for social chatter, including the likes of Freenode and irc.perl.org hosting many channels for Perl and open source channels in general, making it easy to get quick help from developers and users of your favourite project.
However, I find IRC to be a very valuable tool indeed to help development teams collaborate effectively; at work we make extensive use of it. It’s useful whether you’re a formal development team in a corporate environment, or an open source project whose developers / collaborators gather on IRC.
Why is it so useful? Well:
It enables quick discussion and collaboration without breaking your workflow
As a developer, you don’t want to lose your concentration – when you’re “in the zone”, you’re carrying information about the code you’re working on in your brain, and it doesn’t stay there for long if you’re distracted. Someone walking over to you and starting talking to you, or a phone call, demand more or less 100% attention; you will be distracted, and you will “fall out of the zone”, causing your productivity to fall until you get back to where you were.
IRC, on the other hand, means you don’t have to respond quite so immediately, and I find it easy to flick between coding and IRC (both terminals within Terminator for me) without losing focus on where I’m up to and what I’m doing.
Most IRC clients support alerting you when your nick is mentioned in a channel or you receive a direct message, so you can ignore general chatter in the channel until you’re ready to read it, but know if someone is trying to get your attention.
Of course, it’s even more valuable when your development team work from multiple locations, whether that’s having employees working from home, or multiple offices.
Logs of discussions can be valuable for future reference
If you keep logs of your discussions, it’s easy to refer back to later – sometimes you’ll remember “ah, yes, we talked about this – what was the outcome?” – quick log search, and your answer is there. “Why did we decide that this was the best way to implement this?” – log search – “ah, that was why”.
Open, widely-supported protocol
IRC is an open, widely supported protocol; there’s various clients available for pretty much every platform, so whatever system your devs work on, they’ll be able to find a client that suits them.
Easily extensible to integrate with other tools
It’s easy to write IRC “bots” which can help integrate with various other tools in various ways.
A good example is providing easy links to commits / bug reports or issues / pull requests etc.
If you’re using my Bot::BasicBot::Pluggable::Module::GitHub for instance, you can mention an issue and have the bot automatically provide a summary and an URL for anyone who wants to see what the issue in question is – e.g.:
<user1> Anyone had a moment to look at Issue 42 and see what's going on? <bot> Issue 42 (It doesn't work) https://github.com/.... <user2> Oh yeah - I fixed that in 5fcbb01 <bot> Commit 5fcbb01 (Retarded logic fail.) - https://github.com/....
It’s easy to cobble together a simple bot or bot module to do this kind of stuff for whatever your in-house situation requires, if there’s nothing suitable already out there on CPAN (which, a lot of the time, there already will be).
GitHub provide post-receive hooks which can be configured to announce pushes to your IRC channel(s). Bot::BasicBot::Pluggable::GitHub::Announce can automatically announce new/updated issues, and, in future releases, also pull requests and commits/pushes.
System problems reported instantly
Use something like my Bot::BasicBot::Pluggable::Module::Nagios, and you can have system problems reported automatically to the appropriate IRC channels, for quick attention by whoever needs to deal with them. I use an applet in my GNOME system tray which alerts me to problems, but seeing them reported in detail on IRC is handy, and also strikes up conversation about it – a simple “I’m on it ^^” is enough to let others know you’re dealing with the issue and they don’t need to worry about it.
Announce tweets about your company/brand/project/interests
My Bot::BasicBot::Pluggable::Module::TwitterWatch module allows you to have the bot watch for and report new posts on Twitter about your company/project/brand/stuff of interest, and post them to your IRC channel – either for awareness, or to strike up discussion about them.
Wrap various other tools
Your IRC bot(s) can provide various other useful facilities – for instance, find the corelist command useful? Bot::BasicBot::Pluggable::Module::CoreList makes it easy for your bot to answer corelist lookups within the flow of a conversation.
<user1> Could use File::Spec - that's part of core, isn't it? <user2> bot: corelist File::Spec <bot> File::Spec was first released with perl 5.00503 (released on 1999-03-28) <user2> Yep :)
I’ve just released Bot::BasicBot::Pluggable::Module::Nagios – a module for IRC bots powered by Bot::BasicBot::Pluggable which monitors one or more Nagios instances and reports problems to IRC channels.
I’ll be using this at work to have service problems reported to us on IRC for quick attention, but figured it’s something that’s likely to be of use to others elsewhere, too, so I’m releasing it.
There’s still some more features and improvements I want to make (a TODO list is included in the module POD), but it’s at a state where I consider it to be usable (it works for me).
It should be on a CPAN mirror near you soon, and the repo is on GitHub should you wish to submit pull requests or raise issues for bug reports/feature requests.
The following modules are included – see the documentation for each for more details on how to use them.
Provides quick URLs to view issues/pull requests etc when someone mentions one – for example:
<user> Go have a look at Issue 42 <bot1> Issue 42 (It doesn't work) https://github.com/.... <user> I fixed that in 5fcbb01 <bot1> Commit 5fcbb01 (Retarded logic fail.) - https://github.com/....
You can set a default project per-channel, so the above examples will look at whatever project is set as default for the channel the message was in.
You can also explicitly tell it to look at any other GitHub project:
<user> 5fcbb01 @ bigpresh/Bot-BasicBot-Pluggable-Module-GitHub <bot1> Commit 5fcbb01 (Retarded logic fail.) - https://github.com/...
Monitor pull requests for GitHub projects.
<@bigpresh> !pr < sophie> Open pull requests for sukria/Dancer : 8 pull requests open (felixdo:3, perlpilot:1, jamhed:1, dams:1, ambs:1, JTimothyKing:1)
Announces issues raised/closed for each channel’s default project.
Periodically checks on issues for each project, and reports changes,
< sophie> Issues closed : 667 (YAML::XS for Session::YAML) by jamhed : https://github.com/sukria/Dancer/issues/667
The code is on CPAN, and is available on GitHub. Contributions / bug reports / suggestions encouraged.