Proton

It looks to be the same what I extracted from ACRE RC4, so the bug above remains: it does not work with the 1.07 dedicated server .exe, at least in my case it crashes arma2server.exe with pipes. "arma2.exe -server" is fine. You probably have a bad patch address somewhere with the dedi exe. Thank you for the lib anyway, it is extremely useful! :bounce3:

Unfortunately it crashes the dedicated server of 1.07 (arma2server.exe) when using pipes. The non-dedicated arma2.exe runs fine with the -server option.

Thanks, found it.

Any chance for a fast 1.07 support?

Clean Win7 64-bit, i7 920, 6GB RAM, NVidia GTX 295 with 191.07, Creative X-Fi with latest drivers. 1920x1200, all on "very high" except for AA and terrain detail. Beta 59924: I have sound/graphics stutter which was not there in build 59842. Audio or graphics freezes for a fraction of second in a series, resulting in <5 FPS. Most prominent when exiting/entering vehicles. The freezes in graphics and audio seem to be unrelated, sometimes I have sound, but no graphics, sometimes the opposite, but it is so fast that hard to tell. Sound is choppy during game. dpclat.exe shows perfect green bars during the game. Lower view distance lowers the frequency of the stutter, but it is still there. The good news is that with all earlier versions the game was CTD'ing with memory errors in Win7. Now it did not, perhaps the large VRAM fix solved these. I have new messages in the .rpt: Error: post effect with priority 1550 already exist. class HitPoints::Hitglass not found in Land_HouseV_1I1_dam Error: Hitpoint Hitglass not found in the model ca\structures\house\housev\housev_1i1_dam.p3d (original model ca\structures\house\housev\housev_1i1.p3d) Another problem is the flashing flicker when changing from map to game. The background of the "Receiving..." screen is rapidly changing between white and black. It was there in the earlier patches on XP, but was solved somewhere around 1.03. On Win7 it is back, sometimes the flash is between grey and black. Extremely unpleasant to the eyes.

As I just bought the retail version of Windows 7 Pro, I decided to give it a try. Using the 64-bit version, i7 920, gigabyte EX58, NVidia GTX 295, 6GB RAM, ArmA is 1.04. Used Very High settings on everything, except for AA being normal and Terrain Detail varying between Normal and VH depending on the view distance. In about 2 hours of play I had run into a series of CTDs, namely, Bug #3657 and Bug #2440. Tried all suggested fixes in other threads, like -winxp, HT off, but no change. The game runs fine on the same hardware with XP64 and without CTDs since 1.02. My conclusion is that with similar hardware you have to still avoid Windows 7. Probably individual experience varies with components. Quite annoying as I cannot upgrade because of this. FPS was about the same, 15-30 on average. I believe Windows 7 handled swapping the huge textures better. On XP it is quite common that loading the textures takes a lot of time, and you can see buildings "popping up" as the game loads all textures. In Win7 it was more fluent and I never saw such artifacts. What I know about D3D9Ex in Win7, probably the textures were swapped into the extra RAM I have and thats why the entire texturing experience felt smoother. So Win7 has the potential to become better than XP, but BIS still has to fix all the bugs first. They all seem to be related to memory management.

Alexrey: You have plenty of ways to stay close to the battle. First, you can use fasttravel to get closer to the action. The advantage of this that you can take AI units with you. I am currently implementing changes the fasttravel system to enable it for AI without your presence, so if people want rapid action, they can pump up the FT speed and move troops to the frontline pretty fast. Second, you still can use the camps around the town to respawn, but if you die closer than 100m to them or there are too much enemies around it, you cannot respawn there anymore. This is to avoid what could be seen in Arma1 warfare a lot, namely, that a lone Rambo wipes out an entire town by spawning on the same camp a hundred times, or people kill their attacker by respawning until it tries to cap the same camp. Take more camps around a town for a safer respawn. Third, as Luke mentioned, you can also buy a mobile respawn and use that. Hide it somewhere close to the battle. Fourth, you may ask your commander to place a building close to the frontline. You can respawn at any building. However, it can be risky, as you need the MHQ close to enemy lines for doing that.

Forget about the keys if you are not using server signature checks. It should work if you simply copy the .pbo to the MPMissions folder in the arma2 root directory. Just as Luke told you may have something mixed up in the config file of the server.

