Comments (12)
Each of those fields are 16 bits. So a value of 230318 is too large to represent.
If you need to represent more than 65536 entities what I've seen some sims do (e.g. JCATS) is spread them across multiple app id's.
from open-dis-java.
Hi there @leif81,
isn't the tidy fix to change the storage format, so the compiler does the work for us?
https://github.com/open-dis/open-dis-java/pull/22/files#diff-1eb60207f4db64faccdc7d3109d35c8fR20
from open-dis-java.
Hmm, have come across a similar occurrence. The exercise id should be 8 bits. But, the API is specifying a short then casting that to a byte:
https://github.com/open-dis/open-dis-java/blob/master/src/main/java/edu/nps/moves/dis/Pdu.java#L189
Well, I say _come across. I mean to say _spent 30 minutes trying to find out why the exercise id I was passing (2000) was arriving as a different value (208) ;-) . Correcting the API would prevent the next opendis user from encountering this problem (since the compiler would warn that 2000 was too large):
dos.writeByte( (byte)protocolVersion);
dos.writeByte( (byte)exerciseID);
dos.writeByte( (byte)pduType);
dos.writeByte( (byte)protocolFamily);
I'm happy to include this fix in my PR too. Is there any reason why we shouldn't correct the API?
from open-dis-java.
@mcgredonps would know best for why an int was chosen. Most of the API is generated from xmlpg.
But I'm guessing an int was chosen because in Java there's no concept of an unsigned short. A Java short is 16 bits, but the problem I think with using that is it's signed so it only represents a valid range from -32,768 to 32,767. Where we want to able to represent 0 to 65536.
If the api were changed to a short, what happens when a value between 32,768 and 65536 is provided?
from open-dis-java.
the exercise id I was passing (2000) was arriving as a different value (208)
That sounds like a similar problem. An ex id of 2000 is too large to represent according to the spec. The exercise id field is 8 bits. So valid range is 1-256.
from open-dis-java.
But I'm guessing an int was chosen because in Java there's no concept of
an unsigned short. A Java short is 16 bits, but the problem I think with using
that is it's signed so it only represents a valid range from -32,768 to 32,767.
Where we want to able to represent 0 to 65536.
Aaah, I guess this is the lesser of two evils.
Hmm, so how would my grief have been avoided? I guess I could add some code to throw a runtime exception is out-of-range values are assigned. That would have helped me to get to the bottom of my troubles.
What do you think?
from open-dis-java.
I guess I could add some code to throw a runtime exception is out-of-range values are assigned.
Ya that's not a bad idea.
A challenge I'm starting to encounter is how to make changes to the API without creating larger and larger deltas with what XMLPG generates.
from open-dis-java.
> A challenge I'm starting to encounter is how to make changes to the API
> without creating larger and larger deltas with what XMLPG generates.
Yes. I guess the first priority is to capture as many fixes as possible, then the second priority is to reduce the maintenance burden of applying them. Well, until the maintenance burden becomes too large for someone to take on, when it becomes the first priority :-D
from open-dis-java.
Ya that makes sense 👍
from open-dis-java.
I think the solution is to just change what XMLPG generates. It’s pretty agile about
mass changes. The problem is of course keeping the minor tweaks applied after
re-generating the code for things like VariableDatum. I’ve been using a patch
system—after the code is generated apply a Unix patch to tweak the code. But
if the code changes too much the patches start to fail.
Yes, the underlying problem was lack of unsigned shorts/ints in Java.
On Mar 4, 2016, at 7:34 AM, Leif Gruenwoldt <[email protected]mailto:[email protected]> wrote:
I guess I could add some code to throw a runtime exception is out-of-range values are assigned.
Ya that's not a bad idea.
A challenge I'm starting to encounter is how to make changes to the API without creating larger and larger deltas with what XMLPG generates.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-192325330.
from open-dis-java.
It’s possible to use the char type as a ghetto unsigned short in Java. I’s Unicode and two bytes
long, and can be used as a numeric type. but that’s likely to confuse everyone looking at the API,
and require all sorts of type conversions when performing operations. One could also use an
object in the place of a primitive, but that’s likely to cause a lot of memory bloat and GC issues.
The Ant build scripts have a section for applying a patch after the xmlpg code generation—it calls
a bash script in the patches directory:
case "$1" in
dis)
# Pdu.java, apply patch file
patch src/main/edu/nps/moves/dis/Pdu.java patches/dis/Pdu.patch
# Marking.java, apply patch file to ensure character fields are exactly 11 bytes long after set operations
patch src/main/edu/nps/moves/dis/Marking.java patches/dis/Marking.patch
from open-dis-java.
Closing issue, it doesn't have a tidy resolution. The underlying problem relates to the lack of unsigned data types in Java.
from open-dis-java.
Related Issues (20)
- Dis7 Signal PDU Missing Radio Identifier HOT 8
- Address "UNFINISHED" PDU's
- DIS Network Traffic on Macs HOT 4
- SISO-REF-010 Updates HOT 4
- Parsing the Articulated Parameters parameter value field HOT 1
- Unmarshal doesn't save/reset buffer position causing issues when with useCopies HOT 2
- Update Maven Central? HOT 2
- DIS time converter HOT 4
- Absence of edu.nps.moves.disenum in Release 5.0 HOT 1
- DIS 7 PDUs advertise zero length HOT 4
- Unmarshaling enters infinite loop if the length field is zero. HOT 2
- A question about CoordinateConversions HOT 8
- Transmitter PDU Variable Parameter Support HOT 2
- ElectronicEmissionsPdu dis7 Support HOT 4
- Difference with standard protocol for orientation HOT 3
- Deprecate DIS_DR_* and DIS_DeadReckoning classes HOT 1
- BehaviorProducerUDP throws buffer underflow exception when variable datum is greater than MTU HOT 4
- DeadReckoner:perform_DR() for (some) articulated parts not working HOT 1
- Deprecate some disutil classes
- Wrong IFFDataRecord implementation in Java and missing on C++ HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from open-dis-java.