Radioman

Hello, I cannot for the life of me work out how to create an account for the biki. On the front page, it says "Sign up today", which links to this: http://community.bistudio.com/wiki/Special:UserLogin It isn't a register form, nor does it accept my forums login information, or my dev-heaven login info. I imagine it's tied to the community accounts, but, which? Entering information doesn't seem to make it create an account in any way :S Thanks.

Hello everyone, I have begun work on an Arma 2 Warfare BE clone for Arma 3. I've started from scratch with the intent of making a far more optimised CTI for Arma 3 which plays just like it did back in Arma 2. I write to you now asking for expressions of interest in such a mission, as I have noticed that previous and even current Arma 3 CTI projects are left unplayed and eventually abandoned (WASP and Gossamer's to name a few) Would you be interested in an Arma 3 Warfare, akin to Arma 2's Warfare BE? You can track my progress on my Github here: https://github.com/MarkusNemesis/A3Warfare/tree/master/A3Warfare.stratis Please leave me a comment and show your support. Cheers, Radioman

Hello, This is not possible. From a modelling standpoint the UV Mapping is all different, causing different aspect ratios. Textures do not tile, they are simply projected onto the model as is.

Hello, I used to help out the OFPS folks when they were starting to modify their BECTI and got them migrated to Github. The Warfare I refer to is based on Warfare from Vanilla A2. Benny made a modification of it and that is what I aim to base my CTI on as it played well. BECTI and any modification thereof is very different to how Arma 2's Warfare BE played.

Just keeping the dream alive. :)

Then yes, it should be :)

I appreciate your reply. I ask because Warfare is a VERY big mission, and needs good numbers to be a fun experience for those playing. My friend base is around 5 odd people at best, and this mission would require 16-32. Not to mention the sheer volume of code required. If it's all for nothing, I will not be a happy person.

Hello, I've not played OFP, so I would not know. MY foundation for this project is how Warfare BE worked in Arma 2, which was based off BIS' Warfare also in Arma 2.

You could use a combination of the following: Make them aim at the target: https://community.bistudio.com/wiki/doTarget https://community.bistudio.com/wiki/doWatch Make them fire: https://community.bistudio.com/wiki/doFire The issue with doArtilleryFire is that it is hardcoded for them to reset their target and drop their barrel. You'll just have to make your own similar system to circumvent this.

You missed the issue where players can buy as many AI as they like, regardless of unit count limitation. This is due to you only ever checking ONCE that the user has enough room in their group, and that's before the creation process even begins. It also does not check if you have a number of units pending creation either. So I could have 1 unit (myself), I can then select the 'buy' button 250 times within 4 seconds, and then I would be awarded all 250 units. What I also fail to understand is why you need to send a request to the server to create the unit, when all the server does is send the request back again for the player to complete, with little to no necessary data validation. This leaves this issue with a very costly solution of either rewriting the entire unit purchasing process, OR scanning through the entire array of units pending creation to find all those that belong to that one player, count them up, and then revalidate. If it fails to validate, then you'd need to have the server pay the player back for the unit (as the cost of the unit was already withdrawn by the client) which would affect performance due to unnecessary repetition. Just a heads up.

Okay, well, in that case, here's my list of bugs that need to be resolved. UI - Factory: Buying units needs to be default to nearest base building - Gear: Can buy weapons/items multiple times but only get one, but charged for each time you 'added' the item - Gear: Selling helmets does not actually remove the item but gives you money. Disable "sell back" of items. - Factory: You can buy infinite vehicles if you click fast enough - Upgrades: menu has no countdown - Upgrades: menu needs tooltip "Doubleclick to run upgrade" as it is not apparent enough to new users Commander Build mode - Buildings can be built anywhere. e.g. All inside one another. AI - Town AI vehicles do not engage due to aim shake. - Infantry lethality needs to be increased (lesser idiocy) Map - Despawned vehicles don't delete their marker - Towns don't have supply value on their name General - Empty vehicles despawn too soon. - Player payouts appear to occur multiple times a cycle - Starting vehicles - Ambo + Truck - Remove random debug 'hints' - Towns MG Nests don't despawn when a town is capped. There's also a lot of code optimisation that should be done also. ie, you use 'spawn' and 'scriptdone' an awful lot, when you should just use 'call'. You also have a lot of repetition in functions and generally poor readability of code. Your mainloop for the client and server shouldn't use a for loop, it should use a waituntil {[script here]; false } loop, so that it runs once per frame. You could also then break out the other functions to only run every 2 frames, or 4 frames, or 8, etc. etc. Breaking up the overall load. Your scripts are also not clearly scoped. ie, you've functions EVERYWHERE, that both client and server can access. You should have them clearly separated into client, server and common scopes. Storing player funds as a global variable, one that can be modified by the client and taken by the server as 'fact' is also poor design. You need to have proper data validation. A lot of your UI function calls are spawned, with by value variable passing, so thus exploits are easily achieved. You need to change these spawns into calls, and these calls should reference variables by reference. A good way to resolve this issue is by using the mainloops to have an 'event register', which is an array that contains a list of events, their respective variables (if any, due to byref) and their function, along with a 'time of execution' for when the function event is to be called. ie, I buy a unit at time = 1200;, and that unit takes 4 seconds to build. You'd have the 'buy' event registered in the register, and it'd then be 'called' when time == 1204; that way, if I buy 10 units, and can only afford 4, it would stop at the 4th unit as I couldn't afford the remaining 6, due to byref variable passing. Now do you see why I'd like an un-obfuscated version? There's much to be done.

