WarWolf

I really hope that this post doesn't come too late in OFP2 development-cycle to be useful.... If I want to play with some other folks in Australia and USA and Europe (from UK) at the same time, should it not be possible and more importantly - useable and playable for all concerned? Â I think an improvement in this situation is long overdue, and I think it wouldn't be as complicated as it first sounds. Have seen many suggestions about using clustering, dunno if it's going to happen or not, but why not take the concept just one stage further, with improved player-numbers, massively reduced lag, and a better MP experience for all. Interested? Â Read on... The idea is a simple one, and I don't believe it'd be overly hard to implement, if thought through properly and with due consideration to the (useful and good) abilities of the many server admins out there. Decentralisation is what I am talking about. Â Using the machines connected (and connecting) to a game more wisely. At the moment I see online games using a central server, with that server's CPU/Conn stretched to the limits, often with a very poor ping or connection at the players end, with predictable desync'ed and laggy results. So: Why only use one server? hmm. Â Well, co-ordination of the gameplay and synchronisation is obviously required and that does need to be centralised, BUT it IS possible to do that in more than one stage and improve the pings to players simultaneously. I think an example would serve better at this point... Fred and Bill want to play on a server together. Fred lives in London, and Bill lives in Los Angeles. Currently the best choice for them would be to select a server somewhere on the East coast, probably New York that has the best ping to both of them. Â That still means that their game will have the lag of their combined pings, but at least the lag is balanced and desync shouldn't be too much of an issue. Â Note that their pings to the server are based on their ordinary household connections. Now, consider that many servers out there reside on serious sized pipelines, not just the little ADSL connections that we mere mortals have at home, with limited upload speeds etc... Would it not make a lot more sense for Fred to connect to a server nearby in London, with a tiny ping, and for Bill to connect to a server in LA, also with a tiny ping, and then for the huge bandwidth of those two servers to act as a motorway/freeway/autobahn* Â between them? Â Even if there still needs to be a centralised decision-server for multiplayer co-ordination, the simple ability to offload and speed up the comms would improve lag problems. So now think about the inter-player co-ordination. Â Say Jill (in UK) joins the London OFP dedi-server and then joins the game that Fred and Bill are playing.... If the London server can handle the synchronisation between her and Fred, whilst still leaving the LA server as 'master' server, then that's less work for the LA master server, AND less desync problems 'cos Fred doesn't sync to Jill via two transatlantic hops. Now think about that scenario, using 3 or 4 servers co-operating, with 30 or 40 players on different continents, each local server synchronises the players local to itself, then synchronises the result with the other dedi-servers through fat pipelines, which in turn sync to themselves and update their local players. Â Game logic etc. COULD be shared by the co-operating servers, however a central server for this processing would also suffice, less synchronising to worry about that way for the time being. Co-Operative server architecture...hmm even got a name for it. !!Ok, that architecture could also be a great help when downloading maps to players - sync the maps on the servers first, then download locally from each server - less download time = game starts quicker..... As an also to the above, would be interesting to see that file-download 'bonus' applied to dedicated addon-servers....useful also for x-box too I'd reckon. The above blahblahblahetc. could be applied to non-dedi server games also - but some automatic configuration would need to take place to determine the power/bandwidth of connected machines to decide which act as servers - this becomes a knotty problem when disconnections etc occur - and JIG happens - (JIG is an automatic spinoff of this architecture anyway). Â I think that for the time being it would be far simpler to make this an additional capability of dedicated servers, configurable by server admins themselves to decide (in which games to which other servers) which server becomes the master... Â maybe ping could be used instead, but this isn't a failsafe method so manual tweaking would be desirable. That is the only difficult part of the design - deciding upon which server becomes the 'master' server. Â Perhaps allowing the tailoring of the cooperation between the servers to have multiple setups saved for different configurations. Â Like for a game using EastCoast/WestCoast servers have one setup defined, or between continents you'd have a different server defined as master, etc, etc. What I describe is possible with not too much effort, time allowing of course. Â Be cool if it could happen for OFP2... WarWolf. p.s. (hint, hint, lol) IF this proves useful, (for OFP2?), you could repay my kindness by giving us an optional more-realistic flight model+non-auto-centering HAT switch view for helicopters - please, please, please (BEG!) Â Fly ApacheVsHavoc or ComancheVsHokum to see what I mean by flight model... rudder-pedal / multi-joystick support would also be a boon..... PLEASE!

