SMEdit Situation

[Tomino_sama]

So then Who wants to talk about Smedit? I'm still here. but one click away.

references:
SMedit Guides / Tutorials / How To's
https://www.youtube.com/playlist?list=PL1i3gbuaciUWWqarfLq6LIr4pKpxVZmEM

I am eager to get busy. We are adding members to our team all the time :D

 

[schema]

if it helps, here is new new format of chunks (segments). the total size is still 3 byte. the indices refer to bits. the "start" is inclusive, the "end" is exclusive:

  public static final int typeIndexStart = 0;

   public static final int typeIndexEnd = 11; //11 bits -> 2048 (0 incl)

   public static final int hitpointsIndexStart = 11; //8 bits -> 256

   public static final int hitpointsIndexEnd = 19;
   public static final int activeIndexStart = 19; //1 bit -> 1

   public static final int activeIndexEnd = 20;

   public static final int orientationStart = 20; //4 bit -> 16
   public static final int orientationEnd = 24;

there is also a new method to read segment headers, as they now are versioned:

this version data is a byte at the front of the header. Before the frist byte was part of the timestamp of type long. Because timestamps never have the sign bit set (they are never negative), I can determine with a trick if the segment is an old version. If the first byte of the segment-header has its sign bit set (is negative), then the segment is versioned, and the
version = -firstByte;

Otherwise it's an unversioned (old game-version segment), and can be marked to migrated into the new system. Therefore segment version in the header is saved as a negative byte.

I hope this information helps.

 

[Tomino_sama]

if it helps, here is new new format of chunks (segments). the total size is still 3 byte. the indices refer to bits. the "start" is inclusive, the "end" is exclusive:

public static final int typeIndexStart = 0;

public static final int typeIndexEnd = 11; //11 bits -> 2048 (0 incl)

public static final int hitpointsIndexStart = 11; //8 bits -> 256

public static final int hitpointsIndexEnd = 19;
public static final int activeIndexStart = 19; //1 bit -> 1

public static final int activeIndexEnd = 20;

public static final int orientationStart = 20; //4 bit -> 16
public static final int orientationEnd = 24;


there is also a new method to read segment headers, as they now are versioned:

this version data is a byte at the front of the header. Before the frist byte was part of the timestamp of type long. Because timestamps never have the sign bit set (they are never negative), I can determine with a trick if the segment is an old version. If the first byte of the segment-header has its sign bit set (is negative), then the segment is versioned, and the
version = -firstByte;

Otherwise it's an unversioned (old game-version segment), and can be marked to migrated into the new system. Therefore segment version in the header is saved as a negative byte.

I hope this information helps.

Thanks so much Schema! I really hope this can help us all to get this updated now :D Jo told me it is fully up for us to maintain. He did say he was not abandoning SMedit, but that he was happy for anyone to carry on the work.

I look up at that reply and see the keys we need.

Come on Guys! let's get this done!

I'll offer to host the Tool if there is no available alternative to for the release :D

 

[Bobby Bighoof]

I have SMEdit loading on the new game file, all the blocks ids and other block info already input. All the changes for file locations and what not. Now to take the new info on this topic and see what I can do to get all the other info up and running. So still need to do a check over for Header, Logic, Meta, ents and chunks just to be on the safe side)

Thank You Schema for providing this information I have been looking around to see if maybe you had provided it to us somewhere. SO glad we could finally get it.