Taggart517: I do not understand. You have a slider on the dialog. ---------- Post added at 11:06 AM ---------- Previous post was at 10:19 AM ---------- Spamurai: Reproduced. For some reason sometimes it works as normal. Perhaps this is what Luke is referring to, but a respawn from the menu fixes it, so I am not sure why he said they "end" in the water. Looking into what is causing it, it was not there earlier. I could not reproduce this. Tried going into commander, giving back to AI, disconnect, reconnect, going into commander, disconnect as commander, reconnect and being commander again without a vote. Construction menu was properly shown all the time. I could not reproduce it again. I never had a crash because of the command bar yet. Actually, since the 1.02 update I never had a crash at all. What command had you given? It is even harder to reproduce, but I can imagine these ugly stuff may happen when somebody crashes. The engine should maintain consistency in these cases across the network, but obviously it does not. It looks like the player's group list can start holding corrupt entries if the player's group had another player, probably the internal pointers go wrong and they are not checked or removed properly. I cannot really do anything about it from scripts, the best is what the reorder button does: it goes through all units in the group and re-adds them to the same group, letting the engine do a second check about the consistency of the units (that part of the code may be less buggy). But I doubt that I can remove units from a group which became corrupt at the engine level. I recommend not to use BIS's join option now, let people stay in different group. Or take the risks if somebody crashes ;)

As players can do air I think air support is best when it is left to them. I do understand now that there is a huge demand for a scaled-down version, so I will definitely try to add something like in Oden's version. Luke: I could not reproduce, everything I see from here is normal. Players are moved temporarily by the BIS scripts while doing respawn, probably a script gets stuck there, and I have seen this even in ArmA1. I will check your server as soon I have some spare time. Until then: Is it reproducible 100% the times? What were you exactly doing before that? What about "error in expression" lines in the .rpt files?

greenpsycho: I checked what he did, and you are right: he is using a different function for setting the date. Actually, one of the comments of skipTime in the BIS wiki exactly refers to this: Well, thats the advantage of being in the ArmA business for a long time (Oden), and not for a month (like me... ;) ) You just learn these tricks. Expect some thunderstorms in the next release. ---------- Post added at 09:04 PM ---------- Previous post was at 09:02 PM ---------- alexrey: did you download the latest version? The link is in the starting post. The previous version (1.2) did stuck if you were using a non-dedicated server.

Well, I could argue that real war is "an RTS that is ran by 1st person with realistically behaving units" ;) Thats why I said that it is more like a philosophical question. Obviously no simulator will ever be like real, and making it more real would involve putting in lots of boring elements, like toilets and endless guard shifts. Reality is simply another factor of overall enjoyment of the game, and each player community decides about what level of reality is fun. But in the end it goes down to practical issues, like should we use heli lifting which is impossible IRL or not. I think the important separating line is that the game should try not to produce situations which cannot arise IRL at all, although some small imagination may be necessary on the part of the player. Flying tanks below choppers are definitely like dragons - they just simply do not exist.

If you do not touch that part of the dialog, it should do nothing. I completely agree - it is quite ridiculous to see UHs lifting 58 ton tanks. Still, it added a lot of fun to the game, especially because the MHQ could have been transported into the enemy's back. I also agree that a kind of "realism" can be the selling point in this mod, so I do not consider lifting as a very important addition. Maybe we can find something better alternative to do a more realistic drop of vehicles, like using many repair trucks/transport choppers together will enable one to make a building at a spot. This also highlights the more philosophical question of what are the non-realistic features at the moment. Perhaps the best real-life equivalent of warfare is a small-scale, high intensity conflict where areas has to be taken and held. The most unrealistic point is money, but we can see it as an abstraction to distribute available reinforcements. Considering in this role it works quite well, except for the fact that reinforcements usually granted when a side is weak and not when it is strong, because in conflicts of this size tanks are rarely harvested from the field just taken. However, command will evaluate the progress of an operation and consider abandon it if is not progressing as expected, so it is fine to restrict reinforcements in the end if grounds are not taken. To simulate the more probably reinforcing of a looser, a kind of "boost" can be implemented for the weaker side, for example by increasing the buying power of its money. It could also balance the game if the teams are not equivalent. Supply trucks practically measure that how well founded the team's claim to an area, so they are reasonable. It also helps by adding an option to attack the enemy's supply. Perhaps the technical problem of base building distance can be solved by measuring the travel distance, and if it is not long enough then less money is given. However, it would complicate the planning of routes. Factories are also quite unrealistic but they can be seen as reinforcement drop-off points. In theory, all reinforcements should come from the edge of the map but factories and FT are useful to pump up the game's pace. They are acceptable until they do not mean magically appearing units when enemies around. FT is restricted by the enemy activity, so it is fine. Factories are not, and it is quite possible that somebody buys and entire squad of M1A2s at a stray heavy factory in the back of the enemy. What can be added is that the teams has to maintain a supply truck link between factories and the HQ in order to be able to buy stuff at that factory. In a sense the fact that the MHQ has to be moved to the building site is already implementing this as the MHQ is quite fragile, but maintaining a safe route and doing a high-risk move once is not exactly the same, and securing it needs a different military approach. What else? Fire teams should be possible to move especially if arty radar is added. I have an idea how to do this. Please add to the list if you like.