I see what you're saying, but if your clan were to have a ladder match with another clan a long distance away which arguably could/would have their own server too, would reduced lag not be useful in that scenario? Â I have participated in some horribly lagged clan matches in the past, to the point of folks teleporting around in front of my sights, usually just after firing too..... EDIT: I didn't actually mean for a server to route additional traffic, just the traffic to/from it's actual connected players - and respond to those that are in the same game via their other dedi-server(s). Â Basically I mean the optional ability to link dedi-servers together for better performance.... ie the server would only route traffic for games that it's connected players were actually participating in....hope that makes it clearer?

lol, Well you're very probably entirely correct about this critical system, but somehow I can never forget all the blue-screens I've seen (or black at worse and earlier times) over the years... Yes, mainly due to bad drivers or misbehaving apps, but there's times when the maze of documentation and code contain some flamin weird contradictions in less critical bits. The new OSs seem a load more stable, but regular reboots are still necessary to maintain performance and get a fresh memory space. WarWolf

It's my guess that the -nomap command disables some usage of the Windows operating system-level API functions for memory mapping files. Basically what these APIs do is allow a developer to load a partial section of file only at a time and map that section into memory directly so that it can be worked upon and read as if it was part of the RAM, and swap different parts of the file in and out of memory at will, rather than the 'old way' of creating a file pointer then using 'seek' functions to fast forward to the part of the file that you need to read, reading it, and then storing that info somewhere if you need it again later. The best uses of the file-mapping APIs are for inter-process communication, and for jobs that need repetitive access to the same parts of the file many times, the benefits in a read-once or few scenario are limited indeed due to the extra layers of code required to run those API calls. If the code exists and is reasonably well implemented that can avoid use of these APIs for simple file-reading and data cacheing then in many cases it can be preferable to use a custom-coded solution, especially in a high-performance program like OFP certainly is. Custom-written-cacheing of already read information from a file can be much more efficient than the API, but a helluva load more work to do for the programmer. Kudos to the OFP devs for having the foresight and patience to experiment with both methods to find the optimum rather than just taking the easy route (mapping only). The filemapping API can also use up your valuable memory faster, and windoze memory-handling has NEVER been the best around, which I suspect may be some of the reason for these strange glitches in addon behaviour without the nomap command. Personally until recently I didn't know of the nomap command - and after reading this thread, and reflecting for a while, I am gonna try this out and compare performance myself, as I bet BIS code is tighter than MS's So thanks to all for all the comments and threads. Keep em coming WarWolf.

Stoopid question, really, but I remember (perhaps wrongly) that I used to be able to stand up straight while holding a rifle, instead of half leaning over and sighting. You know, like all your AI teammates do while relaxed and not shooting, the gun is held more loosely across the chest. I can't remember 1. if this is possible, and 2. if so how to do it.... pls help.......

ahhhh. thx for that folks!

Thanks for that, but I don't mean the Z/Q keys, like (Z)prone / (Q)kneel+stoop / (Z)stand. You know when you're in standing-up 'mode', if you look at your soldier from 3rd-person view, he's aiming through the gunsights while standing - if u look at the other (AI) soldiers nearby they ain't standing that way, but are in a more relaxed posture with the gun across their chest, not aiming.... I cannot remember if I can get my dude to do the same or not, and it's doing my head in!! If so, how? If not, OFP2 pls? (My manuals/keychart are 150 miles away at my parents house (long story), so this confusion is twice as frustrating...)

