[Tool] FTL Ship Editor: Superluminal [NOT UPDATED TO AE]

[kartoFlane]

On a side note: you should add

Code: Select all

<weaponSlots>4</weaponSlots>
	<droneSlots>3</droneSlots>

to enemy ships when it exports, since it doesnt do it at the moment. Is just a little bit annoying to add it manually afterward.

Huh. I see I left this out for enemy ships... I'm not entirely sure whether these tags affect enemy ships -- in autoBlueprints.xml, none of the default ships have them.

[Metzelmax]

I can guarantee that that it affects them. made a ship with 3 weapons and 6 drone slots.

[ApexMods]

First post. Hi, everyone! Nice place you got here.

Dropping in to say a big thanks to kartoFlane for his indispensable ship editor, and also to report that I cannot get the latest version (download says 13-08-20, app says 13-08-21) to launch on my Mac. The previous one (13-07-11) works just fine, but the new release just drops a message into debug.log and exits:

Code: Select all

Exception in thread "main" java.lang.NullPointerException
	at com.kartoflane.superluminal.core.Main.getRealArch(Main.java:4516)
	at com.kartoflane.superluminal.core.Main.main(Main.java:405)

Both versions are "x64" and I'm running the latest Java runtime:

Code: Select all

java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

Any help would be very much appreciated. Thanks!

[Vhati]

I cannot get the latest version [...] to launch on my Mac.

Code: Select all

Exception in thread "main" java.lang.NullPointerException
	at com.kartoflane.superluminal.core.Main.getRealArch(Main.java:4516)
	at com.kartoflane.superluminal.core.Main.main(Main.java:405)

