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

[kartoFlane]

That's odd. They're all loading perfectly fine for me :/ I did mess a bit with regexps used to load the files, but they should load fine, as long as you don't put some random garbage inside the xml tags.

Also, thanks for the suggestions; will look into it. They're all feasible, but some of them would require me to completely rewrite existing code, and I'm not really up for that. To answer some:

Some way of telling which weapon mount corresponds to which slot.
They're basically linked in the following matter: first mount declared/created corresponds to the first weapon on the list. Guess I'll just add numbers hovering over mount to indicate their index.

Possibly the ability to select more than one element at once by ctrl-clicking, so you can move things around easier?
Sadly, that would require me to rewrite the entire selection system from scratch, and for a rather situational functionality. Doubt I'll ever do that.

The ability to set enemy ships' shields, weapons and engines to a maximum of 10, which happens sometimes in vanilla.
I've never ever encountered an enemy ship with a level 10 system :o It's not too hard, gotta make a restriction for enemy ships only, though.

The ability to uncheck "available at start" for systems on enemy ships (so that not all of them will have that system).
Well, this flag only affects player ships, that's why it's disabled for enemy ships. For enemy ships, if you don't want them to have a system available, you simply remove that system from the ship (so that it has no room assigned). There's no way to make enemy ships gain systems as the game progresses, at least none that I know of.

