0xDEADBEEF

Wow, quite some activity since I last checked, nice to see! @propeler I wanted to check out your new firmware that works with odrive, but it seems your repository is gone again? What's the deal here? I still have my old assembly mechanically ready but I never go to finish the controller. I do have an odrive board I can just flash the firmware to, but it seems it's not available anymore?

I would really put 1 at the end. But other than that It's a very solid list. It would be marvelous to see an ED Employee specifically responsible for Mission Scripting purposes. There's so much potential to empower the users to create better content. I am 100% sure it would be fantastic return on investment for ED.

Very nice, thank you! I had no clue there was an odrive library for arduino This alone will save me hours! I had the original MS FFB Pro in the 90s, I think it's still in my basement. Can't wait to finally fly with force feedback again with a proper grip and more torque thank you guys! What a fun project!!

Would you mind sharing your code? I just finished my mechanics and am about to tackle exactly this. I was actually looking at fino, but it seems it does not really matter which library to use I'm going direct drive with hoverboard motors by the way, landed a nice deal on a used hoverboard without charger for 30€. I was lucky the seller did not check used prices on those boards, a charger would have only been 15€ on amazon ...

Ahh that is very good to know, thanks! I understand it was cheaper back in the day. That is good news for most of us, odrive is rather simple to obtain, albeit not cheap, it's still affordable ouch that's bad news, but understandable. Any news on wether there will be support for warthog-style grips? Maybe I could contribute some code for that in the future, shouldn't be too difficult. Oh and one more question, would you mind sharing your original Fusion 360 designs, alongside the step assembly? Again, thank you for the great work you've shared!

Hey @propeler! I've had some closer look at the schematics and pcb (Very nice work on the PCB by the way . I always appreciate when layouts are a piece of art and not just a bunch chaotic connections). It seems the main difference to a stock Odrive is you are not using the DRV8301 motor drivers, but instead half-bridge ICs with separate current sense amplifiers for each phase. What's the reason you are doing this instead of just measuring the total consumption of the Motor as Odrive does? The reason I'm asking is because sourcing those current sense amplifiers in the current semiconductor shortage is really hard. The only source for them I could find is aliexpress, and they are 25€ each, multiplied by 6 those suddenly become more expensive than the whole board I do happen to hav a few F405 MCUs around from repairing drone flight-controllers for friends and the half-bridge ICs are rather easy to get in comparison. I'm looking for the best solutions to proceed. Ofc if you could provide a version that works with stock odrive would be ideal (already have one of those). Or maybe substitute those ics with jellybean opamps would probably be most const effective, but for that I'd need more understanding how the circuit works. Ideal of course would be if you shared the sourcecode so we can adjust and make that build ourselves. I'm a bit late to the party so I don't know if releasing the source has been discussed or if you plan to do it or not. It would for sure be a huge contribution to the community if you did! The hardware design itself is already fantastic! We just need a way to maneuver around the semiconductor shortage

@propeler amazing work! Why are you not putting the code on github? Everything else is there, it would only help improve the project!

Realistic or not, archairpilot me can't tell, but I can tell that I am incredibly busy making sure I operate it within sane parameters, and still wonder why there is only occasional radar returns, and if I manage to track a target, the track will be long lost before any aim 120 goes active in bvr engagements, and if I make it WVR i have much higher survival chances using my eyeball mk1 ...

Same problem here as well, Radeon 5700XT

I like the freedom of picking up whatever Mission comes along your flight, but maybe it would be good to be able to select a mission and have it exlusively available for yourself, to prevent others from "looting" it ...

Hello! As per the documentation on hoggit the S_EVENT_MARK_ADDED event is supposed to contain an initator parameter. This would also be absolutely expected, as you would not be able to tell who placed the mark otherwise. It appears on my test-rig that with the current OB Version the initiator parameter is not passed along the mission (or is passed as nil, which is the same). This is the table I receive with the event: event = { ['coalition'] = 2, ['idx'] = 251658242, ['time'] = 28930, ['id'] = 25, ['text'] = '', ['groupID'] = -1, ['pos'] = { ['y'] = 522.64993671191, ['x'] = -239932.57126467, ['z'] = 734296.67458392, }, } Setup to reproduce: simple mission, add a script handler. Run in dedicated server on local machine in separate work directory. Connect as a client with standard dcs installation. Place mark. No initiator provided.

Thank you very much c0ff! Much appreciated!

Every server is different in that regard. you will have to name the server to get a definite answer.

It (wrong client id returned in server side) did happen again after the server being up for 25 hours. One weird thing I noticed was a Unit:getName() threw an error: "Unit doesn't exist", even though the line before is "if unit:isExist() then" and apparently returned true. I also notice inconsistencies with hit event. The initiator and the weapon are identical, however I cannot call getPlayerName() on the initiator, I get "attempt to call method 'getPlayerName' (a nil value)". All this started at the end of the log and the 24 hours prior. log is attached. Interesting events happen at the end around 20:00. dcs_log.rar

Unfortunately this bug is still unfixed. Please let us know if we can do anything to help you reproduce the issue. I (we) can run any script you want on the server to collect information that helps to reproduce. This is a serious issue for many servers, please let us help! Edit: disregard, sorry! I got relayed incomplete information. It seems the scoreboard is still recording kills for others, but the kill event on the serverside script now returns the correct client id! I'll have a closer look when i find time.

