infiltrator_2k

After just conducting a few experiments I've found if you leave spaces ie: "-mod=@my addon" in the startup parameters the addon fails to load even though you're not prompted with an error. I've tried a number of combinations of enclosing the parameters with quotation marks and get the same results. I've always had the understanding that underscoring spaces is good practice and prevents issues and there we have it.

Cheers it worked :) I should have thought of that earlier as I had to edit the mission file to remove a vehicle that was taken out of an addon update. Of course this was also throwing up an error until I edited the mission file and removed the classname. Thanks for your help ;)

Why can I no longer edit my mission without having to TFR? I've not added any TFR content in the mission and I get this error: You cannot play/edit this mission; it is dependent on downloadable content that has been deleted.task_force_radio items

Has anyone been able to host this addon on a dedicated server with signature verifySignatures=2 ??? RobJ's won't pass verification neither will the sigs/keys I generate. It's driving me up the wall! The PWS version does however pass - albeit an previous version of the addon. I really need to sort this out because I simply will not host without signature verification enabled. I found this old post that might shed some light onto why I'm getting this problem. http://forums.bistudio.com/showthread.php?155107-Wrongly-signed-Mods-on-the-Server-ACRE-CBA

I recently signed a friend's addon using DSsignFile. I created the private key, bikey and signed all the PBO. Even though I have the exact versions on both client and dedicated server the server fails to verify the signatures and kicks the client whilst adding in the logs "Wrong Signature for addon". How can this possibly the case if the PBOs, Bisign and bikeys are identical and created from the same private key? Is this a bug? I used ArmaTools.

I'm totally stumped. I've opened and examined the bikeys in notepad and they're identical :/ *** Update *** I found the problem. It was an Microsoft Office security feature blocking files that I had copied/pasted from the client to the server using the remote desktop. Problem now sorted :)

I'm wondering if it's because the addons have been signed before by the original creator. With the permission of the original addon creator, my friend has simple re-skinned the original content and released a pack or other people's work with their permission. I'm wondering if the PBOs can only be signed once to prevent hackers editing content and resigning it.

I'll be hosting a BAF I&A dedicated server if anyone's interesting using this addon, along with ASR, ACE3 (when released). Blastcore and DragonFyre will be enabled.

Rob please keep supporting this addon for we British Arma players ;) BTW, I was down you neck of the woods last week. It's a very nice and pleasant little place.

DragonFyre is a client side mod meaning we just have to allow the key. Although I've noticed a lot of admins have it listed in the required expansions? Why? Is there a practical reason for this, or is it a mistake because the admins haven't read the installation process? Also if signature verification is set to 2 does this mean only players with the same mods running as the server are permitted to join? Or does this mean the server has to allow the key for the mod to be allowed to be ran on the client's PC, and if it is 'not' present, does this class the addon as unknown? If so, does the signature verification and allowed key process replace the "equalModRequired" that's listed as outdated? I'd appreciate it if someone could clear this up for me so I can control what addons players are permitted to use on my server. Cheers Ian

I've been running TFR, RHS, Alive, CBA and the ACE 3 mod, but I'm struggling to find a decent RHS COOP mission to host. I've tried RHS Insurgency but my initial thoughts are that's it's boring searching buildings. What other decent RHS COOP missions are there?

Given such an integrated kick/ban feature would be local and not global I think it's a negotiable trade-off and might even help catch the real hackers, as people who get kicked/banned unfairly are more likely to complain and get the ban revoked. The logs then provide good information and a little collaborative detective work could help identify the real perpetrators. As for good server administration I concur, although half the battle is having admins online 24/7. I did however pick up some good advice from an old post from Ahoyworld's admins on how to catch the vermin. At the moment I'm using the Arma Ban List, although there still seems to be no shortage of people who are still wanting to add to it.

Should BIS add TK kick/ban options in the configuration menu to automatically kick and/or locally ban players? It wouldn't be too difficult to detect whether or not a set number of consecutive team kills are detected. If a player say kills several team members on 'separate' occasions without an enemy kill it would be a no-brainer their intentions are malicious. Having the ability to have these idiots automatically kicked/banned by the game would be a welcomed feature by many IMO.