anyways for those who are interested yes just a few steps away. I will keep all informed of my progress. (lol I wasn't going to do it but I just got bored waiting to see if some one else was interested in doing this.)

 

[Kovu]

I have been an active Supporter of Smedit since i started last summer. I was going to look into this (updating for basic functionality) although I am not experienced with how this is written, I spoke with Jo many times throughout these past months promoting the tool both independantly and pro-actively. I am eager to see this completed, I would be eager to retain my involvement to that capacity.

If any of you have already organised, Please get in touch on [email protected]

I am looking to provide support to a coding team that might work on updating this Tool. I can offer all the documenting as in news coverage, blog posts, social media shares and other promotional videos for the Tool. As I have already there would be tutorials on installation, use and basic troubleshooting.

I run weekly showcases on Smedit Builds in the Hall of Smedit Feature. I invite those people to join us at the Lineup Review each week.


If you don't know me, please check out our Starmade Community :D

I have not heard of you, likely because I don't follow much in starmade clans and such. I'll PM you if I need some more help, but UltimateBudgie and I should be good for now.

 

[Bobby Bighoof]

In

 

[Tomino_sama]

I have not heard of you, likely because I don't follow much in starmade clans and such. I'll PM you if I need some more help, but UltimateBudgie and I should be good for now.

You did click the link right?

I did the XML script for people to convert from Minecraft. I did all the tutorials and so on. I don't want to intefere with your Coding process.

If you have not heard of us I suggest clicking. we are not a Clan. I even put links in my Signature to make it easy for people....

 

[Tomino_sama]

In looking at the Smedit source I realized that without too much of a rewrite there was 2 options #1) remove SMEdits's abilty to work with older blueprints, and #2) take quite a bit of time to look at how this code was first realized and written and add in a whole bunch of "else" statements to allow for multiple type file look ups for the file changes that have been made to the game. (I will do this but first we need a quick fix to keep us on the right track here.)

So I am putting out a quick fix file to help people to still be able to work with older blueprints that they already have in their files, and then I will do the complete change over as soon as I get a chance.

Here is a quick fix for those looking to work with the SMEdit program in their updated game file.
This will have the updated blocks in the plugins but will not work with the new blocks.

This is only to work with pre game version 0.1 blueprints. This will not work with blueprints made using the game after the 0.1 game patch . This does show the new blocks in the plugin lists but will not render them and if you put them in your project and save it then that file will not work in either the old version or the new version of the game. So only use this to modify old blueprints.

You can edit older blueprints and save them for the updated game to convert as it uses them.

simply click on the link and run the now "SMEdit_Classic" jar from below

The file is in a zip

SMEdit_Classic.zip

Good Job Bro! Glad to finally see someone being proactive :D

testing it now.

 

[Bobby Bighoof]

Good Job Bro! Glad to finally see someone being proactive :D

testing it now.

OK I will post again you will need the latest version of Java JRE 8. lol got it running on multiple computers now XD

 

[Bobby Bighoof]

You can download This quick hot fix for SMEdit.

I have set it to load and run on the new game code, but here is the catch for now;

You can only open and edit older blueprints and not use any of the new block features in the program.

The program will edit old blueprints like it did before and save them in the old blueprint format for the game to convert when the ships are bought in the game.

The only side note to this is you will have to have "Java JRE 8" installed this will only work on a computer with JRE 8 (yes I am up to date and if you want to run up to date then you should be running completely up to date) so go download and install Java JRE 8)

Here is the link to download JRE 8 link below

JRE 8

AND

Here is the zip file to download for SMEdit_classic just click on the link below

SMEdit_classic.zip

 

[der_scheme]

(yes I am up to date and if you want to run up to date then you should be running completely up to date) so go download and install Java JRE 8)

So, which Java8 features do you use exactly?

