Page 32 of 78
Re: [Tool] FTL Ship Editor: Superluminal - version 4-4-13
Posted: Sat Apr 06, 2013 12:05 am
by 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...
Re: [Tool] FTL Ship Editor: Superluminal - version 4-4-13
Posted: Sat Apr 06, 2013 1:05 am
by Greensburg
Thanks! That solved most of the issues.
Re: [Tool] FTL Ship Editor: Superluminal - version 4-4-13
Posted: Sat Apr 06, 2013 1:10 am
by speedoflight
kartoFlane wrote:
@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..
Re: [Tool] FTL Ship Editor: Superluminal - version 4-4-13
Posted: Sun Apr 07, 2013 11:49 pm
by 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
Re: [Tool] FTL Ship Editor: Superluminal - version 4-4-13
Posted: Mon Apr 08, 2013 12:02 am
by 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.
Re: [Tool] FTL Ship Editor: Superluminal - version 4-4-13
Posted: Mon Apr 08, 2013 12:11 am
by 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
)
Re: [Tool] FTL Ship Editor: Superluminal - version 4-4-13
Posted: Mon Apr 08, 2013 5:25 am
by 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
Re: [Tool] FTL Ship Editor: Superluminal - version 4-4-13
Posted: Mon Apr 08, 2013 6:30 am
by Vhati
kartoFlane wrote: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
Re: [Tool] FTL Ship Editor: Superluminal - version 4-4-13
Posted: Mon Apr 08, 2013 10:05 am
by 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
Re: [Tool] FTL Ship Editor: Superluminal - version 4-4-13
Posted: Mon Apr 08, 2013 6:15 pm
by Vhati
kartoFlane wrote: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.