zorlac

Doubtful... only briefly looked at the LUA export so far, but doubtful that TB could support the abris in any meaningful way.

i`m glad to be back....

Your "news on the 15th" link... is that Groove I see in the right hand picture of the three? :) And is that Jim as well? I had the great pleasure of a fantastic tour around Duxford with Jim and a few other 504 members over the Easter weekend earlier this year. The RC-Sim rig has come a long way since I went there a a couple of years ago to show them TouchBuddy. So, who is going to the FSX show then? I might tempted, now that my enthusiasm for flying has regrown since I purchased the russian BS version. Yes, 500+ days without playing a single game, then WHAM Black Shark is out and I return... a little rusty though :)

I enjoyed that... good job!

Highly doubtful there will be any new development for TouchBuddy in the near future with relation to DCS:BS (or anything else to be honest)... I havent looked at the code since March/April this year, and have no real yearning to start agin.

lol :)

basgy back seat...

you may want to mention that the forum over at DCS appears to be using the same login credentials as on here, so you dont need to create a new account for yourself :)

yay! new fourm... new game/product... same old users :)

wait... just wait..... :music_whistling:

its not like I havent tried ... and tried... and... :)

Some beta testers who run TB already have (aparantly) but as they are covered by their non-disclosure agreement, they cant show me any of it. One day i`ll get to fly in Black Shark.... one day REALLY soon I hope....

actually, we havent actually worked together yet :) This was a quick "kludge" to get the two applications working happliy on the same system. When I finally get the enthusiasm to start coding on TB again*, I am sure we will work a lot closer to make sure things work better (or at least I am hoping we can work closer). (* Am kind of burned out on TB at the moment. I`m not abandoining it, i fully intend to carry on development, but after the last release, and the long period coding for it, I want to leave it alone for a while. Ideas are still going on in my head, but none have really got to the point where I absolutely need to get them coded right now :) )

The TEWs is not a radar screen, it is a radar *receiver* display, and will only show you the direction and relative signal strength of objects that are emiting a radar signal. Unless an object is scanning with its radar (air/ground/sea), you will not see it on the TEWS display. I am away tomorrow, and possibly into Sunday, but I think I might be able to find a few tricks to add to the profile that will help :)

I set the "lomac_data_file =" line to point at a dummy file in the TB directory so it would show something when people first start it. I did forget to think about that as a possible problem... sorry!

Are you running VP+TB on the same machine as LOMAC? Or on a seperate machine?

woohoo! Great stuff... I will still look at why TB + VP are fighting each other for LUA :)

Try this, and add this to the end of the standard export.lua dofile("./Config/export/tbvp-export.lua") tbvp-export.zip

OK, this should be fun :) on the end of the standard export.lua file, I add: dofile("./Config/export/tacview.lua") dofile("./Config/export/virtualpanel-export.lua") dofile("./Config/export/touchbuddy-export.lua") Now, whichever one is *LAST* in this list is the only one that actually gets run. I am not an LUA expert, but I am guessing that something somewhere is being reassigned during the load/run of these lua files, and the last one to run is the one that is getting used. How to fix this? Err.... I dont know, and I am unsure how to check what it is thats causing the problem. I could "merge" the two scripts and see if that would work. I`ll see what I can do, but there must be an easier way of doing it :(

I`ll take a look at this later this evening and see what I can do to get it working Z

Cool... cant wait for the fixed version (how the hell did you find this bug? :) )

after going outside and taking a deep breath, I`m back, and much more relaxed. The way I see this whole Max_FPS is like this (and this may need to be confirmed or denied by Eagle Dynamics, because they know the code). The server is processing the mission, the objects, the movements, etc. For each loop through the list of things to check and process, it then sends the new data to the clients. Without the Max_FPS option, at the end of each processing loop, it then goes off and generates the new on screen graphics. (This is what a client would want, the fastest game and graphics update). So a server running without Max_FPS and running at (for example) 40fps is processing the game loop 40 times per second, and also updating the screen 40 times a second. Now, my understanding of lomac (unsure about other games, never had a game that stresses the system quite as much) is that with the Max_FPS option, you can tell the server to keep processing the server data, updating its idea of where everything is and what its doing, but at the end of the loop, dont always update its own graphics screen. Sure, send the game data to connected clients as often as it can, so they get a nice data update speed on their system (and their own graphical FPS settings on their own machines), but only update the local graphics so many times per second. If the server is processing the game data and is going through the processing loops 40 times a second, thats the important thing. Updating its own graphics screen is not imporant. Its only a graphical representation of the data it has generated and held internally in memory, and spending time updating its own local graphics display on a machine that no-one is actually looking at is wasting CPU cycles that could be used more usefully to update the internal game data that it is passing back to the clients. So, they way I see it running is: $last_gfx_loop = time(); while ($game_running == 1) { server_data_loop(); if ( (time() - $last_gfx_loop) >= (1 / $Max_FPS)) { graphics_update(): $last_gfx_loop = time(); } } So it would do kind of this: server_data_loop() server_data_loop() server_data_loop() server_data_loop() server_data_loop() graphics_update() server_data_loop() server_data_loop() server_data_loop() server_data_loop() server_data_loop() graphics_update() (etc) Of course if lomac is syncronous, and only updates the server loop on the Max_FPS rate then that kind of sucks. I still see 70-128Kbit traffic per client even with the servers running with this Max_FPS setting applied to the server, so its spitting out data at the same rate to the clients at "Max_FPS = 5" as when I ran the server without the Max_FPS setting, and 5FPS is certainly low enough that even when the connected client "predict" where objects should be, they would see the 0.2 second warps/glitches as they received new data from the server. What I do see is a lot of spare CPU cycles on the server that allows more clients to be connected and processed. These spare CPU cycles are coming from not having to calculate its own 3D objects and display them on it own screen quite as often.

Good god, you really think I dont have a clue, dont you? Done

OK, let me rephrase my comment then: If you set the server's screen FPS to something low, it spends more time doing "server" stuff than "updating the graphics" on its own screen. Do you at least agree with that for Lomac servers? If you dont manually force the FPS on the LOMAC server and let it run as fast as it can, then its spending a lot of time updating its own graphics display, using CPU cycles that could be used for background game server routines. Do you agree with that? And this may be the bit that we disagree on: So long as its not the amount of work that the server is doing that brings the FPS rate down (i.e empty server runs at 80fps, full server runs at 5fps), then capping the screen FPS on the server will free up more CPU cycles for the game to run. Setting Max_FPS on the lomac server only affects the graphics update thread within lomac, not the game/client/position update thread, the important bit for a server. (A few guys on here know who my employer is, and roughly how long I`ve been there, and I bet they are grinning like Cheshire cats right now :) )

I find that an incredibly patronizing and mildy arrogant reply. I was just pointing out what I had discovered about the server load versus the FPS on the lomac servers I run. If you wish to do some willy waving about stuff you have done, and make yourself look "superior", then you go ahead. Have a nice day.