Bridge Commander Multiplayer Tweak -1 reply

  • 1
  • 2

Please wait...

Guest

I didn't make it!

0 XP

 
#1 13 years ago

i have submited this tweak to bcfiles is this ever going to be hosted. this tweak has been tested and is proved to make bc multi player better and less laggy and a bit more stable.




Guest

I didn't make it!

0 XP

 
#2 13 years ago

http://bridgecommander.filefront.com/file/11_Tweaked_Scripts_MRK2;47330 starforce why has this been posted as anonymous when i emailed you with a readme and my name in the readme. the multiplayer patch is is a network buffer tweak that i did with darkshimmer i have beta tested this for weeks and it has been proved to help multi player. in the tweak is 4 multi player files the buffers are set to 256bytes for 28k modem compatability as standard i have set them to 2048 kbytes. on a 256kbyte upstream from the server host bc struggles to send all the data that is needed to have a proper multiplay game ie` game laggs really bad over distance by setting the buffers higher bc remains abit more stable i have been hosting my bc server and some usa members have also game play is better it acts more like it should do. i have set the buffers for broadband users i recomend 512k down with 256k upstream for 6 players and 1024k with 386k upstream for 8 players. regards




Guest

I didn't make it!

0 XP

 
#3 13 years ago

1.1A ADVANCED MUTI PLAYER BETA. 1.1 advanced multi player network buffer tweak 1.1a beta done by Mr UnHoLy DeViL dark shimmer and brain storming by x done on 18/9/2005 1.33 pm gmt if you want to use this in a mod please ask me [email="devil_1@blueyonder.co.uk"]devil_1@blueyonder.co.uk[/email] also you can email me with feed back. changes set buffer levels lower for compatiblity with networks that cant deal with 2048 byte upstream also should use less band width this is now set to 4x the default level of the buffer with was 256 bytes now set at 128 kbytes please test this out and give me feed back regards sorry for missing readme in mrk 2 i was very tired after beta testing 18 hours :eek: strait you can get the update here www.devilseed.pwp.blueyonder.co.uk/devil/unholydevil/modproject/1.1AADVANCEDBETA.RAR




Defiant

Free GNU user

50 XP

28th March 2002

0 Uploads

742 Posts

0 Threads

#4 13 years ago

128 kbytes? I guess you want to say 1 kbytes, or 1024 bytes.

We will check this one for kobmaru, and if it does prove to be more stable we would like to include this change in Kobmaru. http://bckobayashimaru.de/phpBB2/viewtopic.php?p=2020#2020




Guest

I didn't make it!

0 XP

 
#5 13 years ago

Defiant hi their test it out i have found it to be more stable and less laggy with 2048kbyte setting i am trying this new setting and would love feed back and yes you can use this tweak if you want. were still under the restraits of the appc moduals in the core exe but i feel that the python is tweakable and maybe i can get this more stable`oh sorry for the crapy tec talk the mp engine sucks lol :) and i am very tired been making mistakes in my posts the new setting is a buffer of 1024bytes or 1k which i am aiming for 128k conections no longer dialup regards




Defiant

Free GNU user

50 XP

28th March 2002

0 Uploads

742 Posts

0 Threads

#6 13 years ago

I'm not 100% how this can increase performance since the communication done by Python is only a small percent of the total communication done. However started by your change I've started a small grep on the App.py and have found this:

TGIP_BUFFER_SIZE = Appc.TGIP_BUFFER_SIZE

A small "print App.TGIP_BUFFER_SIZE" on another computer returned the Value 64 for me. Guessing the unit is "kb", I think we could use a higher value here maybe? I've typed "App.TGIP_BUFFER_SIZ = 256" in the console and it remembered the value so looks like we are able to change it. However I've done any testing yet since I'm too tired too boot windows.




Guest

I didn't make it!

0 XP

 
#7 13 years ago

hi their i agree about the buffer tweak it is only a small tweak and more needs to be done i am not a expert on c++ or python but ill give this a shot. in the core exe are modules the python is the inteface to these modules appc calls are made via app.pyc its a long time since i had a proper look at the sdk. when bc loads it starts to load python files starting with autoexec.pyc in that script it makes a call to the app.pyc and the app.pyc makes calls to the modules in the exe some of these modules are network sound grx and so forth. their is a memory leak i even get lagg in single player ie choppy frame rate at times and i got a very good gamming machine. i believe that this is because ships are not unloaded from memory proper. i am to tired to look at the python but the coomand is class object. load and unload i cant remmber the proper commans for it but unloading and loading ships from memory are in the python`also i noticed in the sdk a file that allows you to make modules which is interesting. i dont know about Appc.TGIP_BUFFER_SIZE but its worth a shot if you have msn you can add me with my email. i dont know how much help i can be to you but ill try i am just learning python but find it intresting as its very configable. i kinda bet that the appc has more to do with network than the mission files maybe its just a recive buffer i tweaked but it does help. regards




Guest

I didn't make it!

0 XP

 
#8 13 years ago

The thing we noticed in the mp mission files was that BC was using a 256 byte stream to transfer certian bits of info to the clients (damage, scores and shit like that). This led to the idea to open them up a bit and see what would happen given that the majority of users had faster connections nowadays than they did 3 years ago. It worked. We started to notice that the games were that bit more stable so devil and another guy expanded on it. The recent betas we did have been met with some good success, most notably allowing some guys to host a small server and get a decent uptime whereas before they just couldn't. As for devils numbers I think they are just a bit mixed up. According to the stock mission1.py, in the stream setup thingy it states that the value 1024 = 256 bytes (bugger knows how, could well be crap arithmetic or a last minute change). Now I would agree that the 256byte setting was set to allow a 28k modem to connect (by the skin of its teeth). Basically, we altered it to run a tad quicker. Devil found that changing the value to 2048 he got nice drop in lag. Its by no means a be all and end all fix but it helps but we noticed that under ideal conditions (ie a server full of fast connections with no proxying) the only thing that brought the server down was "Spawnlag" which would get progressively worse until server death. On the upside we were seeing server uptimes of 2+hours in many cases with much less visible player lagging throughout. Its pleasing to hear that you and your team are interested in Devils work and I hope you see a difference. Kobi is the most promising Mod I have seen to date and it would be a real shame if poor stability was to be its only drawback. The Holy X (aka X punk, that connie refit demander!)




Defiant

Free GNU user

50 XP

28th March 2002

0 Uploads

742 Posts

0 Threads

#9 13 years ago

ok, some information: The appc is the "stbc.exe" and App.py is the Interface between the Python scripts and the stbc.exe. So, when you call a function or a variable in the App.py, the correct function in the stbc.exe is used to execute your command.

We will test this change in kobmaru in the next days.




Guest

I didn't make it!

0 XP

 
#10 13 years ago

Defiant hey m8 i know what the appc is bud and how the python makes calls to the modules i am going to look into the scripts asap. if you know any thing about python load up bc in test mode host a game and run the debug console`you can enter commands their and find out whats going wrong with the python before the game crashes. regards




  • 1
  • 2