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

[kartoFlane]

@Greensburg
Look here, it's an issue with GMM. .ftl packages with missing/wrong elements can't really bug GMM in any way.

@speedoflight
0-360, can be negative. 0 is equivalent to a clock's arrow at 12. Look at JLPH's spreadsheet for more details.
And I've no idea why the values you've pasted here have over 10 points of decimal precision, I've fixed that to 2 decimal places some time ago. Unless you've pasted this from an older ship...

[Greensburg]

Thanks! That solved most of the issues.

[speedoflight]

@speedoflight
0-360, can be negative. 0 is equivalent to a clock's arrow at 12. Look at JLPH's spreadsheet for more details.
And I've no idea why the values you've pasted here have over 10 points of decimal precision, I've fixed that to 2 decimal places some time ago. Unless you've pasted this from an older ship...

Yea, so i was right. So, any ideas why those values are not working?

About the 10 digits, i picked a template from the original game, they are 10 digit numbers.. i was just trying to do it manually..

JLPH's spreadsheet doesnt help, since i want to know why the values i am using doesnt work as intended. Already know how the values work, it is just they dont..

[SuicidalPencil]

Having an issue patching a ship (The Kestrel) in. Here's the error:

2013-04-07 18:24:26 INFO: Installing mod: Kestrel Cruiser.ftl
2013-04-07 18:24:40 ERROR: character mapping must return integer, None or unicode
Traceback (most recent call last):
File "C:\Users\Suicidal Pencil\Desktop\ftl\FTL\Grognaks Mod Manager v1.7 Win32\lib\killable_threading.py", line 99, in run
result = self._payload(*self._payload_args, **self._payload_kwargs)
File "C:\Users\Suicidal Pencil\Desktop\ftl\FTL\Grognaks Mod Manager v1.7 Win32\main.py", line 823, in patch_dats
mod_zip.extract(item, tmp)
File "C:\Python27\lib\zipfile.py", line 1024, in extract
return self._extract_member(member, path, pwd)
File "C:\Python27\lib\zipfile.py", line 1057, in _extract_member
arcname = arcname.translate(table)
TypeError: character mapping must return integer, None or unicode
2013-04-07 18:24:40 INFO:
2013-04-07 18:24:40 INFO: Patching failed.
2013-04-07 18:24:44 INFO:
2013-04-07 18:24:44 INFO: Quitting... (ctrl-break to be rude)
2013-04-07 18:24:44 INFO:
2013-04-07 18:24:45 INFO: Bye

I've tried a complete reinstall but nothing changed. Other mods patch fine. Assistance would be appreciated
This is a dl link to the .ftl in question

[kartoFlane]

Huh. I doubt it was caused by the editor itself, though that "character mapping must return integer" is bugging me a bit... Though all the editor is doing is writing out simple words - there's second to none room for error in this regard. Of course, there's always a chance that some sort of encoding error occured during exporting, but it is very unlikely.
Try loading the ship from the .ftl in Superluminal - if it works, then it's an issue with GMM.

[SuicidalPencil]

I can confirm that the .ftl file loads fine in the editor. I'll be making a post with the error in the GMM thread, and will be tweaking the design to see if I can nail down what's causing the issue.

Thanks for the quick response

edit: The post has been made. It's just a copy-paste of my above post ('cause I'm lazy like that )

[SuicidalPencil]

The issue isn't with Superluminal or GMM, but with the 2.7.4 Python distribution. Dropped to 2.7.3 and it patched perfectly.

The ship editor is awesome, very well done

[Vhati]

Of course, there's always a chance that some sort of encoding error occured during exporting, but it is very unlikely.

Here's my responce in the GMM thread.

• Somehow Superluminal is creating zips that Python sees as containing unicode paths.
  (e.g., "data/blueprints.xml.append")
  This is unusual among FTL's existing 'working mods'. But I guess it's standards compliant and even technically desirable (otherwise each OS gets to pick its own ambiguous ANSI codepage to encode/decode non-ascii characters, which could be painful cross-platform, if GMM weren't in the end just encoding each dat's index as ascii anyway when packing.).
• For Python 2.7.4, a dev - addressing some other issue - inserted some code that chokes when extracting a zip that contains unicode paths.
• Python 2.7.3 is fine. Python 3.x uses unicode everywhere, so it's probably okay.

I doubt you could use the standard Java API to create zips differently anyhow, had you wanted to work around it (maybe with the Apache Commons library mentioned in links below).

http://stackoverflow.com/questions/1551 ... ame-to-zip
http://stackoverflow.com/questions/1063 ... ip-in-java

[kartoFlane]

Hm. Superluminal actually uses System.getProperty("file.separator"); to get the path delimiter native to the system, though admittedly it then uses ZipOutputStream to create the zip file itself.
I've no idea which one is at fault here, but I'll take a look at the Apache libs -- I didn't like my implementation of the zip stream anyway :E

[Vhati]

Hm. Superluminal actually uses System.getProperty("file.separator"); to get the path delimiter native to the system, though admittedly it then uses ZipOutputStream to create the zip file itself.
I've no idea which one is at fault here, but I'll take a look at the Apache libs -- I didn't like my implementation of the zip stream anyway :E

There's rarely a need for file.separator (also, not dangerous). Java understands forward slashes. Zip only uses forward slashes. And path_str.replace('\\','/') is enough to convert paths, should they happen to be from Windows. IIRC all string vars in Java are unicode but streams encode/decode bytes (often using Charset.defaultCharset() ).

I linked those articles about adding unicode characters because if they let you set an encoding, you can set ascii. And if there's a constant called "UnicodeExtraFieldPolicy.ALWAYS", there's a NEVER.