Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nathan67003]

Mind posting screenshots to your folders? Your distro's Java version is unrelated to the one the .sh should run - if you're using CLI, you should be able to just do jre/bin/java -jar ship_editor.jar from within your Ship Editor folder.

This may also fix your issue - I'm not quite sure why the linebreaks would be like this since I wrote the .sh on Mac in .txt mode with TextEdit, but I'll likely need to fix this when I get some time to do so on my own Linux distro.

[CHK]

Sorry it took me this long t see your reply.

jre/bin/java -jar command worked for me. The editor finally opens and seems to be working better than the old one.

Thank you for your time.

[Princess of Evil]

The editor doesn't seem to play nice with `width` and `height` - very noticeable if you try to edit vanilla stations.
Also, why in the [redacted] is undo Ctrl+U?

[Ontheheavens]

The editor doesn't seem to play nice with `width` and `height` - very noticeable if you try to edit vanilla stations.

It is implicitly assumed, just like in Trylobot's editor, that the width and height dimensions will be identical to that of sprite; in other words, editing functionality for width and height is not implemented (again, like in old editor) as hardly anyone would use the feature. If you had some other width/height issue in mind, feel free to provide a visual example and steps to reproduce. If you have a reasonable use case for the additional functionality, you can share that as well and we'll see what can be done.

As for vanilla station - so far my understanding is that all of them have conventional dimensions equal to that of sprites, and I looked at said vanilla stations constantly when implementing module editing and similar stuff. What exactly was the noticeable issue?

Also, why in the [redacted] is undo Ctrl+U?

There are a number of reasons as to why the hotkey layout is not satisfactory; and I, indeed, should like to implement keybinds as they were present in the old editor, since it had a pretty comprehensive scheme. However, Swing has some pretty deeply coded functionality tied to ALT (focusing file menu), and so I was inclined to do ad-hoc solutions throughout development process. Should you have a more streamlined keybind scheme figured out (that would take into account all emergent constraints like number of editor mode tabs and so on), I would be happy to discuss it.

Edit:

If you're using CLI, you should be able to just do jre/bin/java -jar ship_editor.jar from within your Ship Editor folder.
This may also fix your issue - I'm not quite sure why the linebreaks would be like this since I wrote the .sh on Mac in .txt mode with TextEdit, but I'll likely need to fix this when I get some time to do so on my own Linux distro.

While I'm at it - thanks for providing assistance for those Linux issues!

[Princess of Evil]

It is implicitly assumed, just like in Trylobot's editor, that the width and height dimensions will be identical to that of sprite; in other words, editing functionality for width and height is not implemented (again, like in old editor) as hardly anyone would use the feature. If you had some other width/height issue in mind, feel free to provide a visual example and steps to reproduce. If you have a reasonable use case for the additional functionality, you can share that as well and we'll see what can be done.

As for vanilla station - so far my understanding is that all of them have conventional dimensions equal to that of sprites, and I looked at said vanilla stations constantly when implementing module editing and similar stuff. What exactly was the noticeable issue?

After checking it a bit more, the only station that actually has that is station1 - small lowtech. I swear i saw it somewhere else, but i guess that's the only one i can find.

There are a number of reasons as to why the hotkey layout is not satisfactory; and I, indeed, should like to implement keybinds as they were present in the old editor, since it had a pretty comprehensive scheme. However, Swing has some pretty deeply coded functionality tied to ALT (focusing file menu), and so I was inclined to do ad-hoc solutions throughout development process. Should you have a more streamlined keybind scheme figured out (that would take into account all emergent constraints like number of editor mode tabs and so on), I would be happy to discuss it.

The general undo keybind on most systems is Ctrl+Z, which has an upside of being two keys next to each other.

[Ryxsen1421]

Hi hi, I wonder if its possible to add colored background to the ship editor? It's so that it doesn't burn my eyes all the time.

EDIT: Just saw my friend checking out the ship editor with me watching his stream. It's there alright, thanks for the brand new modern ship editor! Time to migrate to the new one.

[starficz]