Any chance you could release a version without the scripts being all garbled? I'd like to fix this mission up and make it playable, but unfortunately I'm having to spend half my time reformatting all the code. If you can't, it's no big deal, I'll just reformat it all and use that. Just not very nice to the community to obfuscate your code the way you have.

Additionally, when I run the server, the RPT file's last entry is Error 5 reading file '' The startup line for the server is simply -server -port=2302 ^ Which works 100% fine on Windows. I can remote to it, I can connect to it, etc. However, on the Linux box, it just shows no results. ^ Disregard, the server is now showing after rebooting the VM and starting the A3 server again. However, gameplay is very broken in that it crashes a lot. No sound specific issues (though xaudio was one of the top-most modules in a crash report) - I'll post crash reports here as I get them. I didn't get the first two because the 100% CPU use it left the server on, made it impossible to grab over VNC. uname -a Linux Arma3Testbed 3.2.0-23-virtual #36-Ubuntu SMP Tue Apr 10 22:29:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux /lib/modules/`uname -r`/kernel/sound arma@Arma3Testbed:/lib/modules/3.2.0-23-virtual/kernel/sound$ ls -al total 40 drwxr-xr-x 5 root root 4096 Apr 25 2012 . drwxr-xr-x 9 root root 4096 Apr 25 2012 .. drwxr-xr-x 4 root root 4096 Apr 25 2012 core drwxr-xr-x 3 root root 4096 Apr 25 2012 drivers drwxr-xr-x 2 root root 4096 Apr 25 2012 pci -rw-r--r-- 1 root root 19744 Apr 11 2012 soundcore.ko find /lib/modules/`uname -r`/kernel/sound -type f -name snd-dummy\* No output zcat /proc/config.gz | grep SND_DUMMY gzip: /proc/config.gz: No such file or directory

root@Arma3Testbed:~# iptables -L -v Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination As for the ALSA errors, I'm not getting any visible ALSA errors, but I assumed that it could be contributing to my current issues. As for the dummy sound object, I am (I believe) running a custom kernel, because my VPS provider uses their own build of the Ubuntu 12.04 kernel. I'm using 'Digital Ocean' and they're freaking amazing. Cheers.

Okay, so I have Steam installed, Arma 3 installed, and I can run the arma3server.exe. My only issue is that I cannot connect to the server.... The server is Ubuntu 12.04 LTS Server, and I've disabled all the IPTables to forward all (for good measure). I try to remote to the server via Arma, and the server list shows empty. I've disabled my MP filters in Arma, and still cannot see it. Both my client and the server are running versions 0.77 of Arma 3. Ideas? P.S - I cannot, for the life of me, "sudo modprobe snd-dummy" I get "FATAL: Module snd_dummy not found." in return.

I don't think you know what he's on about. In arma, the rudder has a mind of it's own. Sure you can bind keys to it and use it, but if you do a turn, then take all hands off the controls, the rudder will just flap about, trying to point you forwards again. It's annoying as hell and cannot be disabled.

Just having an in game scripting IDE would cut down development time like no other. No more "do work, save, start the game, instantly get a syntax error, try again". Just having the option to check syntax would be great.

They likely planned to do this, but because of the attachment system etc, decided against it. Probably another cut corner due to time constraints.

http://community.bistudio.com/wiki/forceWeaponFire

I cannot see why it has come back.... It's uses were for MP, I thought. What case would having this for SP be required? Vs just running code right after object creation?

I handle such things by not making them dynamic, and actually having a flag based system instead, that uses an array, and a 2-3 letter 'flag', for the switch statement, and maybe even nested flags there after. A good (and my only real available) example of this can be seen here: https://github.com/MarkusNemesis/Arma3LifeFramework/blob/inDev/A3LifeFramework.Stratis/client/functions/interactions/clientInteractionItemUseEvents.sqf As for security of your current proposal, there's so many holes in it, it's swiss cheese. First one especially, but the second one isn't too bad, but could become subjected to code injection, ie _unitId could = "unitID; 0 spawn {malicious code here};", and your system would run it without any questions, as it'd work fine.

Problem is Kju, is that BIS uses this function to all high-hell, all through their library.... and, as it stands, it's the only way for an addon to do stuff over the network, to not-addon using clients. Though, mind you, I'm not a big supporter for this whole non-consensual add-on message code slinging.

It could stay in, if BIS perhaps implemented some kind of blacklist for BIS_fnc_MP, and also enable a field in server.cfg, or description.ext, to add specific blacklisted functions for BIS_fnc_MP. Have it IN ENGINE, and not just a BE tack-on. People can waffle on as much as they like about how 'good' BE is, but it's got a marred history of being just plain bad... Not FUD... Fact....

To be honest, I like the idea of breaking pre-A3 content, due to the fact that I, and many others, are fed up with the typical copy-paste content that has been floating about for years and run like turd....

This is because it's an MP mission, not an SP mission. Run it from a dedicated server and try.