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

[dalolorn]

Erm, help- something broke. What'd I do wrong?

https://www.dropbox.com/s/gd696pux07as310/WTF.png

Based on the discussions elsewhere about null rooms on ships causing problems I looked at my old files with new eyes, and found the problem. It seems to be a bug in SuperLuminal. I don't know all of the occasions where this will happen so here's what happened to me:

• Have a mod that works fine. For me it was Asteroid.ftl from this very site
• Import the FTL file into SuperLuminal
• Delete a room. It cannot be the last room you added. For me it was room 9 out of 18 rooms.
• Export that file as an FTL file
• Use Modman.exe to load that FTL file, see that the hull image is skewed like yours is.
• Load back into SuperLuminal, see that the hull looks okay.

To actually fix the problem, I investigated the two FTL files and found that the room I had deleted was room 9. The old FTL file has this room. The new one jumps from room 8 to room 10.

I edited the ship's TXT file (where it lists rooms and doors) to change the room number of room 18 to room 9. I then changed all references to room 18 in the doors to 9. I then moved the data for room 9 from the end of the rooms list to between rooms 8 and 10. Finally, I went into the blueprints.xml and made sure there were no references to room 18 there. It was just a hallway so there were not.

I manually zipped up this FTL file again and loaded it, and bammo, everything's fine.

From what I can tell, because room 9 is not referenced in the FTL file the game creates its own room 9 in the upper lefthand corner, and then the rest of the ship (hull, floor, shields, etc) is skewed to this new center.

kartoFlane, let me know if you need more info. I also have 3 FTL files in various states:

• Working FTL with extra room I want to delete set to "artillery" so I can find the room number.
• With that room deleted and the problem occurring
• With the problem fixed manually

I'll happily upload all 3 of those your download if you need me to.

Seeing as you linked to my post, not only has it since been determined that null rooms (a name i use for 0x0 rooms) are safe, but I should also add that upon further investigation, I found that the number of rooms matched the number of visible rooms perfectly. In other words, there was nothing wrong with that.

[kartoFlane]

I can't see how it could be any other way. The ONLY difference between Asteroid_2 and Asteroid_3 is the asteroid_2.txt file and the only difference between those files is that room 18 is changed to room 9, and 3 doors that said they connected to room 18 now say they connect to room 9. 18 isn't referenced in the xml files because it's a hallway.

I did not load asteroid_3.ftl into SuperLuminal before loading it into FTL to see that it was fine. That text file edit was all that was needed.

Well, it turns out we're both right

The undo/redo was messing with superluminal's internal room numbering. Since the room numbers were not ever updated, they were exported as-is to the .txt file.
So if you've deleted a room that wasn't the last room, and then didn't add a new room in its place, this would cause the .txt file to be left with a "hole" in its room indexing, which is the exact thing that causes the bug.

Seeing as you linked to my post, not only has it since been determined that null rooms (a name i use for 0x0 rooms) are safe, but I should also add that upon further investigation, I found that the number of rooms matched the number of visible rooms perfectly. In other words, there was nothing wrong with that.

Well, it looks like knowledge does not propagate at...
(•_•)
( •_•)>⌐■-■
(⌐■_■)
...superluminal speeds.
YEEEEAAAAAAAAHH

[5thHorseman]

Seeing as you linked to my post, not only has it since been determined that null rooms (a name i use for 0x0 rooms) are safe, but I should also add that upon further investigation, I found that the number of rooms matched the number of visible rooms perfectly. In other words, there was nothing wrong with that.

Ha! I misspoke. I didn't mean that null rooms were inherently buggy, I meant that they may be related to this bug. Now that I know it's possible to have a room that's not a room, I figured maybe it was possible that the not-room room was at 0,0 shifting the ship's center point.

"When is a room not a room?"
"When it's a jar? No wait, that doesn't work."

[Tassyr]

So, er. I'm confused. How do I fix this problem...?

[5thHorseman]

So, er. I'm confused. How do I fix this problem...?

You have two options, wait for a new version of SuperLuminal or do what I said I did in the post after yours:

I edited the ship's TXT file (where it lists rooms and doors) to change the room number of room 18 to room 9. I then changed all references to room 18 in the doors to 9. I then moved the data for room 9 from the end of the rooms list to between rooms 8 and 10. Finally, I went into the blueprints.xml and made sure there were no references to room 18 there. It was just a hallway so there were not.

I manually zipped up this FTL file again and loaded it, and bammo, everything's fine.

Obviously your room numbers will be different, but you should have a gap somewhere.

[kartoFlane]

Alright, updated the 13-08-20 release with fix for the room indexing bug.
Also made the editor capable of viewing ships with 0x0 rooms -- ie. the editor doesn't crash when you attempt to open such a ship. I have yet to implement a way to select/modify/create 0x0 rooms.

[dalolorn]

Alright, updated the 13-08-20 release with fix for the room indexing bug.
Also made the editor capable of viewing ships with 0x0 rooms -- ie. the editor doesn't crash when you attempt to open such a ship. I have yet to implement a way to select/modify/create 0x0 rooms.

Well, selecting would be easy. Make the editor display it as a mini-room.

Once that's done, modifying/creating them is a piece of cake.

[speedoflight]

Or just a room with 1x1 size but with the edges in red or something like that (which indicates the size is actually 0x0)

[dalolorn]

Or just a room with 1x1 size but with the edges in red or something like that (which indicates the size is actually 0x0)

That would likely be incompatible with Superluminal's current room size editing system.

[Metzelmax]

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.