I agree with the need to customise weapon loadout in the editor using drop down listboxes, maybe in a separate popup dialog from the unit dialog, say primary, secondary, handgun, and ammo count for each, this would be better than doing it the hardway through the init line. I can see that this might be problematic with a rucksack though, unless the rucksack's a separate object which gets a loadout and _then_ gets linked to a unit. The most important point raised in my opinion is that of camo-textures being selectable. I get constantly frustrated by all the separate addons for each camo scheme + subsequent searching + downloading etc. IMO it would be MUCH better to have EVERY unit and addon - including 3rd party - include at least the 3 basic camo schemes - green / desert / snow. That would need to be standardised across all addons, which would make mission editors jobs more simple, the players acceptance of different terrain type missions would be improved by not having to download stuff for every mission type, and would fit very well with a dialog-selected camo type for the units you're working with. Possibly an option for the mission / mission editor to set this GLOBALLY, therefore all units you place will conform to this scheme without having to hand-edit each unit placed....? My tuppence worth, anyway. WarWolf

Dunno if you tried this, but you said you'd played with soundcard acceleration, did that include the acceleration settings within windoze itself, or only the in-game settings? (start->settings->controlPanel->Sounds&Multimedia) on mine it's under the audio tab, click playback advanced button, and disable the hardware acceleration to see if zero accel will stop you crashing.

thx for those gems of info guys! no idea on dedicated before that = cheers!

duhh, o yes, TRANSPORTUNLOAD, sorry my mistake - been a while since I used it lol. <embarrassed grin>

Create the chopper, then create the troops far enough away from the chopper to not be part of the chopper's group. Name the chopper something like UH60_1 and put in the init line of each of the soldiers: this moveInCargo UH60_1; Then when u start the mission the troops will start in the helo. Next, set waypoints for the _helo_ put a MOVE about 2 inches short of where u want to unload the troops, then the next waypoint should be an UNLOAD waypoint at the place you want the troops to get out. Then u can put the rest of the waypoints in for the helo to RTB or whatever. The troops waypoints should be set as if they actually start the mission where the helo's UNLOAD is. I have noticed that under MP, especially when laggy, that at occasional times the UNLOAD command gets ignored by the OFP engine (at least it did from 1.85-1.92 - might be Ok now), I have never found a solution to this though. further info: If you want the helo to take off after a delay, or after forward troops have cleared a corridor then you need to look at triggers, synchronisations and variables to affect a GET OUT as the first helo waypoint immediately on top of the helo start position, and make the condition of the next waypoint to test when the triggered variable is set e.g. bGoHelo is a variable that is first set to zero 'bGoHelo=0' in an Init trigger, then when a trigger happens it's action is 'bGoHelo=1', and the waypoint condition is 'bGoHelo==1' (yes you need two '=' to test equality). There are good tutes on this subject around - check out on ofpec.com, or check inside a mission that uses these already. Big topic. Hope this helps

Well, for the time being I've rolled back to 1.92, but for online playing this sux cos most other folks are running 1.96 I'd forgotten how cool it was to hover, look out the side window and use the mouse-stick on the saitek's throttle to aim the cannon independantly of the view (works in only some 1-man helos though). Would be good if the manual-fire allowed manual aiming of the cannon by default in the same way in all helos. WarWolf

This might well be stating the obvious - but if the sound disappears when you are near a loud explosion(s), then returns a few seconds later it is simulating the temporary deafness that would occur at that time.... this is probably not your problem, but thought I'd say it anyway

Yes I miss it too... FYI the old CrazyChopper maps can still be downloaded from http://www.wibblecom.freeserve.co.uk/Index2.htm The versions there need no addons. (I've lost the addon versions somewhen during a reinstall so will have to re-make them sometime), TheFreezer Island still works okay, but the missions lower down for it require quite a few addons, and the links for d/l them are probably broken by now, one day I'll get around to updating them.... Does anyone still have a copy of my 'Tanker' CTF which didnt need addons either (was in desert area to East of Nogova airport) or the DeltaVsRanger CTF. If so pls send me a copy as I've lost that too. btw. I am now running v1.92 as I fly choppers and need the POV to work properly via the hatswitch (BIS killed the HAT in 1.95 ) - are there any clans / servers out there that still run 1.92 ? IMO it was the most stable of the helicopter friendly versions, with better flight physics too than previous/later versions. O yeah, if anyone is currently hosting the CCCTF on their server pls let me know as GSpy seems to be dead (population-wise) and those on there seem only to play C+R .... WarWolf.