Another topic: From your earlier post (don't know why you deleted its contents):

take quite a bit of time to look at how this code was first realized and written and add in a whole bunch of "else" statements to allow for multiple type file look ups for the file changes that have been made to the game

Why would you need that? Here's an example of Ruby code that shows how you can easily support multiple versions (this is for reading, but writing would be equally trivial).

      File.open(file) do |f|
        # http://www.starmadewiki.com/wiki/File_format#Ship_Files_.28.smd2.29
        file_size = f.size
        $logger.debug "file size: #{file_size}" if $logger

        # Read file format.
        file_format = f.read_i32
        $logger.debug "file format: #{file_format}" if $logger

        # Raise an error if we encounter an unsupported file format version
        unless (0..1).include? file_format
          fail IOError, "unknown file format: #{file_format}"
        end

        # Set some values that we need later
        initial_offset = 65540
        chunk_size = 5120

        active_index = 20
        active_mask = 1
        hp_index = 11
        hp_mask = 0x1ff
        id_index = 0
        id_mask = 0x7ff
        orient_index = 21
        orient_mask = 0x7

        # Change the above values according to the file format
        if file_format == 1
          initial_offset = 65541
          active_index = 19
          hp_mask = 0xff
          orient_index = 20
          orient_mask = 0xf
        end

        # Read chunks.
        (initial_offset...file_size).step(chunk_size) do |offset|
          f.seek offset
          # Rest is trivial. Use the variables above to read stuff
        end
      end

Just use variables for everything and set them according to the format version number.

Note: I believe the HP mask was wrong. Don't know why. Should be correct now.

 

[Bobby Bighoof]

So, which Java8 features do you use exactly?

Another topic: From your earlier post (don't know why you deleted its contents):

Why would you need that? Here's an example of Ruby code that shows how you can easily support multiple versions (this is for reading, but writing would be equally trivial).

      File.open(file) do |f|
        # http://www.starmadewiki.com/wiki/File_format#Ship_Files_.28.smd2.29
        file_size = f.size
        $logger.debug "file size: #{file_size}" if $logger

        # Read file format.
        file_format = f.read_i32
        $logger.debug "file format: #{file_format}" if $logger

        # Raise an error if we encounter an unsupported file format version
        unless (0..1).include? file_format
          fail IOError, "unknown file format: #{file_format}"
        end

        # Set some values that we need later
        initial_offset = 65540
        chunk_size = 5120

        active_index = 20
        active_mask = 1
        hp_index = 11
        hp_mask = 0xff
        id_index = 0
        id_mask = 0x7ff
        orient_index = 21
        orient_mask = 0x7

        # Change the above values according to the file format
        if file_format == 1
          initial_offset = 65541
          active_index = 19
          hp_mask = 0x7f
          orient_index = 20
          orient_mask = 0xf
        end

        # Read chunks.
        (initial_offset...file_size).step(chunk_size) do |offset|
          f.seek offset
          # Rest is trivial. Use the variables above to read stuff
        end
      end

Just use variables for everything and set them according to the format version number.

JRE 8 is the java JDK and JRE pack I am running and supporting over 7 that has already had too many flaws, holes, and backdoors for us in the past. No other real reason I didn't convert any of the code to JRE 8 standards (not at this time, but it is on the drawing board)

last post got removed do to lack of pre testing before offering the "SMEdit_Classic" file. More solid testing has been done now. Helps when you got those who support to help out. So with that being said here we are now.

I thank you greatly for the sample code and will absolutely take it into account when considering all the ifs, and, or, elses', and what not that has to be now applied to the existing SMEdit 's file read and write source.

 

[NeonSturm]

I see no reason why we should not be allowed to edit hull surfaces as rgb-channels image with common graphic software tools, just the rgb color actually being a block.

He could overhaul the system and use a hex value to determine the colour, but that would greatly increase the number of calculations performed because I think you would have to add 24 extra bits of data to every block.

Actually not. I was saying that you can draw all colors which are available via a block. Grey, Black, White, RGB, Yellow, Orange, Brown, ... and maybe 3-4 ship specific colors (16 in total) which would just switch some bits in the block-IDs of basic and hardened hulls.

 

[Bobby Bighoof]

This has been updated to now be compatible with JRE7

Here is the link

SMEdit_Classic.zip

 

[Exarchian]

I just got this app and am having a bit of an issue with it. I dont have any color choices, they are all gray, how do l fix this?

 

[Exarchian]

I still have an issue with not having any color choices. Can anyone advise?