darkpeace

By chance, you might just happen to work for, study at, see or experience VBS1. For example if you live in Australia and study at the Australian Defence Force Academy (ADFA). You know....by...err....'chance' (wink wink, nudge nudge)

You did goto http://www.x20.org and read up on the history of the SpetzNats and the night / optical equipment they historically used before posting that thermals don't exist didn't you ? (The Soviets had the upper hand in night battles for quite some time, esp since they had white thermals for tank drivers, and not the early distorted green light amplification that the Americans had during the same period) [Once you update your reply feel free to remove this post, just not the topic itself - cheers ]

Might as well kill this thread off, lazy ass ISPs holding us back. Finding 384 players that want to LAN Flashpoint is near impossible, the highest I have heard of is 64, and the server could handle more (human) players, so long as AI was kept to a minimum. What is the maximum number of players a server can host anway ?, I mean setting 3072 players is all good and well, but at 64 players will it just reject connections ? (Flashpoint1) Just that over the net finding 384 players is easy enough Guess I'll just have to wait.... BTW: If you get a chance to use VBS VESL Training Server|54ms|131.236.20.224:2302 VESL Match Server|61ms|131.236.20.58:2302 A30VESLNET00061.VESL.local|53ms|131.236.20.138:2302 All Australian servers, all using ADFA/ADFA2 mod

I can safely assume another workaround, has already been found to the high CPU / memory subsystem usage in FP1 though ? (3000 soldiers, insane amounts of units, etc really hits any system) I hope FP2 server will get a boost from hyperthreading (above 55% CPU in task manager) and esp from quad or eight way servers. So how are you guys solving the high CPU usage issue in FP2 anyway ? (figured that the more crap you can process in blocks, the better, esp going beyond standard x86/x87 and into the added instruction sets for multimedia and even the newer 64bit systems) Still, 384 players on a LAN, any chances ?

You can still have multiple streams as above anyway, instead of 1 x 10 Mbps stream, would would want 40 x 256 Kbps streams for example, it is a hybrid of multicast and the current method. (See above)

I was hoping that Flashpoint 2 would handle 384 Players on a LAN, there is a point when the above is far more effective than the current method of netcode that all current titles use, I could therefore deduce that FP2 will only support 64 - 80 players in Multiplayer ?

True, however, instead of designing it for 64 Kbps, you could cram 4x the data into a 256 Kbps stream, Delta compression would still work for the above anyway, just less so, it is only a design concept (much like Doom IPX MP is compared to current titles) and could be improved upon greatly. So Flashpoint 2, will be closer to your typical FPS in Netcode ?

