Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Test the first beta
SketchMapMerge
This little tool allows you to merge two SketchMaps into a new one having the sprites of both. This is useful to use stuff coming from another map into your map, as you cannot copy/paste in the editor. It's also useful for storing little things (like a complex enemy made of parent-children parts) in Sketch files, to be the merged at will into more important maps, and maybe distribute these Sketches as standalone files for other map makers.
More info can be found in the included ReadMe, for now (for those who know how to use command-line tolls, anyway), please test this and tell me of any issue, especially as it hasn't been tested (but should work) on a PowerPC Mac. If feedback is good enough I'll improve this tool and will post it to the add-on files once if it reaches release status.
Edit: took down the proof of concept link, now that there is a beta available
This post has been edited by Zacha Pedro : 14 February 2007 - 07:34 AM
@zacha-pedro, on Jan 11 2007, 08:02 AM, said in SketchMapMerge:
...especially as it hasn't been tested (but should work) on a PowerPC Mac.
It works quite well on my PPC Mac, apart from the lack of offsetting of the merged-in map. So far, I like it, but it definitely won't be ready for release until you've added on the modifications you mention in the readme.
Recommendations for future versions:
Moving and rotating, of course.
Optionally ignoring layer 1 in the .Sketch file.
A super-simplified preview display, just showing the outlines of the sprites involved in the two maps (perhaps only for certain layers?), at a very small scale.
A window for the disk image that isn't sticking partially off the right edge of my screen (not everyone has widescreen monitors, people).
Edwards
Glad that you like it, thanks for the feedback.
Ignoring level 1 will obsolete by the time I release this, thanks to the auto-background feature (unless there is another need for this) I'm afraid I cannot display anything in any way, this program doesn't know about the sprites or their appearance, it can barely handle their records in the level (and to do otherwise, I would need to fetch info from the SketchFighter app and act like it, which seems quite complicated already). Even super-simplified is easier said than done, and I don't want to throw in this feature unless I'm damn sure it works perfectly and it really serves a purpose the way I implemented it. Oops. Guess that the position of the window when I freeze the disk image is important. Sorry.
@zacha-pedro, on Jan 11 2007, 10:14 AM, said in SketchMapMerge:
Ignoring level 1 will obsolete by the time I release this, thanks to the auto-background feature (unless there is another need for this).
Well, there have been a couple of times so far that I've wanted to do the background at least partially by hand, so I hope that there won't be any trouble doing so with the new editor. I'd need a bit more information about the new auto-background feature to be certain of my opinion on ignoring layer 1. Does it simply populate layer one with the appropriate sprites, or does it add a bit of information to the file saying "use this sprite(, in this orientation)(, with this color) as the background" and let the game engine handle things?
I'm afraid I cannot display anything in any way, this program doesn't know about the sprites or their appearance(...)
I can assure you that it knows enough. All I was thinking of was a plain box around the border of each sprite, with no hint of the actual appearance of the sprite, for the purpose of visually aligning the offset and orientation of the two maps. However, adding this in may not be at all easy to do (I have no idea how displaying images and such is to program), and is certainly not essential to the functioning of the program. It would be nice, though... :puppy-dog eyes:
Oops. Guess that the position of the window when I freeze the disk image is important. Sorry.
It's quite surprising how many people don't realize that.
Now, one more possible feature: Adding a prefix/suffix-before-the-first-period to the names of the sprites in the level, as a simple way to avoid name collisions if you want to add several copies of a complex critter to a map.
@edwards, on Jan 12 2007, 04:00 AM, said in SketchMapMerge:
I'd need a bit more information about the new auto-background feature to be certain of my opinion on ignoring layer 1. Does it simply populate layer one with the appropriate sprites, or does it add a bit of information to the file saying "use this sprite(, in this orientation)(, with this color) as the background" and let the game engine handle things?
It simply populates layer 1 with background sprite 2, the paper, in the plain orientation.
@freq245, on Jan 13 2007, 02:20 AM, said in SketchMapMerge:
That's all it does? You don't even get a choice of which background sprite you want?? It's not too late to change the format of the sketchmap files - if a new version renders the existing 3 or 4 maps on the addons incompatible then so be it. I would much rather an important change was made now than have people still complaining that backgrounds aren't as simple as they could be when there's dozens maps up on the addons pages.
:raises an eyebrow: Let me see what I can do, but I can't make any promises.
Wow. Mr. Gäfvert is either pressed for time, or he doesn't really care that much about the editor. Or both. Since I know this is likely a side project, I'll give him the benefit of the doubt either way and leave it at that.
deep breaths
Ok. ZP, what a wonderful idea! It's definitely in proof of concept stage, but I like what I see so far. It seems to work fine on my PowerBook G4 w/10.4.8 (as in, it hasn't failed a merge yet, and seems to deal gracefully with malformed input).
Since you say you plan to make a GUI, I'm not sure if I should offer suggestions for the command-line version or for the GUI version. So, I'll do both!
CLI: -The rules for omitting file extensions are rather convoluted. Why do you require a .Sketch extension on the second parameter? I mean, you don't unless the user wants to omit it, but why would they bother to change the file extension in the first place? And on the topic of extensions, why make the user manually add one to the outfile, when you could do it for them?
-Beyond what you said you wanted to add in the Readme, an option to specify the number of copies to merge would be golden.
-It seems to work if you specify the same file for input and output, but a warning that doing so may not be the best of ideas is probably in order (with an option to disable it).
GUI: -Make it a droplet (drop files, fill in dialog with options, "Boom!").
-Preserve the CLI interface to enable scripting and automation (unless you're down with adding AppleScript support; I hear it's a royal pain).
-There is no step three!
Again, this is a potentially great tool with some rough edges. I intend to wrap it in an AppleScript droplet for personal use, at least until the final version arrives. Thanks for sharing!
So now I have collected some feedback, let me expand a bit more (yeah, sorry, no update so far, unfortunately I've been kept busy by a few other commitments, like making sure you get the 1.0.1 update ASAP).
Edwards, as you know yourself not even the size or bounding rectangle of a sprite is stored in the level, only its position and orientation. This means I'd have to locate the SketchFighter app and interpret the various data files even for displaying them. I'd like to keep this little tool as simple as possible (not to mention that it could be broken if ever the internal data formats change). So a first release of this tool won't include this at any rate.
cheleball, Lars does take the editor seriously, it's just a bit low-level, down to the level details (i.e. backgrounds that have to be there in perfectly aligned squares); in fact he improved the auto-background tool recently ofr the next update. So there.
About this tool: I'll keep the command-line interface (and I intentionally worked so that it would deal gracefully with malformed input, I'm unfriendly enough to give only a command-line version already, better not make things worse by making the program mysteriously not work when there's a typo) and create a GUI version (they will share the actual, level-merging and modifying code), though don't expect anything really complex, probably a setup screen where you will be able to input the two files, set the options for each file (shift, rotation, which layers to keep, renames if any, etc...), with finally a merge button which will ask you for the destination. I'll put a basic rename, wich will look for sprites with a certain name and its children, and rename the parent and the parent part of the children accordingly, but also a mass merge, to insert a bunch of critters of which one instance is in the second Sketch, with a number appended to the base name each time so that they don't get mixed up.
About the Sketch extension: I want to be able to create such Sketches, containing just a complex critter, and upload them to the add-on files for other mapmakers to use, and I want others to do so too (in fact, TrickyEnemy.Sketch is very serious, and I encourage you to use it in your custom levels); also, my next custom level (which is waiting for 1.0.1 to be released) will include a .Sketch version of the boss, for it to be used in other custom levels (when you'll see it, you'll see it can be used as a great mid-level blocking path miniboss, or even not a boss at all, he doesn't need to be a boss). But of course these Sketches can not be played as custom levels, and I want to avoid people mistakenly using them as custom levels (which would be horrible since there is no background, no start position, no walls...). So the easiest way I found so that these Sketches wouldn't be mistaken for custom levels was to change the extension to .Sketch; this way they keep the custom level format (so they can be easily done from a .SketchMap, just remove the Map, and the merging program deals with them exactly as it would with a SketchMap). It's obvious SketchMapMerge will be more often used with these simple Sketches than with full SketchMaps as the addendum, you won't often merge two full maps. So I set the implicit extension for the second file to be only "Sketch". Notice that with input files it still allows you to specify any file name, since if it finds the filen having the filename as you gave it, it will use this file, and only add the extension if he didn't find a file with the original filename; on the other hand with output, the file is assumed to be created, and if the user doesn't want the SketchMap extension there would be no way for him to specify it if I implicitely added it after the filename he gave. So that's the reasoning behind (.SketchMap)-(.Sketch)-nothing.
@zacha-pedro, on Jan 17 2007, 01:23 AM, said in SketchMapMerge:
(...)Edwards, as you know yourself not even the size or bounding rectangle of a sprite is stored in the level, only its position and orientation.(...)
Oops, It has been confirmed to me that such data may not be unfound in the level, so that it is definitely not within the realm of impossibility to have this "preview" feature not be absent, without even not ignoring the data not unfound in the main game. Sorry for assuming I know everything, when I don't even check the data. As a punishment, I will therefore definitely implement this feature, though I make no promise about when it will be done :p. Thanks for the whack upside the head, Edwards, I needed it.
Uh oh... the ways sprites are actually placed in the level from the coordinates and rotation angle is so complex and relies so weirdly on the rotation center, that in order to implement what I wanted to be the first implemented feature, rotation (so that you can have critters merged in at various rotations, heck it would be a little boring and repetitive to always have this "Tricky Enemy" oriented to be hit from the south), I need to peek in the game's data files to get the position of the rotation center of the sprites, this means locating the game in the first place and all that. Just for this little feature. Oh joy.
The GUI version will probably ask you for its location the first time then store it as a pref (maybe with an option to reselect it when you upgrade, and of course it will detect when the one it had been using so far is gone), as for the CLI version, the location of the app will have to be in an environment var. Joy, I tell ya.
This post has been edited by Zacha Pedro : 17 January 2007 - 08:06 PM
It's just me, a begginer at Terminal. I've tried to get it it to work, but this is what I get:
/Users/Me/Desktop/SketchFighter\ 4000\ Alpha/Custom\ Levels/Map.SketchMap TrickyEnemy.Sketch Output -bash: /Users/Me/Desktop/SketchFighter 4000 Alpha/Custom Levels/Map.SketchMap: Permission denied
This post has been edited by FireFalcon : 20 January 2007 - 10:02 AM
@firefalcon, on Jan 20 2007, 08:01 AM, said in SketchMapMerge:
If the first line is the command you typed, then you need to put the name of the command first. That is the full path to the tool in this case (or ./ if your present working directory (pwd) is the same as that of the tool).
Indeed, I don't see any SketchMapMerge whatsoever at the beginning. For the super-simple way to do it, just drag and drop first SMM, then the base map, then the addendum, then type the output file name and hit return. It will tell you when it suceeded, and if it doesn't it'll tell you why, provided SMM runs at all (if it doesn't then I can't do anything about the error you get; technically here the shell tells you that the first string specified in the line, which is supposed to be a command to run i.e. an executable file, is not actually executable and cannot be run, that's all).
Ok, I did it this way this time but it didn't merge:
Last login: Sat Jan 20 12:23:46 on ttyp1 Welcome to Darwin! my-emac:~ Me$ /Users/Me/Desktop/SketchFighter\ 4000\ Alpha/Custom\ Levels/SketchMapMerge /Users/Me/Desktop/SketchFighter\ 4000\ Alpha/Custom\ Levels/TestMap.SketchMap /Users/Me/Desktop/SketchFighter\ 4000\ Alpha/Custom\ Levels/TrickyEnemy.Sketch Output /Users/Me/Desktop/SketchFighter\ 4000\ Alpha/SketchFighter\ Editor.app/ Output has been successfully filled with the merge of /Users/Me/Desktop/SketchFighter 4000 Alpha/Custom Levels/TestMap.SketchMap and /Users/Me/Desktop/SketchFighter 4000 Alpha/Custom Levels/TrickyEnemy.Sketch. my-emac:~ Me$
This post has been edited by FireFalcon : 20 January 2007 - 01:28 PM
It did merge. Just check out the new "Output" file that has been created in (from the look of it) your home folder.
Gah. Just so that you realise it's 4AM here. I've worked non-stop to debug the working of the new version; it has been pretty much rewritten in Cocoa so that I could take a few things into account (like the fact I need to fetch data off the SketchFighter bundle) and to generally be better able to fit a GUI on the thing, but for now the work has been on the underlaying algorithms: rotation, displacement, renaming, mass merging, etc... Remains the glue code to write to have an actual CLI client that allows accesss all the features, then a GUI app (which, by the way, will require 10.3 because Cocoa bindings are so cool), not to mention to prevent the app from spewing a gazillion of "no pool in place" messages logged to stdout... (right now, the app is a bare-bones CLI with a gazillion things hardcoded and ugly code for the main function).
So to prove that I have worked, here are a few teasing screenshots:
Oh sweet bed... how I missed you... ZZZZzzzzzzzzzzz.....
((NSAutoreleasePool alloc) init); for god's sake, man!
Hehe, someone who knows what the heck I am talking about (referring to the ""no pool in place" messages logged to stdout"). Thanks for the pointer, but I'm afraid I already knew, it's just that I was too lazy to put that line when the time came to write the ugly hardcoded CLI wrapper to generate these two examples at 3AM...
Heh, fair enough.