Here comes a new version - mostly bugs, but added an options dialog as well with some new functions. I hope the arty is more robust now and is less prone to stuck, so probably it is easier on server resources, please test it. I have also slightly improved the base building of the AI commander, so it should be more useful now. 1.3 CHANGES: + Increased overall AI skill to the highest. + Added an option to the communication menu to unflip selected vehicles. + Added an options dialog where it is possible to 1. set the view distance and terrain grid, 2. transfer money in a more convenient way, 3. compact and sort group member icons and 4. set the default vehicle lock/unlock. + Fixed bugs in the buy units menu hack. + Fixed: added arty server script timeouts to handle non responding clients. + Fixed: destroyed AI teams are now re-added to high command properly. + Fixed: AI groups defending base will now leave their static defenses if base is moved away. + Fixed: AI commander now moves its building location with the HQ, so it is possible to relocate the MHQ and give the command to the AI again. + Fixed: AI commander will not build in water anymore. + Fixed: Improved vehicle placement around factories. + Fixed: Mission works again on a shared client/server. ---------- Post added at 04:53 AM ---------- Previous post was at 04:33 AM ---------- About future additions: I looked into the weather and it looks like being incompatible with the fasttime setting. It is kinda works, but in my experience the clouds of the overcast are stuttering and are changing shape without transitions, which is really annoying and unrealistic. So it looks like we have to choose between night/day cycles and weather; I think the first is more important and BIS implemented that much better, so I leave it as it is now. Fog can be added but it is quite lame. A couple of basic things are still missing: an arty radar would be useful, helicopters should be able to lift vehicles and adding music would enhance the gameplay a lot. But I think the major targets are bugs and improving performance now. I will have less time in the coming weeks so if the game is actually playable, I am going to slow down. In the recent weeks two other major mods of warfare have been released: http://forums.bistudio.com/showthread.php?t=81301&highlight=oden+warfare http://forums.bistudio.com/showthread.php?t=82201&highlight=benny+warfare I encourage you to check them out - just tell me what you liked or disliked in mine in comparison. Would be nice if the developers could work on a unified project together... we are now pretty much inventing the same (sometimes squared) wheel separately.

First I thought that this was persistent, but I could not re-create it, and the base menu is properly back when you move into distance. So I believe you are referring to the normal behaviour, which is not a bug, rather a feature. Base deployment is deliberately forbidden closer than 500m to any town depots (see changelog). This is because otherwise the commander could deploy the base (or a service point) very close to a town depot, and generate money by doing extremely short supply runs, or maxing out the town supply value in a few minutes. If you do not like this, you can change this value in Change_Common.sqf in the line BIS_WF_Constants SetVariable ["MINBASEFROMTOWNRANGE",500];

Ok, I have it - you are running it as a standalone mission by hosting. Now it looks like to work properly on dedicated server only. Fix in progress.

I will try reproduce them, especially No. 1. The changes of the buy menu is because of the removal of the addon - I had to circumvent that with an ugly hack. I already fixed some bugs related to it, but it looks like from your description that it is more serious. That parachute bug is really weird and I have no idea what is going on there... Maybe some network async (I guess the chutes were generated for him but he got disconnected from the chute in the game engine.) I will definitely visit your place soon, as I should actually *play* the mission more to see where it is the worst. Your reports are extremely useful and keep me busy, thanks for it! ---------- Post added at 04:52 AM ---------- Previous post was at 04:50 AM ---------- Hm, thats another strange one. Are you using addons? Can you please check the arma2.rpt or the arma2server.rpt and report bugs towards the end of it?

