Fixed some more parsing errors.

edit: Updated

Alright, this is nearing completion, though Chris Vimes is also contributing and looking into solving the memory issues.

I've squashed a lot of bugs, and I sat and talked with Thor as he rendered his maps, sorting out various bugs and he eventually ended up with a rendered map and no issues. However, this update is for some more major feature updates:

> NPCs and Ganis are now stored differently, but together. This makes things a little simpler in the code, but more importantly it allows me to sort them before I render them. Now they're sorted via their Y position, meaning NPCs should now no longer draw oddly over each other. However, because of the way ganis and such are rendered, there were slight complications. If a gani was in front of a door for example, but one tile below it, it was still being rendered under the door because of the way gani offsets are handled. So to compensate this I gave ganis a "handicap" so that if their Y matches a non-character Y, they would get draw over priority. However, because I've added this, it will also allow me to eventually parse for drawoverplayer() and so on and add that into the calculations when sorting.
> Render Characters toggle now works. Though, it only works if a character is deemed a character via showcharacter. If you're simply setting a gani like setcharani idle,null; then it will still be drawn.
> Fixed loads and loads of parsing bugs

So unless people have some major bugs will this, I'll probably sort out a nice write up about it and have Crono update the original post.

edit: Catching nullpointervalues now so it shouldn't hang when it encounters those problems, and should notify you via errorlog.

This does not show any NPC's at all for me:
http://i.imgur.com/VOivU.png

It seems the recent changes to file cache'ing in V6 prevents images from being found by this tool, which is a massive shame.

Ah that's a pity... if someone wants to make up a quick fix the source is still up. If I ever get back into this I'd probably redo a lot of things from scratch(like script parsing), and I haven't the time for that right now.

I created a patched version of this. The fixed Jar and source are in zip below. If anyone has problems with it I'll work on getting it fixed.

i don't see any source?

also, could you explain what you did to "patch" the issue where FILENAMECACHE.txt no longer exists?

Dusty already told me I just forgot to edit my post. I thought I had included. I've since reformatted my computer and lost the changes. I could easily redo it but I'm kinda lazy and don't really want to because it works as it currently is. If anyone wants to fix it all i did was make it generate a new FILENAMECACHE.txt in the ./Graal directory that would generate when it opened.

