Jump to content

sinistar

Members
  • Posts

    11
  • Joined

  • Last visited

About sinistar

  • Birthday May 15

Personal Information

  • Flight Simulators
    DCS
  • Location
    United States
  • Interests
    Cycling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I am seeing very similar issues. Has there been any solution?
  2. Yeah, I just don't know how patient is reasonable - and not sure on the PayPal policies on contesting a non-delivered product. However, thanks for the comment!
  3. Hello all, I sent BuddyFox PayPal funds early this month (January, 2023). I received a confirmation email within a day, but haven't heard anything since - and have not received the product (UFC). I have tried contacting them - both from the website, and also responding to the confirmation email, without any answer. Has anyone recently dealt with them? I know I can file a report with PayPal, but I really don't want to: a- Cause any strife for BuddyFox, as I know they are a small company b- I really want that UFC! Any/all advice appreciated.
  4. I had this issue happen to me twice a few nights ago while landing on the Syria (Al Minhad - runway 09) map on the Hoggit server. The first time, the issue was egregious enough that I had to abort the landing and go around, the second time it wasn't as pronounced and I was able to land on the first attempt.
  5. Has anything ever come of fixing the brightness on the clock and UHF repeater? Holy cow those are bright.
  6. Man am I frustrated. I purchased the MFG pedals a number of months ago and have been battling them on-and-off for quite some time. Things have now gotten so bad that they are basically unusable. I'm not getting much support from MFG - just suggestions on things I have already done/tried. Here are the different hardware configurations I have tried: Pedals plugged direct into MoBo Pedals plugged into Atollo powered USB hub Pedals plugged into VanTec higher powered USB hub I have tried two different USB cables I have also gone through the firmware update process on the pedals After all of this, I still have regular disconnect/reconnect while in-game. A message pops up in the upper-right corner of the DCS window (see screenshot). Most of the time, the disconnect is quickly followed by a connect message, although sometimes they don't reconnect and I have to manually unplug/plug. I feel as if this is somehow related to the querying of the pedals by the game itself, because during other uses of the computer, I don't see/here the USB connection messages. I'm hoping someone has some thoughts on what can be done? I've asked MFG for more help and/or a replacement unit, but now I feel as if they are ghosting me.
  7. I'm going a little deep on this because I'm seeing things which don't appear to fit that model all of the time. One of my confusing situations shows up while monitoring the bottom line of the CDU - that with the blinking cursor (line 9). I would expect to see about two calls to that update every second (cursor-on / cursor-off) which is the case most of the time. However, every so often (maybe once every 5 blinks) there is an extra call to that update function. This has lead me into the danger zone of trying to understand more fully what the dataflow looks like from DCS to my serial-port connected Arduino, and as a side effect, understanding better the program flow. Unfortunately, my C++ experience is very limited which is making my research more difficult. I suppose my next route will take me into understanding the StringBuffer class defined within ExportStreamListener.h: template < unsigned int LENGTH > class StringBuffer : public ExportStreamListener { private: char receivingBuffer[LENGTH+1]; char userBuffer[LENGTH+1]; volatile bool receivingDirty; bool userDirty; void (*callback)(char*); void setChar(unsigned int index, unsigned char value) { // DCS-BIOS will occasionally send data even if it did not change if (receivingBuffer[index] == value) return; receivingBuffer[index] = value; receivingDirty = true; } public: StringBuffer(unsigned int address, void (*callback)(char*)) : ExportStreamListener(address, address+LENGTH) { memset(receivingBuffer, ' ', LENGTH-1); receivingBuffer[LENGTH] = '\0'; userBuffer[LENGTH] = '\0'; receivingDirty = false; userDirty = false; this->callback = callback; } virtual void onDcsBiosWrite(unsigned int address, unsigned int data) { unsigned int index = address - firstAddressOfInterest; setChar(index, ((char*)&data)[0] ); index++; if (LENGTH > index) { setChar(index, ((char*)&data)[1] ); } } virtual void onConsistentData() { if (receivingDirty) { noInterrupts(); memcpy(userBuffer, receivingBuffer, LENGTH); receivingDirty = false; userDirty = true; interrupts(); } } bool hasUpdatedData() { return userDirty; } char* getData() { userDirty = false; return userBuffer; } virtual void loop() { if (hasUpdatedData()) { if (callback) { callback(getData()); } } } };
  8. Thanks - it is becoming clearer now! Are there any docs explaining the structure of that "stream" - the specifics of the CDU display (line 8 ) starting at 0x1280 for example.
  9. Hello community, I am looking for a bit of guidance in terms of the DCS-BIOS "API". Specifically the calls associated with the CDU display. It seems that the common model for gathering CDU display data is code like this: void onCduLine8Change(char* newValue) { printLine(8,0,newValue); } DcsBios::StringBuffer<24> cduLine8Buffer(0x1280, onCduLine8Change); Where the function "printLine" is defined by the user something like: void printLine(int row, int col, char* newValue) { int16_t y = row * 32 + 6; mylcd.Print_String(newValue,CENTER,y); } (This will be slightly different depending on the display library used for the particular TFT) I guess my fundamental issue is that I am not very comfortable with C++ syntax, so am confused as to what this particular line is doing: DcsBios::StringBuffer<24> cduLine8Buffer(0x1280, onCduLine8Change); To my untrained brain, this looks like a function(method) definition of type StringBuffer<24> (inherited from the DcsBios class), but I don't think that is correct? How would it be called? Also, any hints as to the two parameters passed into that function? The first looks like some type of offset(0x1280), while the second seems to be a reference to the function just declared above this call.
  10. This looks like great work - Kudos! With regards to the project zip file you uploaded @jj3 , what software did you use to create it?
  11. @Tippis, can you elaborate a bit on "adding a custom radio setting file to the mission"? I'm not sure how to do that. Our squadron _really_ needs a common set of presets for our hawgs...
×
×
  • Create New...