It would be also interesting to check that what happens if two teams (belonging to different players) start firing on one side simultaneously. I have gone through the scripts and it looks viable, but it can fail in practice for any reason I am not aware of. I have also experienced this random "get off" bug once, but did not happened since. It may be related to the fact that the fire team is moved into a temporary group on the server, and its leader is created then silently removed in the process; perhaps the one getting of the piece is the new assigned leader, and the server decides for some reason that it should get off... What I can do for now is to temporarily lock the arty pieces for the duration of the mission.

Thank you for the fast feedback, Luke. What was your experience with more parallel arty missions per team? It should work in theory... but it is quite hard to test alone. Can you describe the steps leading to a situation when deletion of arty pieces or shooting their crew is necessary? I found the team removal/addition part quite reliable while testing, but it does not mean too much. Indeed there are more crew places per arty piece, but I never found a reason to put more on them as they do nothing. Use 1 crewman per mortar/howitzer and a driver/gunner per rocket launchers. Only the driver and the gunner will join the fire team, the others will stay with you. In theory it should not create any issues, and while testing I was able to conduct a fire mission with my AI sitting on the howitzer. Did you have any problems with that?

Ok guys, here comes the one with arty. I had a really hard time to put this part together as I had to twist the original code a lot to get the arty and the secop modules working on a dedicated server. I hope there are no major bugs. New additions in 1.2: + Added artillery. + Found a workaround which made the addon unnecessary. + Added more weapons/vehicles. + Merged with changes of the 1.03 update. + Fixed game ending with a single deployed MHQ. + Fixed: base construction menu for non-AI first commander. + Increased starting money to $1000. + Increased minimum side starting distance to 4km. + Changed MHQ repair cost to $15000. ---------- Post added at 07:44 AM ---------- Previous post was at 07:21 AM ---------- About the AI issues: IMHO warfare, or at least this version makes much less sense with a static base. The regular warfare had the major problem of forcing sides to build a fixed base, as moving the MHQ was very risky (a guy hiding with a Javelin could end the game). As both sides has enough firepower to obliterate a base quite easily towards the end of the game, the finale became a peek-a-boo where the first to find the enemy base wins. The mod intented to circumwent this by making the MHQ more easy to manoeuver and encourage the commander to build more bases, so destroying a single base cannot end the game. This is very hard to do well with a scripted AI commander, so I always had a human commander in my mind at the first place. *Always* have a human commander or you are deemed to loose.

Commander placement needs a lot of improvement. For now, I recommend taking it over from him at the start by voting and deploy it properly. You can give it back later. I have imported all the changes in the warfare module of the 1.03 update - there were only a few. As BIS did not release a dedicated server yet, it is harder to test the changes on one machine as arma2.exe -server uses the same .rpt file as the client.

As soon as I finished the arty. I have less time these weeks, but I hope I can do it soon, hopefully in the next couple of days.

I have fixed this construction bug in the development version. I am still struggling with the arty as the BIS module produces pretty mysterious bugs: it works on joint server-clients with the arty in your group or in a separate group, it works on dedicated server with arty in a separate group, but it does not work on dedicated with arty in *your* group, which is exactly the case I have to use. The SecOps was similarly bugged, but it is fixed already.

I am increasing the starting distance as people here suggested. I still has to check that it actually does something, as it happened in other cases that the variable is there, but it does nothing (town deployment range). I think you can place them on the map in the editor, and the scripts will handle the rest, at least there is some functionality to do this. But it may be broken, just like many others are ;) I have already added lots of stuff you have asked (like the colt, xm1014). The config files are in the Common\Config directory. I am sure that removing the addon will boost popularity - but it also had the positive side effect to turn away more causal players until the majority of the bugs were fixed. ---------- Post added at 03:22 AM ---------- Previous post was at 03:09 AM ---------- It is an entirely different matter when you are playing with your friends and when letting a mission run on a public server. One griefer may ruin your day. In many cases I have seen people login just to blow up their own HQ. You will never make people on a public server into votekicking for somebody stealing your vehicle. On public servers they usually do not even vote for a commander, either they do not know how to do it, or they do not care. If you have an admin, you have endless debates about who stolen what. The clean solution is to have all vehicles coming locked. Believe me, in ArmA1 warfare we were begging for this functionality. What I can imagine is to release two versions, one with default vehicles unlocked and one with locked. Or you can modify it on your own. The default is towards the bottom of the Client_BuyUnit.sqf script, change the line which says "_vehicle lock true;".