This ship editor is really nice. Used it a bunch on KoL. One thing though, typically I needed to manually align several ship layers with modules in each one to another layer with a parent ship, as you cannot edit the module ships themselves when loading a variant data. when loading a variant data could you put an option to also load the module ship on separate layers in the correct place in global coordinates? It would save me from having to manually pixel line them up every time.

[Ontheheavens]

Hi hi, I wonder if its possible to add colored background to the ship editor? It's so that it doesn't burn my eyes all the time.

EDIT: Just saw my friend checking out the ship editor with me watching his stream. It's there alright, thanks for the brand new modern ship editor! Time to migrate to the new one.

Yes, there are options for color and checkered background, which can be combined together. Thanks.

This ship editor is really nice. Used it a bunch on KoL. One thing though, typically I needed to manually align several ship layers with modules in each one to another layer with a parent ship, as you cannot edit the module ships themselves when loading a variant data. when loading a variant data could you put an option to also load the module ship on separate layers in the correct place in global coordinates? It would save me from having to manually pixel line them up every time.

That's a comprehensive suggestion, thanks. Updated to v0.7.6:

• Options for quick module-to-layer loading: both selective from module list right-click option and bulk loading through button widget.
• Fast layer selection, handy when working with dozens of layers: hold ALT and move mouse to select closest layer to mouse point (compared by layer sprite center point).
• Performance tweaks.

Module to layer widgets, background options

[close]

Edit: should you already have the editor on your machine, it is possible to just swap the JAR and peruse the new additions.

Edit 2: might as well revisit the hotkey issue:

]
After checking it a bit more, the only station that actually has that is station1 - small lowtech. I swear i saw it somewhere else, but i guess that's the only one i can find.

I looked into the custom width/height stuff - it would be a sizable bit of effort to try and accomodate this feature. Considering that Alex himself doesn't seem to use this, and hardly anyone in community does (you can just modify the sprite itself, right?), I don't think benefits justify the development effort here. For what it's worth, I would be willing to consider incoming pull requests should someone write the implementation, but I won't be working on it myself.

]
The general undo keybind on most systems is Ctrl+Z, which has an upside of being two keys next to each other.

After fiddling a bit and comparing behaviour with the Trylobot's editor, I figured out some wonkyness from ALT's focus behaviour does not outweigh benefits of old streamlined scheme.

Just went ahead and realigned hotkey arrangement: undo/redo is CTRL-Z/CTRL-X, layer drag/rotate is middle mouse button with SHIFT/CTRL, various instrument action hotkeys now only use SHIFT/CTRL/ALT and mouse buttons and gestures, while keyboard buttons like C, S, B and so on are now used with ALT to quickly switch between instrument tabs.

I shouldn't like to release another update with a change so trifling, so anyone wishing to test this has to swap the JAR: https://github.com/Ontheheavens/Ship-Editor/blob/master/ship_editor.jar

Feel free to post your feedback and suggestions. Thanks.

[nathan67003]

Edit: should you already have the editor on your machine, it is possible to just swap the JAR and peruse the new additions.

Would probably be a nice QoL thing to have this spelled out in the release descriptions on GitHub as well as a link (or something) directly to the .jar as a standalone download in said release. A very minor thing, admittedly but when the changes are very minor, knowing you just have to swap out the .jar definitely makes me update immediately if I'm not in the middle of a large project.

[SirSmoustache]

Hey I don't know if I'm just a little dense or smth, but is it possible to load sprites from the /mod folder? Everytime I try to do that I got an error saying its not part of the game's folder. Runnin it in a Mac if that helps with troubleshooting.

[starficz]

When Selecting weapon slots, the data seems to be the last selected slot, and not the current selected slot.
Also, Renaming Wepaon slots will alwayd append a 000 number to the end for some reason.

[nathan67003]

Hey I don't know if I'm just a little dense or smth, but is it possible to load sprites from the /mod folder? Everytime I try to do that I got an error saying its not part of the game's folder. Runnin it in a Mac if that helps with troubleshooting.

Completely missed this. Can you go into your problem in greater, step-by-step detail of what isn't behaving as expected?

[Ontheheavens]

Wasn't paying attention to Starsector stuff lately - sorry about that!