It seems that the issue is usually affecting clients with ID 3 and 6 when it occurs.

I just had another case where the wrong player was returned to spectators. The player with Client ID6 got killed. It triggered a Server side onGameEvent("kill", ...) with client ID 3, which apparently sent the wrong player to spectators. This time I could not find a relation to unit IDs. The player who got killed id a reconnect a little bit earlier, so he was not a "fresh client", if that's even a thing.

I've just finally managed to get a little bit of time to test it. But it is really hard to pinpoint. Best I can do is outline the things I have observed: - I joined with player ID 5, which was previously assigned to another player I'll call player1 - I joined a slot, and the group ID my helicopter was assigned to had the same Unit ID as the f16 player1 joined previously. (This was edited: previously it said groupId, but it was the unit ID) - the player with ID 4 left the server - everything seemed fine, my kills were counted normally and no anomalies were observed - another player connects and gets ID 6 as expected - I fire another vikhr and the log is as expected including kill event. - player with ID 6 enters a slot - I fire another vikhr and hit the target. there is no kill event being dispatched, only unit_dead and - this is is not entirely accurate in terms of when exactly this is observed unfortunately, should have taken a note, but i guess this is the point I realize I have 15 kills, when in reality it was ~5 - player with id 2 fires a weapon, hits and events are dispatched as expected I also coincidentally noticed that my Unit ID was exactly the same as the different unit player1 (also client id 5 previously) had. Afaik Unit IDs are supposed to be unique, I guess this might be able to cause issues like this. I also find interesting that the unit ID matches the one who had the same client ID previously. I have attached the log as well. Hope this helps. The events I have described happened from about 14:45-15:35 dcs.log.rar

A user on my server is reporting this: I'll try if I can get this tested later today or tomorrow.

Not a list, but my server has it: http://91.133.95.88 whenever a pilot ejects his pilot will spawn a csar mission. If it gets rescued the pilot gets his life back plus the rescuing pilot gets 1000$ ingame cash, which can be used to call fortification convoys or awacs/tankers.

Hello! TLDR: To fix performance issues with Radeon cards try toggling off/on "Instant Replay" in your Radeon Software. It helped in my case. I have had a weird FPS drop issue today after updating to the latest openbeta update, and figured the fix might be worth noting for others. I am using an Amd RX 5700 XT GPU and am used to rather solid 60 fps (my displays refreshrate). Today after the update it went down to solid 15 fps. I deleted metashaders and fxo folders and did a repair, which did not change anything. Then I noticed when Windows was focused on anything outside of dcs, the FPS would go back to normal. The ultimate solution was in the Radeon Software. I had the "Instant Replay" feature turned on. I figured this might be something that could cause a performance change when focus changes I turned it off and evoila, my framerate was back to normal. I turned it back on and fortunately frames stayed normal :pilotfly: Hope this helps for some of you! :joystick:

I wish. Though I'm afraid the dedicated server has little to nothing to do with these problems, as it would essentially be standard dcs code in a nutshell to run platform independent with apparently a bunch of code left out like most prominently 3d rendering. It will still run the same simulation and same netcode, and as long as the netcode looses sync/freezes clients when the server runs code that blocks up for multiple frames it will have the same result, dedicated server or not. (two problems: code blocking in the first place and the netcode not handling it gracefully which I am guessing is why we see lagspikes when missiles launch and track during close combat in mp). Of course I expect and hope a dedicated server will improve performance, I just don't think it is going to be the magic solution. It will most of all make hosting servers significantly simpler and more affordable. that said, I see more positive signals from ed towards multiplayer than the past few years. I still wish they would set up a dedicated and experienced team (= with team members who have successfully made networking code for more than one high-client-count large-world game) to significantly improve multiplayer performance, so we maybe one day can have servers with 100+ clients flying without people opening threads because they think there are "lag hackers" in DCS. Unfortunately writing networking code that keeps a large amount of clients in synch with so many things happening like in dcs with every single thing requiring complex calculations both client and server side is very very far from easy and simple. The fact that ED - and I think many in this subforum will agree - has put rather little focus on this topic for years is not helping ofc. That said in response to the OP: There is no such thing as lag-hackers. Sorry to disappoint you.

also make sure you use the latest official nvidia driver!

wild guessing from the log it might be a shader issue. you can try deleting the fxo and metashaders in your saved games/dcs folder (Benutzername/Gespeicherte Spiele/DCS). If those folders are missing the shaders will be regenerated, maybe that will solve your problem. You may also wanna try switching to the open beta branch as there were many changes to the f18 already. It may fix your problem too, while it may also introduce other problems. Maybe worth trying (to switch go to your programs/dcs folder, hold shift and right-click the bin folder and click "open in command prompt" ("Eingabeauffoderung hier öffnen" oder so ähnlich), then type "dcs_updater update @openbeta". But try deleting the two shader folders first.

We are the ones that have understood you can only develop proper simulations of declassified/out of service aircraft, because you would have to do guessing for most vital systems, which is not a proper simulation.