As it is the case with almost any InSim application, LFSLazy also use InSim buttons. Button system in LFS does a great job and yet it's simple enough. However, there are certain limitations while using it, for example, you can place only up to 240 buttons. That may seem like a lot to some, but surely it's not enough from the programmer's side when you want to show a lot of data.
A few months back, I started working on my own button system using LFSLazy overlay (like Radar and Dashboard work). I've put it on hold because of other personal obligations. With the recent design suggestions by nacim, we continued to talk on PM and he reminded me of overlay potential, so I've decided to get my button system near the finish.
The new button system has much more options than standard InSim one, for example:
unlimited number of buttons
complete control over the position on screen to a pixel
background and text color can be selected from a full range of colors and alpha (ARGB) for each button separately
possible to use different fonts
LFS color code handling is implemented as well and it can draw borders around buttons from full ARGB range. Firstly, I wasn't that satisfied with the performance, after some optimisations and testing I actually think it does a great job now. For example, pure LFS at same scene gives me 133 FPS, using my button system I get 126 FPS and using InSim 125 FPS. When buttons aren't that filled with text, it performs much better than InSim's one.
Sure thing, many great things come with this, but what I'm worried about is that there are still some people that have problems running LFSLazy overlay. I'm not sure that I will be able to help them. If they cannot use Radar or Dashboard (run LFSLazy overlay), they won't be able to use new button system. If I decide to move to the new system that will leave them disabled.
About moving to a new system, it can be easily be done using a wrapper function. It will take some time to make all code take the full functionality of a new system. Many great animations can be done, fade in or out on a group of buttons for example, but have in mind once I move to a new system there is no move back. Here is a screen shot of gadgets drawn using the new button system:
Are you gonna do them rounded and with configurable transparency?
Also text shadow is must have here, because then you don't need those button backgrounds opaque too much.
Also, apparently it looks like you're able to draw transparent stuff O_o. Then why don't you make car radar opacity configurable? I had to make it really small, otherwise I can't read some important stuff on F12 menu (like amount of fuel to put on pitstop). And by the way, you can make yet another option to reduce radar opacity while in F12 mode.
Still not sure how to efficiently draw rounded buttons. Each button already have different transparency (alpha).
Here is how my button update function look like:
Text shadow - good idea especially for split info, noted! One thing though, should I allow myself to choose once again another color for shadow, or maybe to just invert text color? I already see myself having lots of problems designing menus with so much options.
Regarding Radar opacity, I made it now reduce opacity of everything drawn by the radar by 50% if you are in F12 menu and center of your radar is bottom right part of screen.
Exactly, we can't help you if we don't know the error
Radar - cars temporary red after crash
Support for 0.6H4
Regarding new button system... There is a new option Other->Options->Use overlay buttons. Checking that checkbox will enable new button system, but first you must restart your LFSLazy.
Don't expect miracles, for now only gadgets, gadget editor, split info are drawn using new buttons. Still lot of stuff is not functional. This is probably the hardest way of them all to implement new button system, but good thing is it will keep current InSim menus intacted. If you notice any problems with InSim menus please inform me.
If you do not check this option LFSLazy should remain as it is.
BTW: As there isn't button limit in new button system, there isn't 19 gadgets limit anymore (while using new button system).
There are more and more open config usage in events these days, so I am here again with couple more ideas on how to identify the tracks.
First is intercepting insim button packages. You can get track name from airio powered servers by passing !tr message packet and then intercepting the response (which is either buttons window with track name or just message in the chat).
Another way which doesnt require airio or any tracker on server, is using md5sum or any similar hashing algorithm on the layout. You can get the layout info by setting ISF_AXM_LOAD in the IS_ISI packet. Then you collect whole layout into some buffer and then calculate hash sum of the resulting buffer. That way you will get unique ID for every possible track.
And lastly, it would be nice to simply be able to enter track name manually to LFSLazy until we come up with something proper here.
Using !tr isn't that good idea because it will bring Airio's track menu to front without user requesting it and packet intercepting isn't something I'd like to deal with.
Checking layout data is more on my mind. I'm not sure that I have any spare bytes in current pb files, so I'd have to make separate files for open configs which shouldn't be so complicated. My idea is to check position, heading of splits and finish line, because you probably wouldn't like your PB to be discarded just because one object was added/deleted.
But last way of handling open configs will not always work. Why? Because setting ISF_AXM_LOAD will not send layout data to InSim if you are connected to server at InSim start (there is no way to requesting layout). You'd have to either reconnect to server or wait for track change. This may seem pretty balan to you, but I know there will be people not carrying about such a stuff.
I didn't even know that you can scale LFS interface I will see what can I do, but not promising anything.
I never made a phone app and for now I don't have such ambitions, sorry
Pushed little update to support new 0.6H5 version.
There are also some other nice changes, but not so usable at the time. One that is the most important is that Split Predictor can now work on open config tracks. However it will not always work, because there is no way to request layout data, LFS only send this data when layout changes. That means Split Predictor will not work right as you join a server, but you'll have to wait for a layout change after which it should work.
vitaly_m has started a thread regarding lack of TINY_AXM in InSim to request layout data anytime. Lets hope this will be implemented soon
For some reason lazy stopped working for me on vista after the update "The procedure entry point K32GetModuleFileNameExA not found in the dynamic link library Kernel32.dll" (note: error message translated with google translate)
My issues with Overlay have gone now so no idea what it was.
Is it possible to have more than one acceleration statistic? So like 0-100mph, 0-150mph etc? Would be nice. Possibly some distance ones too like 1/4 mile, 1/2 mile, 1 mile times, but I suspect these are a nightmare to code.
Regardless this is still the best mod for LFS ever, and it's great to see the progress made. Great work!
Can you please try downloading LFSLazy from the link in the first post and try it. I don't recall making any changes in code that could do that, maybe some settings changed.
Once again, absolutely no changes to code that deal with Overlay injection.
Quite simple infact, my concern is actually how exactly to implement it without too much complicated settings. I guess having so much messages for all those events would be quite annoying sometimes, probably better would be to display times using a gadget.
For example two new gadgets "TIMER DISTANCE" and "TIMER SPEED". TIMER DISTANCE shows time needed to make 100, 200, 400, 1000m from a complete stop, and TIMER SPEED show time needed to achieve 50, 100, 150 kmph from a complete stop.