If the above post sounds flame-like I apologise, but I do feel very strongly about this issue, to the point that if something isnt done about it then a previously enthsiastic if techically limited member of the community (me) might well give up on ofp entirely, and ofp2 will have at least one less customer. The hat switch has been wilfully broken in OFP 1.95+. I want it fixed back the way it was so that I can enjoy playing and flying online again. Which at present I cannot do simultaneously due to this new 'feature' - btw is it x-box related by any chance? I would certainly object to having to pay more money to get something working again that was working fine before - if you take your car to a garage and THEY break the steering wheel, would you be happy if the garage told you you'd have to buy a new car to get the problem fixed?

I tried posting my own question re this autocenter issue, but the response said no-fix until OFP2.... This sucks. Â BAD. Â The behaviour of the hat switch has been constant through all versions of OFP until 1.95. Â To change it now is simply unacceptable. Â My thread was closed so I couldn't respond - (?!!!) - so posting here instead. The ability to look around freely in a helicopter is crucial to flying, target spotting, and landing operations. The new autocenter behaviour has made the game unuseable for helicopter operations. My only option it seems is to reinstall from scratch AGAIN after only 3 days of a clean install, in order to reload my old 1.91 patch so that I can once again enjoy flying my helicopter addon collection. Â BUT this means that I won't be able to fly online with all you other OFP nuts. This is totally unacceptable. It simply must be fixed to allow/return the original behaviour of the HAT switch. This problem - and especially the attitude of 'we aint gonna fix it - so buy the next version' has impaired my enjoyment of OFP to the point that I am considering uninstalling completely and not bothering to reinstall. If no fix for this to restore the default behaviour is going to be forthcoming then I will not be bothering to play OFP any more, create maps (and simple addons) etc., encourage other players online (many hours I have spent helping and encouraging folks via Gspy chat to create missions and enjoy the game) nor will I be very enthusiastic about buying any new version OFP2 in the future. This is a sad day for me, I have played OFP since the first CWC release, and the uncaring attitude that seems to be the official line now will seriously deter me from supporting this title any more, and buying OFP2. The change in the OFP code is a new one since 1.95. Â Never before has the HAT switch autocentered after engine startup in a helicopter or plane. Â In a plane I can see it would be useful to optionally autocenter, but not in a helicopter. Note the word optionally - please MAKE IT OPTIONAL at the very least. I bought OFP legally, same with OFP:R. Â Now the developers have broken that which I paid good money for. I want it fixed. Â I want it returned to non-autocentering or optional auto-centering. Â I want to be able to fly online with my m8s and be able to enjoy that flying. I would be seriously annoyed if this post / thread gets locked like the last one I posted. Â I WANT to know how strongly other folks feel about this issue. To summarise: Â devs please fix the auto-centering problem for us helicopter flyers, or you might well lose at least this one customer when you release OFP2, maybe many more. WarWolf.

Hey all, Been away for a while, now I'm back, just reinstalled up to 1.96 and there's been a change in the code since 1.95 it seems. I found other threads saying about the view auto-centreing being a problem - I agree very strongly! I am always flying around in helicopters too, but the hat-switch view has now been killed by this auto-centreing problem - It USED TO stay looking in the direction you pointed to last (once the engines were started), but now it won't hold a view direction. Major problem for the flying players! DEVs: WHAT IS GOING TO HAPPEN ABOUT THIS PLEASE???? IMO I think this new problem is important enough (to all of us that fly) that it justifies a patch release just to correct this newly introduced (but annoyingly incorrect) behaviour. Coming in to land now is a very difficult process as you have to fight to get a decent view all the time - very distracting and it really is killing the flying experience in OFP:R for me now, and I suspect that many others share my feelings. Please please please make fixing this a high priority. Cheers, WarWolf.