Edit: should you already have the editor on your machine, it is possible to just swap the JAR and peruse the new additions.

Would probably be a nice QoL thing to have this spelled out in the release descriptions on GitHub as well as a link (or something) directly to the .jar as a standalone download in said release. A very minor thing, admittedly but when the changes are very minor, knowing you just have to swap out the .jar definitely makes me update immediately if I'm not in the middle of a large project.

Noted, thanks!

Hey I don't know if I'm just a little dense or smth, but is it possible to load sprites from the /mod folder? Everytime I try to do that I got an error saying its not part of the game's folder. Runnin it in a Mac if that helps with troubleshooting.

One way this could transpire is if you were trying to load a sprite directly from Starsector.app/mods folder.

This was originally a design decision - since sprite path values are defined in ship files as, say "graphics\ships\aurora\aurora.png", loading a sprite from root mod folder will (theoretically) result in a path value that will be erroneous. This is because game searches for sprites by appending sprite path name, first to a core data folder, then to all mod data folders. I understand that sometimes you just want to test some sprite outside of any of those packages, maybe even from desktop - so I added a toggle to turn this error message off and load sprites from anywhere you want. Toggle it from a main menu bar under new "Settings" submenu.

Relevant code:

Code

// From oth.shipeditor.parsing.loading.OpenSpriteAction.java

    public static void openSpriteAndDo(Consumer<Sprite> action) {
        JFileChooser spriteChooser = FileUtilities.getImageChooser();

        int returnVal = spriteChooser.showOpenDialog(null);
        FileUtilities.setLastSpriteDirectory(spriteChooser.getCurrentDirectory());

        if (returnVal != JFileChooser.APPROVE_OPTION) {
            log.info(FileUtilities.OPEN_COMMAND_CANCELLED_BY_USER);
            return;
        }

        File file = spriteChooser.getSelectedFile();

        boolean loadingFromAnywhere = SettingsManager.isLoadingSpritesFromAnywhereEnabled();
        if (FileUtilities.isFileWithinGamePackages(file) || loadingFromAnywhere) {
            Sprite sprite = FileLoading.loadSprite(file);
            action.accept(sprite);
        } else {
            log.error("Selected file is outside of any game packages. Image loading aborted.");
            JOptionPane.showMessageDialog(null,
                    "Selected image is outside of any game packages: " + file,
                    StringValues.FILE_LOADING_ERROR,
                    JOptionPane.ERROR_MESSAGE);
        }
    }

[close]

When Selecting weapon slots, the data seems to be the last selected slot, and not the current selected slot.

I'm not really sure I understand - on my end I don't see any such behaviour, slots are getting selected as expected. Could you provide steps to reproduce?

Also, Renaming Wepaon slots will alwayd append a 000 number to the end for some reason.

Right, that's another (maybe shortsighted) design decision. Added a checkbox to turn numeric suffixes for weapon slots off - right above ID text field.

Updated JAR is at the usual place - should be good to go with a simple swap (worst case, you'll need to fiddle with your editor settings file because of new options):

https://github.com/Ontheheavens/Ship-Editor/blob/master/ship_editor.jar

Thank you everyone for your feedback.

[starficz]

When Selecting weapon slots, the data seems to be the last selected slot, and not the current selected slot.

I'm not really sure I understand - on my end I don't see any such behaviour, slots are getting selected as expected. Could you provide steps to reproduce?

https://imgur.com/a/2q3Iqxk

[Ontheheavens]

Quotes

When Selecting weapon slots, the data seems to be the last selected slot, and not the current selected slot.

I'm not really sure I understand - on my end I don't see any such behaviour, slots are getting selected as expected. Could you provide steps to reproduce?

[close]

https://imgur.com/a/2q3Iqxk

Thanks for the visual (I only tested viewer space for selection, didn't thought to check slot list as well...), fixed:

https://github.com/Ontheheavens/Ship-Editor/commit/6394f9341a4f09fd4b1fb582ad8bf693b4243525

The JAR can be swapped for updated version:

https://github.com/Ontheheavens/Ship-Editor/blob/master/ship_editor.jar