Fixed typo
Hey thanks. Would you be able to do the merge request through github? https://github.com/karljj1/kdis I have setup CI tests so want to try and use this more so to avoid any compilation issues slipping in again. Ill then sync it back across to here.
Hey no problem. I have done it myself in the past. I have setup a github version with CI that should detect these issues in the future https://github.com/karljj1/kdis
Recent merge #55 breaks GCC builds
I have pushed a fix. Im also working on setting up a github version of kdis which includes CI. If all goes well ill move the project over.
Sorry I accidentally deleted the post in the moderation queue. Thanks for sending the CI link, I have been meaning to get something like this setup. Ill look into the failure.
FrozenBehavior Enum Error
Thanks!
Hardening against defective PDUs, and some minor fixes identified by static code analysis
Ah yes I do need to put together a new release :)
I think its likely that the old data was wrong. These were generated from DIS 6 standards mainly with some coming from DIS 7. Over 10 years ago now!
Thanks!
Added support for multiple NICs to the Connection class.
They were scraped from a file however I dont think that's what happened here. I think its likely the file had a typo or some human error. The scraper would add a _ when the value started with a number. E.G WarheadType _1umWarhead = 31, _5umWarhead = 32, _10umWarhead = 33, Ill try and fix this although we will ikely need to keep the old enum and also add a new one so that we dont break any code that uses the wrong enum.
Merge requests are ideal although im happy to take submissions any way really.
Hey. Yes merge requests are ideal because I can accept and merge the change though source forge and don't need to pull the code myself.
Unit test link error
Merged sourceforge.net/p/kdis/code/merge-requests/53/
Thanks!
fixes #104 unit test link error
Thanks!
DeadReckoning calculator returns last-reset orientation for RPW and RVW methods for cases where dead-reckoned orientation is not calculated.
Beam Function Enumeration is off by one.
Thanks I just pushed a fix
Hi, My math is a little rusty but you probably want to first convert the lat, lon and altitude into cartesian coordinates to make the math easier. GeodeticToGeocentric should be able to do this for you, its in KConversions.h. Now you will have a position Vector(X,Y,Z), speed and bearing. The speed is essentially the magnitude of the vector you want to calculate. So its basically a triangle in 3d space where the speed is the magnitude https://www.khanacademy.org/science/physics/two-dimensional-motion/two-dimensional-projectile-mot/a/what-are-velocity-components...
Hi, The descriptor type can vary so you need to cast it to the correct one based on GetPDUStatusFireType(). Before DIS 7 this was always a MunitionDescriptor but it can now also be a ExpendableDescriptor. so something like if (pFire->GetPDUStatusFireType() == MunitionFTI) { MunitionDescriptor* desc = dynamic_cast<MunitionDescriptor*>(pFire->GetDescriptor()); } else { ExpendableDescriptor* desc = dynamic_cast<ExpendableDescriptor*>(pFire->GetDescriptor()); }
Hi, The descriptor type can vary so you need to cast it to the correct one based on GetPDUStatusFireType(). Before DIS 7 this was always a MunitionDescriptor but it can now also be a ExpendableDescriptor. so something like if (pFire->GetPDUStatusFireType() == MunitionFTI) { MunitionDescriptor desc = dynamic_cast<munitiondescriptor*>(pFire->GetDescriptor()); } else { ExpendableDescriptor</munitiondescriptor*> desc = dynamic_cast<expendabledescriptor*>(pFire->GetDescriptor()); }</expendabledescrip...
Oh thanks a lot for the changes, it really helps!
The core PDU structure is there its just there is a large number of different IFF Record types that can be added into it (50~), I think I had managed around 4/5. Do you know which record types you need?
Thanks!
ClockTime and TimeStamp improvements
Thanks!
PDU Status record bitfield misaligned
Hi, At some point yes but I don't have as much free time to work on it at the moment. I'm more than happy to take contributions if someone else wants to finish the work though.
Thanks!
Converted Kdefines to fixed width types.
Thanks!
Vulnerabilities detected by static analysis
Intercom_Control_PDU Decoding
Hmm I just checked and this is correct. Are you using an old version of KDIS? The latest master branch already has this fix. I fixed it in 2017 7963d9bd
Various minor issues
Hey. A PR or a patch is a good way to submit changes.
Hey! While I dont do as much active development on KDIS at the moment I am very responsive to PRs and changes submitted from other people. I am happy to take contributions as PRs or you can email patches to me(email in the source code). Yes it probably is time to roll out a new tagged release. Most people seem to pull directly from git so I fell behind on official releases and tags but im happy to update it if you need something. Karl
Thanks!
Clang reveals minor syntax error - easy fix.
Fixed in https://sourceforge.net/p/kdis/code/merge-requests/47/
Closes #97 - Clang minor syntax error.
Thanks!
Pass C/C++ compiler to externally added project
No theres nothing for this. Its quite specific to the application so tricky to implement in a generic way. There is also rules that a PDU must be sent every so often regardless of changes (heartbeat).
Update for commit 759ab63
Thanks!
2 commits that support building under Linunx and C++11; 1 commit to improve
KDIS::DATA_TYPE::ClockTime does not handle timePastHour correctly
Hey thanks ill take a look into it.
Hi, Can you please provide a method or constructor that would allow network connections to use a particular NIC card for outgoing packets (multi-homed)? Hmm. Im not sure, ill have to look into the socket code and see how that would work. can the KDIS::Network::Connection constructor figure out that the supplied IP Address is multicast or not? No theres no checking, it uses the SendAddressIsMulticast parameter to determine if it should be treated as multicast or not.
Hi, *Can you please provide a method or constructor that would allow network connections to use a particular NIC card for outgoing packets (multi-homed)? * Hmm. Im not sure, ill have to look into the socket code and see how that would work. can the KDIS::Network::Connection constructor figure out that the supplied IP Address is multicast or not? No theres no checking, it uses the SendAddressIsMulticast parameter to determine if it should be treated as multicast or not.
Hey,By default, the PDU version is set to the lowest version required to support that PDU. So if a PDU from the DIS 5 standard is sent then the version will still be DIS 5. Setting KDIS to DIS 7 just adds some extra PDUs and Data Types.If you want them all to be DIS 7 then you could set this before you send the PDU. Regards Karl
Hey,By default, the PDU version is set to the lowest version required to support that PDU. So if a PDU from the DIS 5 standard is sent then the version will still be DIS 5. Setting KDIS to DIS 7 just adds some extra PDUs and Data Types.If you want them all to be DIS 7 then you could set this before you send the PDU. Regards Karl On Wednesday, 23 September 2020, 00:03:27 BST, noreply@sourceforge.net wrote: Hi Karl, I think I may have found a bug or I my be misuing KDIS. In ccmake, I configure KDIS...
Hi, For Fixed Datum records the informatiion should be in the SISO-REF Enumerations for Simulation Interoperability document. Section 7.1 in the 2011.1 version. It describes the ID enum, the data type and length in bits. If you need further information such as what types of FixedDatum to send then you will need to refer to the 1278.1 standard for that PDU. This is the best document to use for refernece. For VariableDatums records the 1278.1 document is the best resource as it tells you the full structure...
Hi, For Fixed Datum records the informatiion should be in the SISO-REF Enumerations for Simulation Interoperability document. Section 7.1 in the 2011.1 version. It describes the ID enum, the data type and length in bits. If you need further information such as what types of FixedDatum to send then you will need to refer to the 1278.1 standard for that PDU. This is the best document to use for refernece. For VariableDatums records the 1278.1 document is the best resource as it tells you the full structure...
Hi Steve, For arrays you need to do each byte at a time, KDIS_STREAM only works with types of DataTypeBase.Fortunately, VariableDatum already has this behaviour by default. You only need to override the Decode function if you are adding in some custom fields, if all you want is an array of bytes then it already does this. You can get and set it with GetDatumValueCopyIntoBuffer and SetDatumValue.So if all you want to do is send an array of data with id 12345 then you dont even need to create a custom...
Hi Steve, For arrays you need to do each byte at a time, KDIS_STREAM only works with types of DataTypeBase.Fortunately, VariableDatum already has this behaviour by default. You only need to override the Decode function if you are adding in some custom fields, if all you want is an array of bytes then it already does this. You can get and set it with GetDatumValueCopyIntoBuffer and SetDatumValue.So if all you want to do is send an array of data with id 12345 then you dont even need to create a custom...
Sorry I forgot to reply! Im a bit unsure about this. Its Linux sockets, not an area im all that familliar with. This is what I do now // Linux non blocking // KINT32 uliIoctBlock = !m_bBlockingSocket; // 1 enable, 0 disable. iResult = fcntl( m_iSocket[i], F_SETFL, O_NONBLOCK | FASYNC, &uliIoctBlock ); It may be worth commenting this code out as the socket should be blocking by default.
What OS is this on? I only ever tested it on WIndows so its possible it does not work correctly on Linux.
Great news im glad you got it working.
Yeah it should work just like an istream. Thats how I decode all the values in the PDU stream >> value1 >> value2 >> value3; etc It will do any endian swapping you need.
Ah ok that makes sense. The data is just treated like an array of chars so no endian swapping is done. You could use a KDataStream to extract the values, it will do the endian swapping for you. Something like: pSig->Decode(stream,false); Length = pSig->GetDataLength(); pSig->GetData(DD,Length); KDataStream stream(DD, Length); KUINT32 myFirstValue; stream >> myFirstValue; // Endian swap and extract the first 4 bytes.
Maybe try dumping the data to a file and check if the bits are correct by hand. If they are then your code is wrong, if not then mine is ;)
Hi, The timestamp is calculated in TimeStamp.cpp CalculateTimeStamp Scale of the time is determined by setting one hour equal to (2^31 - 1), thereby resulting in each time unit representing 3600 s/( 2^31 - 1 ) = 1.676 micro secs or 0.000001676 seconds.
Can you share the code that is doing the converting?
Oh. When you call GetData you are supposed to pass in a buffer for the data to be copied into. Are you passing in a null pointer? The idea is you create a large reusuable array of KOCTET and then pass that into GetData. So when you do D = new KOCTET [uiDataSz];, just do that before you call GetData and pass the array in.
Nothing looks wrong in that. Can you try debugging the Decode function or do you have a sample dump of one of the PDU's I can test locally myself? Maybe if you just write one of them to a binary file before its deocded so I can see the raw data?
Nothing looks wrong in that. Can you try debugging the Decode function or do you have a sample dump of one of the PDU's I can test locally myself?
How are you getting the PDU's? Are you using the PDU_Factory or the PDU_FactoryLink16? Have you tried using a Link16_Signal_PDU? When the PDU is decoded the payload is also decoded so there should be no further work needed, it should be inside of the PDU, stored in the m_vData vector. Can you examine m_vData in debug and see if its the same as you get from GetData?
How are you getting the PDU's? Are you using the PDU_Factory or the PDU_FactoryLink16? Have you tried using a Link16_Signal_PDU? When the PDU is decoded the payload is also decoded so there should be no further work needed, it should be inside of the PDU, stored in the m_vData vector. Can you examing m_vData in debug and see if its the same as you get from GetData?
Hi, Is the above Decode calling pSig->Decode?
Hey. Oh no I feel like im back at school! Im not sure you have enough information to calculate the 3d velocity vector here. You could calculate it in 2d but to get 3d you will need another parameter. https://wildbunny.co.uk/vector-maths-a-primer-for-games-programmers/vector/
Yeah its under Project Settings -> C/C++ -> Preprocessor -> Preprocessor definitions It should be the same as the cmake generated project that you built the KDIS lib with
Yeah its under Project Settings -> C/C++ -> Preprocessor -> Preprocessor definitions
Its because the header files are also using the define. Its needed to know the inheritance structure for the PDU Header. In your original error you can see it expects the signature to be VHeader6 but it was built with a VHeader7 so it cant find the symbol.
Thanks. Glad to hear its working for you.
Hi, I have never tried to use KDIS with Unreal, I actually work for Unity now ;) Did you define the DIS_VERSION in Unreal? It sounds like you need to define DIS_VERSION 7 which is why it worked with 6 as thats default.
linux test failures
Thanks!
Some encode/decode unit tests are failing.
Oops sorry, I missed that one. Merged now
#98 Transmitter_PDU.cpp not compiling
Transmitter_PDU.cpp not compiling
Thanks!
#99 Some encode/decode unit tests are failing.
Thanks ill take a look
Thanks!
EnumEmitter.cpp won't compile - BeamState vs BeamFunction
https://sourceforge.net/p/kdis/code/merge-requests/41/
Fix for presumed copy paste error from 759ab63a4d0a3c1fdcd3ac531ec0b4abf1922b22.
Make most constructors explicit and friends
Thanks for answering. Yes thats correct. pHeader is a pointer to the base type of whatever PDU is returned, so you just need to cast it to the releventa PDU to get full access to all its data. You can do that by either checking the GetPDUType() parameter or simplfy doing a dynamic_cast and checking if the cast is null or not.
Thanks for answering. Yes thats correct. pHeader is a pointer to the base type of whatever PDU is returned, so you just need to cast it to the releventa PDU to get full access to all its data. You can do that by either checking the GetPDUType() parameter or simplfy doing as dynamic_cast and checking if the cast is null or not.