Hi Das, so are these the hacks that are currently undetectable by BE? Or are these servers with BE and sig verification disabled that are having these problems? I ask this because such a feature could be tied to the condition of having BE and sig verification enabled. If however this type of hack is getting past BE then it begs the question whether BE is fit for purpose.

Is an integrated kick/ban configurable option just too obvious and simple to implement? It doesn't take the brains of an archbishop to figure out that such a feature would drastically reduce team killing. There would be no scripts or admins having to police their servers, it would be an automatic system that acts given the admin's setting and what the parameters are for that particular setting. BIS would be the ones who decide what's considered a tolerable level. Server admins could be given 3 options: off, moderate or strict. Players would be able to see from the server list what a server's kick/ban setting was on, just like the difficulty level. Therefore they too would be given the option on whether of not it's a server they'd like to play on with a clear understanding that TK may get themselves or other players kicked and/or banned. It's all about giving the consumer the ability to make a choice whilst also cracking down on abuse.

What does it matter if it feels like a donation or not. At the end of the day paying for the DLC will ensure further development whilst also providing a job for the devs so they can support their families. It's a win-win situation. In many respects BIS catered for all, because if people aren't too bothered about Arma they wouldn't have purchased the DLC. It wasn't as if BIS were forcing the purchase upon us. I haven't used the DLC yet, but it felt good to have bought it because I know it will increase both the quality and longevity of the game. I think Arma has a lot going for it and it will only get better and better with future DLC. Not suggesting the OP moaned, but the fact remains that there will always be people who moan about buying DLC because there will always be those who want something for nothing and who don't care for or understand economics. I remember the days of Novalogic's Delta Force series and their half-baked expansions that were just bloody awful! You go into the editor and wouldn't be able complete missions properly because of the missing content. Those of you who remember those days will be the ones who'd rather throw money at BIS than go back to that garbage.

That's why I highlighted "separate". For example: if you crashed a chopper full of team players 2-3 times killing scores of players there would be no kick/ban. But kill 4 players consecutively, but on separate occasions without an enemy kill then there would potentially be a kick/ban.

I'm not talking about quantity, I'm talking about the number of consecutive TK's without an enemy kill. Not really. Those threads are about what admins do to prevent TK, and I think a lot of the onus is on BIS to stamp out this type of behaviour as it's a big problem that's marring public multiplayer play. It's a problem that I think needs to be addressed at the root, that being at the game's current lack of kick/ban options. Also creating a new thread with a more relevant title it has more of a chance of capturing the dev's attention and may inspire them to introduce such a feature.

So if I'm running a milsim server it best for me to allow Blastcore and DragonFyre then? But if it's a public server being configured properly the addons won't show up in the expansions field, meaning players won't know if you've allowed the bikey. I guess the only way around this is to add it to the description. The only addons I use that require both client and server installation is Task Force Radio and ASR Ai. What other addons are a must for a milsim server? Authentic Gameplay Modification perhaps?

It seems practical that equalModRequired may have been superseded by the signature verification on order to allow players to join servers who haven't got to be tied into using the same addons as the server.

I don't think it works like that. Final Draft has created the framework for creating spec scripts, but that doesn't give them the right to own a screenwriter's screenplay. If you read my earlier post you'll realised that I'm impartial.

I've ran a few tests and it seems you can join any server running mods even if you aren't running any. It seems you can at least run client sided mods on a server as long as the server has installed the mod key. In short, I haven't yet found a way of ensuring players run a mod that's also running on the server, but you can at least restrict what mods players run on your server by restricting/limiting what mod keys you allow on your server.

You are correct as you cannot copyright an idea. But could there be an argument that BIS copied a design? The outcome of such court cases are inevitably dependant on the arguments put forward by the lawyers.

You've brushed upon something that's intrigued me for a while now: that being scripts and addons that are later introduced into vanilla. But BIS and its devs won't give credit because that'll be an admission that they've based their ideas and work on other people's creations, and then there's the legal implications as there's an universal agreement that people's work is automatically copyrighted. "Every poet's a thief" but morally it could be argued that sooner or later BIS would have thought of the idea anyway, hence why patents are time limited. How I see it is BIS and its devs have time and budget restraints that prioritise what they develop and such features are planned but not yet released due to this.

This kind opens a debate of what AI can and can't see. For example: does wearing a Ghillie suit make you less obvious to the AI? Can the AI see through any objects/structures etc?