recreated your changes by using JDGUI and adapting your code to Oracle Java instead of openJDK, which might not work for most people (didn't work for me)

src is available at github, also created a pullrequest to dusty's repo to maintain a centralized place for the code.

Neither of your patches work for me. Cubical's opens, but the process halts at "Generating..." while Deas' java file refuses to open altogether.

Edit: This "Generating..." hang is now happening with Dusty's submissions too.

Deas version won't run for me either. I suspect it has something to do with the manifest because it throws this error message when I run it though the terminal:

Edit: The problem was because the manifest doesn't indicate what the main class is and can be easily fixed by adding the text below to the manifest file:

See, when I open the manifest file, those lines are already there.

This is what I get from my console.

Which is exactly the same, haha.

They aren't in Deas version or at least not for me.

That's odd. I'm defo using Deas' version too. I tried deleting the file and adding it to the jar again, but still no luck. It always returns that error.

ok, lets try that again, here's a new jarfile exported from the patch i made

A bit late on this thread, but this tool is very useful.

It is working well for me, with the exception of not being able to load custom images made as tiles (added by addtiledef2 in gs1). Says it "couldn't load the file <filename>" etc...

Using DEAS latest version attached ^^^

Is there a directory I need to store these images in within the graal folder? They are all currently located in my graal/levels/images/download folder...

//edit copied to the following directories: graal/levels/images

and now I only get the error for:

NPC Code:

---

[20:47:01]: Generating...

[20:47:01]: Creating new FILENAMECACHE.txt file in local directory C:\Users\Bradley\Graal

[20:47:01]: Created new FILENAMECACHE.txt file in local directory

---

and no activity afterwards...

error log: Parsing level: toran_00-00.nw

As far as Deas' version goes his change was mostly to fix the fact that Graal no longer uses Filenamecache.

However if you want to try my version out, you can still force filenamecache via deleting filenamecache.txt from your Graal folder and then running GraalEditor.exe.

I was able to generate images (did not include added tiledefs for some reason..) earlier no problem, even for the entire gmap, but the only thing I have done differently is store the images in a different directory (graal/levels/images instead of graal/levels/images/downloads) and I get errors with both versions.

I removed the images from both of the previously listed directories, and it is now able to generate a .png of the level, but does not include tiledefs, and gives me an error that it cannot LOAD the images when it generates the .png from my level...

SO, Maybe I am overlooking something, but what directory in my graal folder do I need to ensure I have the images for the tiles I am using (that the nw2png cannot find...)

I am assuming this is the source of my problems ^ ^ ?

Sorry for bumping an old thread, but is anyone by chance interested in a Graal to PNG program as well? If so I can probably make something for it. Tho I havent gotten to loading NPC's just tile data. Alternatively I could do Graal to nw. I dont have any zelda format to test tho.

Really wish this worked for terrain too, but it will probably never happen. :[

Would be more likely to happen if people fully understood how terrain works. If you can figure out how the heights all work you can draw polygons and apply a texture to them. Then you could have terrain but I'm not quite sure how terrain works and I don't have any levels to use to test with.

was pretty sure the default level editor would draw terrain maps just fine.

i am interested in nw2png improvements.

There is very minimal support for drawing layers correctly. When I get a chance I will post some examples.

It does show terrain right. But I have no idea how you would edit it in the first place. Draenin k ow more on how it works then I do. Layers art to hard to work with on levels but if you tried to do gmaps it can get very resource heavy. I would probably struggle more with npc but those aren't to hard it's more the set shape part or light effects ect.

What I want to do is make an html5 based gmap editor. Where you can edit a level and zoom out to see the whole gmap and still place trees and stuff. That would be a game changer there. But since it involves similar work as this I think the 2 projects can benefit off each other. My code sadly is in c++ not html5. Luckily it's not hard to convert.

But like I said the 2 projects could benefit off each other. Some people still use .graal levels for example level2.graal from npulse. I'm sure other people have levels saved on there hard drive from years ago.

Also does anyone know if you can do terrain on .graal levels?

I'd hazard a guess at no considering the only two ways to apply terrain to an .nw file is by either using the terrain generator or editing the values between the HEIGHTS and HEIGHTSEND tags and since .graal files are not readable as plain text it would be difficult to apply the terrain.

Well, .graal and .zelda used "#" character to separate data chunks. I doubt there is any chunk of data after the last segment since I see "# # #" ect at the end. But correct me if im wrong they also have height data in gmaps? If thats correct would the terrain also be applied to .graal levels?

Like I said I am not familiar with terrain like Draenin is. And maybe someone else could help answer that question? Maybe I am remembering things wrong even, not sure.

It does, but your only option is to print the map at a fraction of the size, and it does not include NPCs.

Sadly, there's only so much I can tell you about gmaps in relation to things like .graal levels and so forth, and I can't even begin to fathom how to replicate them, other than using pure black magic.

But, just to entertain the notion, here's a dump of information from a terrain gmap.

What I can tell you is that each height in the height map represents a vertex which is basically the corner of each level in the gmap. There is also a grid of about 9 x 9 smaller vertices on each level (including the level corners) which can be raised or lowered to affect the slope of the lines between each vertex.

It is very likely that these smaller heights are determined by the massive number of seeds down at the bottom of the list through pseudorandom number generation, but the geometry itself and the subsequent 'stretching' of tile textures when you move these vertices up and down is likely a product of either tessellation or fractal equations. Or both. I really have no clue.

If you're interested in how they work, here's a little video of me making a volcano. :D

Thanks Draenin, thats what I was referring to. There are a lot of things that I cannot understand about that either sadly either.

Like I said, it pretty much works through black magic.

This is creative works well I know I'm late but good work Dusty!

such a useful tool tbh