The getRealArch() code is trying to determine whether your OS is 64bit...
But it's doing so in a Windows-specific way.
On non-Windows systems like yours, it's looking for hints that don't exist (and wouldn't be relevant if they did exist).

@kartoFlane:

Be warned: that environment variable test is only good for Windows.

Told ya!

[kartoFlane]

Be warned: that environment variable test is only good for Windows.

Told ya!

D'oh.

Well, I brought it onto myself, since apparently I'm a moron and can't read:

But 64 bit Windows platforms will lie to the JVM if it is a 32 bit JVM. Actually 64 bit Windows will lie to any 32 bit process about the environment to help old 32 bit programs work properly on a 64 bit OS.

I'm going to make an assumption that os.arch returns correctly on 64 Mac and Linux...

Either way, I've fixed the problem.

Also got a new update ready, changelog:

• Fixed:
  • Fixed an issue with weapon mounts sometimes having incorrect positions when their assigned weapon was changed.
  • Fixed an oversight in mount properties undo/redo, the other mount's index would not be redone.
  • Fixed a bug with undo/redo that would cause layout.txt to have holes in its room indexing, causing FTL to crash whenever ship was selected in hangar
  • Fixed a crash when loading/creating a new ship while an object was selected
  • Fixed a crash on Mac and Linux (?) on editor startup
• Added:
  • Added rudimentary 0x0 room editing, not thoroughly tested.
    Disabled by default, go to Edit > Enable Zero Rooms to enable.
    0x0 rooms appear as squares taking 2/3 of a grid cell.
  • Enemy ships should now correctly export weapon and drone slots

Dropbox Download Directory: Superluminal 13-08-29

[dalolorn]

Be warned: that environment variable test is only good for Windows.

Told ya!

D'oh.

Well, I brought it onto myself, since apparently I'm a moron and can't read:

But 64 bit Windows platforms will lie to the JVM if it is a 32 bit JVM. Actually 64 bit Windows will lie to any 32 bit process about the environment to help old 32 bit programs work properly on a 64 bit OS.

I'm going to make an assumption that os.arch returns correctly on 64 Mac and Linux...

Either way, I've fixed the problem.

Also got a new update ready, changelog:

• Fixed:
  • Fixed an issue with weapon mounts sometimes having incorrect positions when their assigned weapon was changed.
  • Fixed an oversight in mount properties undo/redo, the other mount's index would not be redone.
  • Fixed a bug with undo/redo that would cause layout.txt to have holes in its room indexing, causing FTL to crash whenever ship was selected in hangar
  • Fixed a crash when loading/creating a new ship while an object was selected
  • Fixed a crash on Mac and Linux (?) on editor startup
• Added:
  • Added rudimentary 0x0 room editing, not thoroughly tested.
    Disabled by default, go to Edit > Enable Zero Rooms to enable.
    0x0 rooms appear as squares taking 2/3 of a grid cell.
  • Enemy ships should now correctly export weapon and drone slots

Dropbox Download Directory: Superluminal 13-08-29

I'm going to point out that FTL wouldn't crash if its room indexing had holes unless you tried to shut down a repair drone that had attempted to travel between rooms. There may be a few other instances that I do not know about, but my own indexing errors didn't crash inside the hangar.

Either way, good update.

P.S. Next time, warn me you're going to update... this is the 2nd update I've downloaded today.

Edit: By the way, you wouldn't happen to know as to why Chrome insists that both updates are viruses? I scan them with my own AV afterwards, and the two disagree considerably.

[ApexMods]

Update works. Thanks a lot for the super-quick fix, cartoFlane!

Hope you don't mind if I voice a feature request. I'd love to see an option to auto-enumerate rooms in a pre-set order (e.g. top left to bottom right) upon export, or -preferably - edit room numbers on-the-fly during editing. I always mess up the room sequence somehow (which of course also causes doors going mental on me) and have to manually fix it all in the .txt file, which is a real pain.

Anyhow, thanks again, and keep up the excellent work!

[dalolorn]

I quickly received the following crash.log file while editing the Dominator:

Code: Select all

java.lang.NullPointerException
	at com.kartoflane.superluminal.core.Main$30.handleEvent(Main.java:2096)
	at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Display.filterEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.sendKeyEvent(Unknown Source)
	at org.eclipse.swt.widgets.Widget.wmKeyDown(Unknown Source)
	at org.eclipse.swt.widgets.Control.WM_KEYDOWN(Unknown Source)
	at org.eclipse.swt.widgets.Control.windowProc(Unknown Source)
	at org.eclipse.swt.widgets.Display.windowProc(Unknown Source)
	at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.DispatchMessage(Unknown Source)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
	at com.kartoflane.superluminal.core.Main.open(Main.java:755)
	at com.kartoflane.superluminal.core.Main.main(Main.java:423)

What could have gone wrong is beyond my understanding, however all I did was:

1. Move the shield room to match its position on the NPC.

2. Rescale the artillery room to 0x0, placing it into the shield room.

3. Attempt to relink some of the doors, as they seemed to partially act as airlocks.

4. Start deleting the doors upon finding that they all appear to be linked.

5. Press the down arrow upon finding that I am unable to scroll. Yes, I remembered while writing this post that it was the wrong thing to do.

6. Post the bug report.

Oh, and I agree - there should be a way to edit the IDs of the rooms and weapon mounts within the editor without deleting them. Gibs are of no consequence, as their ordering in the editor - and the files it outputs - is of no significance, but these two...

[kartoFlane]

I'm going to point out that FTL wouldn't crash if its room indexing had holes unless you tried to shut down a repair drone that had attempted to travel between rooms. There may be a few other instances that I do not know about, but my own indexing errors didn't crash inside the hangar.

Yeah, guess I got so used to fixing crash-causing bugs that I wrote that out of custom

P.S. Next time, warn me you're going to update... this is the 2nd update I've downloaded today.

Can't really give you a heads up if I myself do not possess that knowledge I mostly push out the updates as they're needed / when I'm done with a feature and don't have anything else on my todo list

Edit: By the way, you wouldn't happen to know as to why Chrome insists that both updates are viruses? I scan them with my own AV afterwards, and the two disagree considerably.

No idea why Chrome is acting that way, but it was reported earlier, too. Anyhow, I'd trust a full-fledged AV software more than a browser.

I quickly received the following crash.log file while editing the Dominator:

Undo/redo is going to be the death of me.
This will happen if you have no object selected and try to nudge. It's easily fixed, though.

@ApexMods
I considered that, but with the way the editor works internally, it probably won't be easy to implement that. I don't really see a need for this, either, since doors are linked automatically on export, as long as they haven't been linked manually.
Though right now doors store their link in the form of an int, which will break if the rooms' IDs are reorganized -- I'll have to change that to be an object reference to room instead...

IDs of the rooms and weapon mounts within the editor without deleting them

You can already edit IDs for mounts -- double click on one with the Selection Tool.

[kartoFlane]

Updated the release with a fix for the nudge crash. Also, doors now store their links in the form of object references -- will be less error prone.