Correct me if I am wrong, but all players need to know the positions, movements, firing angles, etc of all other players ? Now over 384 players on a single server, that is a shitload of indentical packets, no ? One way is to only get sent data from players that are nearest you, this works, however if there are say 16 large battles going on at once, then 16 streamcasts (for each given area, the code for this is fairly basic) would be better than 384 dedicated 'channels' for game/MP data. It would: 1 - require less bandwidth 2 - be more CPU effient for the server, than processing what data to sent to 384 different players, based on what all players are doing (huge CPU usage) If the server could intelligently calculate that instead of 1 shoutcast (send all players all data on all other players), that in fact 16 lower bandwidth shoutcasts (send all players all data on players near them, collectively, and a sideshout at lower bandwidth for stuff that is happening miles away, which player-2-player shoutcast bandwidth of say even 33.6kbps is suffient, and the server doesn't even 'need' to know about it, but could receive it anyway for verification/anti-cheat/etc) would be better. In fact it could, or rather, should dynamically setup 'shoutcasts' within a given port range based on what is going on. Scenario 1 - All players within 2 km sq, 1 shoutcast should do Scenario 2 - Players split over 4 battles, 4 shoutcasts, 1 sideacast. Scenario 3 - Players split over 192 micro battles, 32-192 thin bandwidth shoutcasts, minimal sidecasts. (and so on, with everything in between) In the above example I use sidecast to indicate data that is player-2-player on a thin upload channel (as it is faster than going from player-2-server-2-player ping wise, and even 33.6 Kbps could sustain it, thus players that normally lag, would lag less so, in perception to other players that is) The server, capable of dynamically assigning X many shoutcasts based on conditions of battle, area, etc, all the variables, and a graph could be created, indicating to 'auto-optimize' the number of streams, esp if the game uses a sequential port range, even if only 64 UDP ports), as 192 Microbattles is very unlikely and overheads would prob make it pointless to use more than 64 shoutcasts at once. There are going to be people that don't quite grasp the concept immediately, however with todays insanely fast CPUs and memory subsystems, and the internets limited bandwidth, esp to consumers in the upload direction, I do believe that ultimately the about would be the option, but not for 32 players on a decent link, however there is a point where (and I think it is about 96 players) the above becomes far more feasible than the current backward thinking method. And forward thinkers understand the above is only a starting point. Personally I hope a codemaster with TCP networking and C++ skills picks up on the above. In fact the above is almost comparable to the memory system in multi CPU Sun systems (to a degree, but surely some of you see the similarities), as Sun 'solved' the memory bottleneck (tends to appear in 6 CPU or greater systems) in a manner 'similar' to the above. The above system might not be used in Flashpoint 2 (2005), but maybe in Flashpoint 3 (2007 - hopes) Anyway it solves 2 problems: 1 - Flashpoint makes more effective use of bandwidth/netcode 2 - Flashpoint is economical to run, thus becoming more popular than CounterStrike by mid 2006 (for example) And thanks to MMX/SSE,3Dnow!,etc it is more desirable to process such data as netcode in groups, vs per player/connection.

Seam to be alot of people with a 'can't do' attitude around personally I would like to see it tried (flashpoint or otherwise, lan or internet) and results, checked, improved, etc I mean ultimately it is the future of gaming, as even a low end link (upstream, kept within a given ISP) would be far more cost effective than the current 'each player needs truely dedicated bandwidth'. And if people with 256 Kbps upstream can host, then the ISP saves on servers, and can keep datastreams internal, esp if specific port ranges are used that do not conflict with anything else. And if Flashpoint 2 became more popular than CounterStrike I am sure that all of us would be very happy, esp if we don't all need to go hire $200/mo servers to play it in MultiPlayer. (Remember Australia, 1536/256 ADSL is the best we can get, without forking out ALOT more $$$)

I never said ISPs would like it, but it is easier to code than people might like to think it is. It would be nice to have a huge Conquer the Island using this technology on a LAN with upwards of 384 players at a LAN duking it out on a huge battlefield. (similar to MFCTI 1.16+) However if shoutcasts where limited to a given ISP, etc, then it would not cost the ISP in external bandwidth. However 1 single Flashpoint 2 server with 384 players, would obviously be using more bandwidth than some low end Counter-Strike server, and it may even be more cost effective to host 384 players on 1 FP2 server, vs 384 players over 20 or so Counter-Strike servers with the forementioned shoutcasting technique. Even coding both shoutcast and 'standard' netcode would not take much longer, and given the environment the server admin could select which was desired. (Best of both worlds scenario)

Laymans terms If you want to send voice to 32 people at 16 kbps It can use 32x16 Kbps (512 Kbps) OR It can be shoutcasted and only use 16 Kbps There is no reason why the same concept can be used for netcode, esp if clients can shoutcast to each other. Have the game use ports 230x - 240x if need be (what ISP blocks game ports ? - I'll avoid them) An ISP isn't going to block ports if they are used for gameplay and not pirating music, games, applications, etc

It would have huge savings for both voice and netdata. It may even help with cheaters.

See Also : http://community.codemasters.com/forum....t394957 Anyone else got other stuff to add that is Soviet Thermal, US LightAmp, Optics, etc related ? Its a topic in itself (IMHO), but it relates to the game engine / visuals.

http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?act=ST;f=57;t=38516;st=0;r=1;entry527576 See the bit on pseudo shoutcast at the bottom of the post. ~~~~~~~~~~~~~~~~~~~~~~~~ Also has anyone mentioned letting players 'join' into a AI player, during a battle ?, so an AI slot can become a human player (sort of like the Matrix) Think outside the box, -Psuedo shoutcast the netcode = more bandwidth -Perhaps have clients act as sub-servers and shoutcast what they can to other players -Warn if someone is capping their upload speed to screw the shoutcast (after a 2-5min check) and kick or ban repeat offenders (long story short: it would let them cheat, and become harder to hit) Having a central server handle everything is so, 1985 (pun intended - lol)

lol....doh And after all that I forgot to mention the same thing for the network setup. Eg: if players need / want to host MFCTI / or normal maps, etc, they need between 64kbps and 384kbps+ PER SLOT in the UPSTREAM direction. I am sure that many FOOLS on ADSL seriously think that a 1536kbps connection is 1536kbps BOTH WAYS, even though down here in Australia the ADSL consumer speeds are (and will be until 2007) 1536/256, 512/128 and 256/64. Now 2 players in MFCTI is possible to host on 1536/256 if everyone is on the same ISP, the other 12 players can be on a LAN. Also seperate LAN and Internet traffic shaping in the server, if you need to cap it at 220kbps you don't want the 12 LAN players been capped to 220kbps/12+ as then their is ARTIFICIAL network congestion to the Internet players.... (This may have already been fixed, just exclude 192.168.0.x and the other LAN classes from bandwidth shaping) Do a similar benchmark Flashpoint.net 2005 (just a lame name) -Show how many players they can host -Do not let them go under 48kbps PER SLOT Or..... Would it be possible to 'shoutcast' the same data to all players, with a tag to those players that are far away from a battle that it doesn't matter if they drop 'that' packet, where as for a battle somewhere else it would be the vice-versa situation (assuming a psuedo shoutcast technology, that can selective 'lose' packets to players in different areas) This way a 1536/256kbps connection could host (in theory) unlimited players, as they would all get (a psuedo selective) shoutcast stream from the server at 256kbps (which is a shitload off bandwidth for gaming, on a per player basis) Damn, should've posted this under the netcode

What Flashpoint 1.96 (and later) really needed was a benchmark / autoconfiguration tool. For example, one that runs through a 30min (or less) benchmark going through texture sizes, for smoke, vehicles, cockpits, terrain, weapons, explosions, etc The ATi FireGLs can only do 8 (full) hardware lights, which is pretty good, although the setup allows up to 32 lights (good, but dynamic lighting didn't scale well in hardware) Smoke, Explosions, etc, well smoke need only be a 16x16 alpha effect (looks the same when layered), explosions could be changed, or done at 128x128-256x256, etc Well, run through the combinations of various settings, and advise the user what to expect (min/max/avg/delta min), if they enable say, feature X (2048x2048 textures) or say feature Y (32 dynamic lights vs 4 or 6) Give it a cool name like a FlashpointMark 2005 etc, and submit the program/demo/benchmarker to a few PC mags (atomic, pc user, APC, etc), to a few websites, and the like. Do a database of what video cards get what score, with information on the particulars (like how slow 32 dynamic lights are, or layered alpha effects that actually are computed as (layer1+2+3+4+5+6+nth alpha effect DIV nth = pixel colour) which hurts performance, since they are all the same colour 'smoke cloud' it could be done at (total smoke layers+final non smoke layer DIV grand total alpha layers). eg: smoke, background = 50% (smoke x 2 layers) background = 2/3rd alpha - 1/3rd backgnd (smoke x 24 layers) background = 24/25th alpha - 1/25th Cuz damnnnnn, alot of smoke alpha textures can drop me to 6-12 fps on a RADEON 9800 XT card with P4C-3000+HT Maybe have a setting that limits the total smoke, alpha effects to X many smoke puffs, and include results in benchmark (in increaments of 4 or so) It would be quite simple to code, 1 -Benchmark available settings in CFG file (with min/max framerate available to tweak, as it is in user.cfg) 2 -Show the results, and let the player decide what features are worth having on, warn them if it will give under 30fps or under 15fps, as some idiots like to break their PCs) 3 - Write the CFG file, let them post the FlashpointMark 2005 score somewhere. In all my years of computing, have noticed that benchmarks (however meaningless) are always popular, if a good one cropped up (I eg: read above) and was distributed (as above, and to www.tomshardware.com, etc) I am sure Tom (and every other PC Mag, reviewer, out there) would start running it. And it is a damn cost effective way to use word of mouth on a global scale and get publicty for the game. (if it was possible to do this for FP1985 I would seriously try coding one up, but it doesn't support logging the frame rate) Also gives players a sneak peak at what to expect the game to run like on say GeForce MX420/440 and the like, what detail they can 'pull off' at 30fps +) I am sure others will post their thoughts and ways to improve or even write the program. I am off to play at 60fps now, after much MANUAL tweaking of files that the autoconfig does not even touch Still, Flashpoint is to tactial war sims as Half-Life was to first person shooters - Good Work guys