Blueprint format/API?

  • ...]Also a different question now:
    I created two test cases one with a single ramp texture 21 and one with a single stair1 again texture 21 to test the block data structure.The values I get from the blueprint file are:


    blocktypehexdec
    ramp26C19921
    stair10F513921


    seeing this result I understand that 21 refers to the texture, while the first two numbers refer to the position? If that is the case how does the game know if the block is a square block, a ramp or a stair1, a stair2, or a stair3 etc.?

    Not where I can test this, but does the variation byte have any difference?


  • @Steve I was talking about blocks (blocks are made in the blockbench and their names are block, ramp, stair1-3, half-block, cylinder, half cylinder, etc.) the code block you included above is for objects (objects are made in all other benches i.e. sawbench, workbench etc.). In game you can distinguish them when you use console commands to spawn them, blocks need the word "item" in front to be spawned while objects need the word "object".


    e.g.:
    item block 1 21
    item ramp 1 21
    object bed 1 0 <--this 0 is the variation e.g. this can be 0-10 i think for beds
    object chair 1 0

  • I took the Pepsi challenge from one of your recent change logs on 400?x fly mode, using the native system JDK (Steam java is bogus on Linux, FYI.. I know the Ubuntu 2001 edition er 12.04 runtime and all...) and a few JVM tweaks for GC management to see if I could get screen tear or stutter

    Oh, could you provide more information about that? Which JRE/JDK did you use exactly? Eventually we may replace the current JRE which is delivered with the Steam Linux version ^^


    wait wouldn't it be wiser to use the inbuilt method buffer.getShort() (i.e. blocks = buffer.getShort() ) instead of reinventing the wheel with bit shifting?

    So true :D When writing my response I was originally working with a byte array instead of a buffer, so I wanted to avoid to wrap the array into a buffer :rolleyes: But of course, if a buffer object is already available (like in this case), it d e f i n i t e l y makes sense to use the inbuilt buffer.getShort() method instead of messing around with bit shifting ^^


    I created two test cases one with a single ramp texture 21 and one with a single stair1 again texture 21 to test the block data structure.The values I get from the blueprint file are:

    Now it's getting tricky: Currently the game uses a short buffer to store the block information, both the texture and the block shape are encoded into a single short value. Basically every shape has an individual "offset" (at least an offset of 300, to keep enough room for textures). In this case, 9900 is the block shape id, while 21 is the texture.
    However, having both information encoded into a single value is crap. That's why we want to change it in the medium run (probably instead of using a single short array, we will use two byte arrays [one holding the texture id, the other one holding the shape id]).

  • thanks @red51 I now fully understood how blockdata works :D I will now run a few test cases to determine the unique identifiers for each type of block.
    When you decide to change the blueprint file format I would appreciate if you could include the changes in the changelog or post them somewhere on this forum.


    Edit: I forgot to also ask, is the typeid of each object the one I find in the definitions.db database in the game files?
    i.e.:
    1 rocksmall1
    2 rocksmall2
    3 tent
    4 table
    5 chair
    6 shelf
    7 bed
    8 piano
    9 workbench


    10 torch
    etc.

  • Oh, could you provide more information about that? Which JRE/JDK did you use exactly? Eventually we may replace the current JRE which is delivered with the Steam Linux version ^^


    See edit at bottom


    So I've actually tested this game enough to ask for QC title. On Arch Linux ( the plain ole shoot yourself in the foot 5X then it runs for the next 10 years, Arch ) rolling release, 64bit,
    currently on 4.10.10, but I have I think 2 kernel updates need to compile. I'm either the best Linux tester for you or the worst. Best b/c I know what info you're looking for.
    Worst b/c on a rolling release I get updates within hours of them being available (Ubuntu might be 2 years.. not a dis, just facts, people :) So in a way it's like someone
    futureproofing your code so long as it doesn't break before 50% of your Linux users catch up on libraries, etc. Ok, sorry JRE/JDK:


    2017 JDK: (relevant timeline since I've played) Arch 64bit
    ===============================================



    [2016-11-04] installed jdk (8u112-1) < I switch between these two. Probably 80-90% Oracle Java, but when testing
    [2017-04-22] installed jdk8-openjdk-jetbrains (8.u112.b783.1-1) < JVM features, I would usually go test on both and they are 99% compatable I think.
    + The Oracle installs are binary install, while I compile the patched OpenJDK.
    * Also on the laptop is Oracle early access 9 (snapshot), but obviously doesn't run RW.


    I'll also probably be filing a but report tomorrow or Monday when I get a chance. My CPU usage went up with the latest release (why I was delayed reporting back here -- trying to figure out what it was before I blessed any given JDK... ) I've seemed to narrow it down to libfmod, but will need to install previous build to confirm. If there is something you can shoot back one line here, like "YEAH, we had a fmod update" that would make me feel better otherwise I'll gather some logs and such and let you grep your way through them. ?(



    2017 JDK: (relevant timeline since I've played) Arch 64bit [ host ] Windows XP 32bit, Windows Vista 64bit, Windows 7 64bit [ guests in Wine software]
    ======================================================================================================================
    Before you ask -- it was to get some screenshots and test some setting for our server. I maintain a performance guide and it's tough getting people with time or give a s* to test config parameters like a proper group of Linux users would : ) JK Anyways, I ran all the above clients in Wine, so not quite the same as real Windows, but it was the RW Windows build, no
    problem. Actually quite well.. Vista seems to be the best about 90% performance of native host. They were all tested using the Windows / Steam JRE/JDK. I wasn't about to try to install
    java on a guest without a real VM in between. That just seems like a recipe for disaster : /


    Probably more than you wanted, but that's it for now. I'll get you more details on possible regression from update, but I want to test the previous build first before I "cry wolf".***see edit


    Thanks @red51


    Edit 4/23


    I did some more testing with the current version and found that of all things the FOV under View Adjustments made a huge difference going from 1.00 to 0.90. Obviously with less objects to draw, there was a noticeable increase in FPS, which didn't necessarily help the CPU usage (around 30%, 120-150 FPS). After adding vsync to bring it down (60 FPS), several benefits were immediately realized:

    • CPU usage dropped from 30% to 20% (previous release was around 15-18%, but will confirm)
    • CPU temp dropped from 71C to 57C (19% decrease) due to freq. decrease from turbo @3.4GHz to @2.8 GHz, which is about the base freq.

    While I enjoy 1.0 FOV, I'll be using 0.90 for now.

    Edited once, last by Steve: Updated for other findings re: bug ().

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!