Being able to change the shield graphic on loading enemy ships; at the moment you have to place a room and then delete it before the button is available
Oh well, that's a bug. Generally I didn't intend for enemy ship's shields to be changeable. Don't think it's even possible to do that, i.e. it won't affect the enemy ship in-game (it'll default to normal shields). Gonna test that.

Make the Auto-Scout appear on the enemy ships list - it appears to be missing at the moment.
Auto-Scout is the AUTO_BASIC ship... If it's not loading for you, then something must be wrong with your blueprint files :S

And don't be sorry about the wall of text - this is great feedback, and it's exactly what I want and need to make this program better.

[Tweevle]

Hmm, weird, I don't recall doing anything to my files that'd have that effect. Do you think you could upload your autoBlueprints.xml so I could make sure it's not me somehow breaking it? That goes for the missing Auto Scout as well.

Guess I'll just add numbers hovering over mount to indicate their index.
That's pretty much what I meant, thanks! As is it's okay if you're making a ship from scratch, but if you load a premade ship or one you made a while ago it'd be difficult to figure out which one is which.

Sadly, that would require me to rewrite the entire selection system from scratch, and for a rather situational functionality. Doubt I'll ever do that.
That's all right! I thought it'd be a bit of a hassle and it's not really vital in this case.

I've never ever encountered an enemy ship with a level 10 system :o
I don't think I have either, but IIRC the Auto-Assault can have level 10 shields, although it's rare to see it. It's worth including the option, anyway.

Well, this flag only affects player ships, that's why it's disabled for enemy ships.
I'm pretty sure it does affect enemy ships - the start="false" modifier is on a lot of enemy ships' systems, and I believe it has an effect ingame. For instance, the Rock Scout sometimes has a Medbay and sometimes doesn't. They don't use start="true" on the others, though, for some reason.

Oh well, that's a bug. Generally I didn't intend for enemy ship's shields to be changeable. Don't think it's even possible to do that, i.e. it won't affect the enemy ship in-game (it'll default to normal shields). Gonna test that.
Ah, fair enough, that makes sense. Although on a related note, if I create a new enemy ship the shield graphic won't load at all, even if I browse for the normal shields.

Glad to help! :3

[Lord0fHam]

I have a mac and whenever I try to open the jar files it just says they can't be launched. I am sure I have the newest verion of java. What do I do?

[kartoFlane]

Well, I've no idea about macs, as I've said earlier... Do you get any specific message, anything you could plug into google and find a solution?
Also, take a look at this, first answer: try to open the console app for mac and then run the jar file, maybe some more information can be gathered this way.
Another thing is that, from what I've read, most macs have Java 5 installed, where Superluminal was compiled with Java 7, but I guess you already took care of that.

[Vhati]

Keep up the good work. And why apologize for doing it in Java?

I just have this deeply ingrained opinion that Java is generally a bad language to develop, well, pretty much anything, due to its rumored inefficiency :E

It's generally not a good idea to form deeply ingrained opinions based on rumor.

Article: Wikipedia - Java Performance

Java is often Just-in-time compiled at runtime by the Java Virtual Machine, but may also be compiled ahead-of-time, just like C++. When Just-in-time compiled, its performance is generally:
- slower than compiled languages such as C or C++,
- similar to other Just-in-time compiled languages such as C#,
- much faster than languages without an effective native-code compiler (JIT or AOT), such as Perl, Ruby, PHP and Python.

[Program speed] is in some cases equal to C++ on low-level and numeric benchmarks.
[...]
Results for microbenchmarks between Java and C++ highly depend on which operations are compared. For example, when comparing with Java 5.0:
- 32 and 64 bits arithmetics operations, File I/O and Exception handling, have a similar performance to comparable C++ programs
- Arrays operations performance are better in C.
- Trigonometric functions performance is much better in C.

But bad design (like excessive I/O, graphics caches that don't free their resources, bogging down the GUI thread with long tasks or floods of intensive events, nagging calls to low-level libs outside the VM, etc) is much more likely to cause inefficiency bad enough to worry about than the choice of compiler/runtime.

[Vhati]

if there happens to be someone with experience in regards to drawing 2d stuff with java, I'd appreciate any input on the matter, as I'm fairly certain using Canvas class to do all the drawing is a bad idea

I'm a Swing dev, but strategies should translate:

-- Draw complex static things onto buffered images. Bake the drawn graphics into reusable objects you can rubber stamp onto the screen when painting is required.

-- Delegate drawing to regional objects, which each receive repaint events only when they are obscured. Swing does this with custom JComponents that override paintComponent(Graphics g) to draw. When you paint on a timer, you're wasting cycles drawing what's already there.

For instance, every room's floor is a rectangular region that paints itself. Every system icon is another region that draws itself. And these objects' painting methods are called back-to-front: floors first, then icons, etc.

Worst case, you can roll your own paintable-rectangle classes and test whether they contain the dirty area described by the PaintEvent your listener's getting.

-- Avoid recalculating things and allocating new objects. Like in FTLShip, have a boundsUpdated() func that loop-searches for high/low bounds and stashes the point objects in private members of the class (update when you've done something you know might change them), and let findLowBounds() just return the low point as needed.

Given how few rooms a ship has, that example's over-optimizing a bit, but you get the idea. Paint methods get called a lot, so remove as much non-graphics logic from each call as you can.

[kartoFlane]

I've skimmed my code again and it seems like I'll have some rewriting to do... That said, many thanks for taking a look and commenting on it!
I have some more questions, if you don't mind; I don't want to spam the topic though, I'll send them over a PM.

[Tweevle]

@OP: Thanks for sending me your xmls! It works now - however when I ran my autoBlueprints next to yours in text-compare.com there are a lot of differences, and I definitely didn't make them myself (this includes the addition of start="false" to enemy ships mentioned before). It might be because I have it on Steam and so it auto-updates to the latest version? If this is the case it might be a good idea to make the ship editor work properly with that. (I have v. 1.03.1. according to the main menu screen.)

[shark]

Keep up the good work. And why apologize for doing it in Java?

I just have this deeply ingrained opinion that Java is generally a bad language to develop, well, pretty much anything, due to its rumored inefficiency :E

It's generally not a good idea to form deeply ingrained opinions based on rumor.

We all know that 'rumor' was spread by "programmers that do their own laundry and take out their own garbage".
It is mainly pointed at the GC being somewhat inefficient. Yet all those C++ programmers seem to forget the bloating created by standard templates...

But bad design (like excessive I/O, graphics caches that don't free their resources, bogging down the GUI thread with long tasks or floods of intensive events, nagging calls to low-level libs outside the VM, etc) is much more likely to cause inefficiency bad enough to worry about than the choice of compiler/runtime.

Whoever says C is faster than Java is free to use JNI to speed up Java.
But there's one thing Java does better than all C incarnations - it severly reduces development time. The performance tradeoffs are justified by the huuuuge standard library compared to C.

just my 2c, being an embedded programmer, working with both, and having these kind of talks on a daily basis...

The choice of language will not impede anything you try to do - it will just offer idiomic approaches; just because Java favors OOP doesn't mean you can't make a bloat class with a main()-like in it. Just because C favors prodecural programming doesn't mean you can't make brilliant classes inside of a simple struct. Peeking at kernel code reveals very decent OO approaches with pure C. So all of these are moot points. In the end, Java runs on top of C, and there's no changing that.

[boa13]

This is getting quite off-topic. Two small corrections:

- Java (at least the Sun/Oracle implementation) is written in C++
- Java (at least the Sun/Oracle implementation) emits assembly language, the crucial parts of your code do not necessarily run "on top of" another language.

But apart from that, I agree with you.