|
|
NimoStar
Responsible
Legendary Hero
Modding the Unmoddable
|
posted November 01, 2018 03:31 AM |
|
|
I actually prefer a set of PNGs to ora honestly, its easier to work with since .ora makes a mess with the layer sizes (which are not the same as the document size as noted).
But Namerutan's tool already uses ora...
____________
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted November 01, 2018 08:53 AM |
|
|
NimoStar said:
I actually prefer a set of PNGs to ora honestly, its easier to work with since .ora makes a mess with the layer sizes (which are not the same as the document size as noted).
But Namerutan's tool already uses ora...
The Resource editor already allows you to use PNGs. Ora was recommended partly to make it comoatible with Namerutans tool and also cause PNGs would be single layered only.
What do you mean make a mess with the layers?
____________
|
|
iliveinabox05
Honorable
Famous Hero
|
|
posted November 01, 2018 07:33 PM |
|
|
Karmakeld said:
The Resource editor already allows you to use PNGs. Ora was recommended partly to make it comoatible with Namerutans tool and also cause PNGs would be single layered only.
What do you mean make a mess with the layers?
I think he meant multiple pngs in a folder the way I described earlier when I asked everyone which they would prefer. Since the .ora format was basically a zipped folder of multiple png files, we went ahead with that.
In the future it is certainly possible that this program could handle png files in a folder, zipped or not, but currently I still have a lot to get finished.
|
|
iliveinabox05
Honorable
Famous Hero
|
|
posted November 03, 2018 02:35 AM |
|
|
So it looks like there's something weird going on with my editor for the shadows when importing from an ora file, but apparently they are still there.
So, I started with my test forge object, which was derived from a sawmill object.
Select File->import as before.
This time, change the file filter from png to ora and select the ora to import.
The ora is imported, including the shadows, which for some reason aren't being displayed.
Now, adjust the footprint to fit the sawmill.
Finally, add it to the palette and drop it on the map!
It's a still image, but the animation is definitely working  I'll try to get the update out to my testers asap!
Edit. Sent the updated drive link out to my testers!
|
|
NimoStar
Responsible
Legendary Hero
Modding the Unmoddable
|
|
posted November 03, 2018 09:12 AM |
|
|
Karmakeld said:
NimoStar said:
I actually prefer a set of PNGs to ora honestly, its easier to work with since .ora makes a mess with the layer sizes (which are not the same as the document size as noted).
But Namerutan's tool already uses ora...
The Resource editor already allows you to use PNGs. Ora was recommended partly to make it comoatible with Namerutans tool and also cause PNGs would be single layered only.
What do you mean make a mess with the layers?
as ilive said,
many editing programs make sprites out of separated png files.
They can be named layer001 layer002 etc. or arbitrary names just like with the ORA, but they are separate files, which makes individual editing less messy in some aspects; and Photoshop layers can be exported as PNGs, enabling another program to do edits.
But well, I aint asking for any features, just saying my thoughts on the issue.
____________
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted November 03, 2018 01:07 PM |
bonus applied by Galaad on 09 Jun 2019. |
|
 I had forgotten multiple png's could be an option, my bad.
I'll take a look at the new updates 
Also I now know a bit more about the end code 's properties which I'll post soon, but I still feel there's still a long way to go with the end code.
EDIT: Back to end code properties..
In the image above, I played around with some of the various 03 byte codes and I found that indeed the different codes have different properties.
Test with Derelict Ship: Changed 3 0 0 0 fe ff fe ff ff ff to all ff/255's. Ship now couldn't appear on top of tree. (see image)
Changed to ff ff fe ff fe fe. Ship now partly covers the tree, if placed on top of it. The same is the case with the mirrored Ship, it also only covers part of the tree (if placed above a tree). So what if the mirrored Ship has it's code changed to 255 255 254 255 254 255, will it cover the tree then? YES.
So clearly some of the codes is linked with direction, either left or right faced. This is also noticeable when comparing objects like Red Dwarf Mine, Skeletons.Dragon R and Vein.Ore R. All are 2x3 objects and all share the same end code. Passability and entrance info vary, so clearly these are non-determining factors.
Test with Derelict Ship shows that byte code lenght can't be changed. Tried both 02 and 04.
Test with Skeletons Dragon and Dragon R, switching the lenght 05 to 06 and around, failed. So again it seems lenght can't be changed. And the code seems to have to be the right one to appear correctly in the editor.
But why is Skeletons.Dragon's code longer than Skeletons.Dragon R??B Frame 001 differs only 1 pixel and shadow 001 only 5 pixels, so this doesn't really support my theory about frame size. The 2 Gold Veins also has different lenghts of end code.
I tested Crocodile (03), Pig (02) and other objects with pure 255 code, and they don't appear behind other objects like the Derelict Ship (03) did if changed to all 255.
Adding an end like code 2 0 0 0 255 255 255 255 255 or 3 with additional 255 255 to Skeletons Snake, didn't make it appear it front of objects.
Same goes for Skeletons.Bird. They keep appearing behind objects.
So why doesn't Crocodile2 appear behind objects, when it consists of all 255 code? Is it the impassability info, that pushes it infront?
Changing the Snakes end code to fe ff fe ff ff ff, didn't change anything.
Given the Snake the impassable entrance info of the Crocodile also didn't change anything. Hmmm...
I recalled the mirrored Labyrint (3x2), which had the same 'appear behind objects' issue. I found that the original Labyrint has a 07 byte code, so I added that - the mirrored one, didn't have an end code. The editor could read it, but it still appeared behind the tree. So I tried to mirror/reverse the end code but that didn't help either as seen on the image. Worth mentioning, is that the Labyrint is inserted into a larger image than the original Labyrint, so was it pure coincidence that the 07 end code matched..? Perhaps Radmutant can recall what object it was inserted into..? An end code of all 255/ff's also appears behind so did the end code of the Dragon Cave (3x3).
I tried shortening the code to 5 0 0 0 254 255 253 255 252 255 252 255 253 255, from the Vein.Ore a similar 3x2 object. The mirrored Labyrint can be read by the editor, with both a 05 and 07 byte code, but any attempts still leaves it appearing behind other objects.
So my conclusions so far:
- The objects (tile) size (e.g. 2x2 or 2x3) seems to have an impact on the code within it's byte lenght group (e.g. 02 or 03). Tile size also translates to e.g. Right faced directions.
- Original objects have fixed end codes. These can be changed as long as they keep the same lenght, but as depicted in the first image, it may affect how it act together with other objects.
But then how come, some objects can have the lenght of their end code changed, and they can still be read??
- Still some unknown factor decides the byte lenght.
- Removing the end code, will force the object to appear behind others.
So basically I'm still puzzled as to how it all fits together.
Importing new images into existing objects seem to be the safest way to avoid objects appearing behind others.
I noticed Radmutant managed to ensure all of his terrain objects will always appear behind all other objects, no matter what. These have no end code, which seems to be the reason. The mirrored Labyrint can appear behind those terrains, as it also lacks the end code. Same with the Snake Skeleton. Now an interesting thing is that the new Magic Lamp tend to jump in front of other objects, even at points where it shouldn't ought to.
Perhaps countless hours could bring us closer to understanding how end codes are determined, but I think I'll just rest my case here and focus on actual makin of new objects.
____________
|
|
iliveinabox05
Honorable
Famous Hero
|
|
posted November 05, 2018 01:11 AM |
|
|
|
So I finally found the bug causing me the issues with applying the alpha data. Pretty ridiculous bug.. Working on a fix
|
|
radmutant69
Promising
Known Hero
|
|
posted November 05, 2018 02:28 PM |
bonus applied by Galaad on 09 Jun 2019. |
|
Karmakeld said:
So basically I'm still puzzled as to how it all fits together.
Importing new images into existing objects seem to be the safest way to avoid objects appearing behind others.
I noticed Radmutant managed to ensure all of his terrain objects will always appear behind all other objects, no matter what. These have no end code, which seems to be the reason. The mirrored Labyrint can appear behind those terrains, as it also lacks the end code. Same with the Snake Skeleton. Now an interesting thing is that the new Magic Lamp tend to jump in front of other objects, even at points where it shouldn't ought to.
You should also look into my newer terrain objects too. Like the black terrain and others. They have the end code of the Trading Post since i used that to import the images. Their inability of appearing in front of other (normal) objects depends on this code part in the header
as i mentioned before multiple times. There is 00 02 in the original Trading post instead of 01 01 and it makes the terrain being a background object. Really.
But now it looks clear the end code is affects how the object covers other objects on the map. It's great you found it out. Now I could fix this Magic Lamp issue above by simply changing all of their end codes into FF's. They no longer appear in front of others if you don't want them do it
Edit: I think this means we don't have to actually know how these bytes determined to create new objects. The only thing needed is having a list of how long are the end codes in the various object types and sizes, and make the Resource editor set all the bytes to be FFs. With a little luck it should work just like that in most cases. I think.
|
|
iliveinabox05
Honorable
Famous Hero
|
|
posted November 05, 2018 05:58 PM |
|
|
Another thing to note, the number of these 2 byte numbers at the end of the file don't seem to have as much to do with the size of the footprint as we first thought (meaning the number of grid tiles), but more likely has to do with the size of the image being used (which, of course, you set the footprint to match).
If you look closely at the images Michael posted, you will notice there are square "chunks" appearing in front of the object below. I'm almost positive each of these "chunks" is being represented by one of the 2 byte numbers and the value is potentially a weight as to whether one "chunk" should appear above the same "chunk" of the other object.
Good stuff either way. Once I finish fixing my bug with parsing the alpha data, I can probably move onto figuring this out. It will be simple for me to make each of the end fields editable in order to try out different values on specific squares to see what happens.
What else would y'all like me to work on? Need to get that list going again!
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted November 05, 2018 07:38 PM |
|
|
Radmutant said:
as i mentioned before multiple times. There is 00 02 in the original Trading post instead of 01 01 and it makes the terrain being a background object. Really.
But now it looks clear the end code is affects how the object covers other objects on the map. It's great you found it out. Now I could fixthis Magic Lamp issue above by simply changing all of their end codes into FF's. They no longer appear in front of others if you don't want them do it
Edit: I think this means we don't have to actually know how these bytes determined to create new objects. The only thing needed is having a list of how long are the end codes in the various object types and sizes, and make the Resource editor set all the bytes to be FFs. With a little luck it should work just like that in most cases. I think.
Right. I had an itch in the back of my head about the other part determine fore/background, just couldn't quite recall it. Besides it was faster having you repeat yourself rather than searching for it lol.
Both of you ignited new energy in me to research further, so thx.
But as I posted, the only object type that seems to have an impact is the subtype (right/left/non directional) as well asthe tilesize. Perhaps I'm just misreading your point, but the tricky part is that even similar objects like the skeleton dragons or gold veins have different lenght end codes, depending on their direction. So aiming for object that won't be affected by the issue posted with the Derelict Ship, imo would require immensely amount of research and 100's of various setups.
Rather I would go for FF code as well and just live with the risk of objects having the Derelict Ship vs Tree issue. At least it's less important than front/background issue.
Edit: Updating the Magic Lamps in my object package with the fixed ones, we agree would cause a crash right? They'd need new names, yes..?
iliveinabox05 said:
Another thing to note, the number of these 2 byte numbers at the end of the file don't seem to have as much to do with the size of the footprint as we first thought (meaning the number of grid tiles), but more likely has to do with the size of the image being used (which, of course, you set the footprint to match).
If you look closely at the images Michael posted, you will notice there are square "chunks" appearing in front of the object below. I'm almost positive each of these "chunks" is being represented by one of the 2 byte numbers and the value is potentially a weight as to whether one "chunk" should appear above the same "chunk" of the other object.
Good stuff either way. Once I finish fixing my bug with parsing the alpha data, I can probably move onto figuring this out. It will be simple for me to make each of the end fields editable in order to try out different values on specific squares to see what happens.
What else would y'all like me to work on? Need to get that list going again!
Could you point out those 'chuncks' for me?
Some objects have a large visual frame when placed in the editor - which also effects it arae of deleting - but as I wrote I haven't been able to pin point how size affect the lenght. I can post or send my documentation so far, but I've 'only' looked at largest frame(s), that is if one frame has a larger width than the highest frame, 2 frame sizes are noted, but this doesn't hold up in court, so I'm guessing it's down to a single frame being the 'deTerminator'.
Anyway it seems Derrick has some idea where the data is read, so perhaps you have better insight?
As for next subject on your list, how about implementing the change of Object Types? I send you the list already 
____________
|
|
iliveinabox05
Honorable
Famous Hero
|
|
posted November 05, 2018 08:21 PM |
|
|
Karmakeld said:
Could you point out those 'chuncks' for me?
Some objects have a large visual frame when placed in the editor - which also effects it arae of deleting - but as I wrote I haven't been able to pin point how size affect the lenght. I can post or send my documentation so far, but I've 'only' looked at largest frame(s), that is if one frame has a larger width than the highest frame, 2 frame sizes are noted, but this doesn't hold up in court, so I'm guessing it's down to a single frame being the 'deTerminator'.
Anyway it seems Derrick has some idea where the data is read, so perhaps you have better insight?
I'll try to get to that when I get home from work. When I say "chunk" I just mean a square of one object's image appears above the other.
Basically, where you can see the tree popping up above the derelict ship, the portion that is showing over the ship are several square shapes from the tree object's image. So each of the end of file 2 byte numbers seems to be for each of those squares that show above the other object or appear below it.
To put it another way, chop up the image of the object into squares of equals size, then the info at the end of the file determines whether each of these squares will show above or below the image of another object.
That's what it's looking like to me anyway And thinking a little more about it, the squares themselves probably have a fixed pixel size (which someone could check out to see what the pixel length / width is based on the images you provided). This fixed pixel size it most likely what is imposing the image width / height and footprint location restrictions.
Karmakeld said:
As for next subject on your list, how about implementing the change of Object Types? I send you the list already
Oh right! Forgot about that one. Feel free to keep reminding me of what features we have discussed because I'm forgetful lately
|
|
radmutant69
Promising
Known Hero
|
|
posted November 05, 2018 09:40 PM |
|
|
Karmakeld said:
Edit: Updating the Magic Lamps in my object package with the fixed ones, we agree would cause a crash right? They'd need new names, yes..?
No they don't cause crash. When i tested it, I packed them with their original names into my mod file while they were already in the editor's object palette and they worked as well. But a double check never hurts..
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted November 05, 2018 09:57 PM |
|
|
Okay, now I get your idea. I was desperately looking for squares BELOW the objects haha.
I can see some reason in your theory, but then how to split the image evenly in 5, 7 or 11 chuncks? But let's look into it and see what comes out. Hopefully a bit of digging can reveal some more.
Edit: Rad, will double check. Just a bit uncertain as to what parts can be edited within the object, without causing the editor to break, but it's nice to know your attempt was succesful.
____________
|
|
iliveinabox05
Honorable
Famous Hero
|
|
posted November 05, 2018 10:25 PM |
|
|
Karmakeld said:
Okay, now I get your idea. I was desperately looking for squares BELOW the objects haha.
I can see some reason in your theory, but then how to split the image evenly in 5, 7 or 11 chuncks? But let's look into it and see what comes out. Hopefully a bit of digging can reveal some more.
When I say "evenly" it is a little misleading, because the square sizes are likely the same regardless of the size of the image. So the bigger the image / frame, the more of these "squares" that will cover it.
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted November 05, 2018 10:34 PM |
|
|
Right. I guess it would also make better sense with fixed squares than adaptable to size. Looking forward to see if you can confirm this..
Edit: also for next task how about looking into the dll stuff?
____________
|
|
iliveinabox05
Honorable
Famous Hero
|
|
posted November 08, 2018 07:57 PM |
|
|
Ah so not a task for the Resource Editor, but a new project?
I guess once I have this alpha bug fixed and you can change object types and foot prints (create new objects), there isn't much else for the Resource Editor to do.
The only other major thing would be for me to learn exactly what the end of file code represents. After that would be relatively easier tasks such as importing or exporting individual layers, etc.
I guess there is still the whole packing h4r files, but since we currently have tools that can do that, that task can be pushed to the bottom of the pile.
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted November 21, 2018 08:59 PM |
|
|
Hi mate
Had time to just test the ora import feature and it works nicely - with still images. I had a minor issue that images seemed not to be imported if the imported canvas is larger than the original, but I believe this had already been covered, so no biggie. If the canvas is large or similar size as the new image, there seems to be no issues. Though I encountered a single image, where the saved file didn't work. I had some issue with resizing, as the image would appear small and the passibility info was taking up the entire interface (much larger than the image). I tried to reproduce the issue, but in later attempts the passability info displayed correctly, although the object still didn't work.
Finally managed to make it work, by resizing Data to Grid, and the passability info fitted the image. In all cases I let the Extra Offsets being Present.
I can send you the files in case you want to try it out or I can try the process again.
The passability info is moving smoothly now 
Also I wonder if it would be possible to preset the save file name to that of the lastest imported file?
In some cases I get the entire path name, so it would be a bit of a time saver if possible.
____________
|
|
iliveinabox05
Honorable
Famous Hero
|
|
posted November 21, 2018 11:00 PM |
|
|
Thanks for giving it a test!
Currently resizing is actually turned off whether you select resizing options or not. I turned it off because there is still more work to do as far as resizing .ora files. A single image is simple, but I have to also scale the offsets for .ora files.
So for now, you'll need to do as you've been doing with Namerutan's tool and use gimp for resizing before you import an ora file.
If you import a small image, I can definitely see the footprint appearing large since I think I scale the footprint info based on the size of the image.
It's simple to save the last loaded path when selecting files, I just haven't gone back to that yet
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted November 22, 2018 12:36 AM |
|
|
iliveinabox05 said:
Thanks for giving it a test!
Currently resizing is actually turned off whether you select resizing options or not. I turned it off because there is still more work to do as far as resizing .ora files. A single image is simple, but I have to also scale the offsets for .ora files.
So for now, you'll need to do as you've been doing with Namerutan's tool and use gimp for resizing before you import an ora file.
If you import a small image, I can definitely see the footprint appearing large since I think I scale the footprint info based on the size of the image.
It's simple to save the last loaded path when selecting files, I just haven't gone back to that yet
Well I did already resize them in gimp, so, but yeah they weren't resized..
But the odd thing was that in 1 attempt the footprint was major large, and in the next it was fine and matched the image size.. I'll be sure to take some screenshots if it happens again.
I have another thing to mention. I tried inserting a bunch of images into one of the decidious trees, it worked with 4, but then failed with the rest. Then I switched to the Magnolia tree, and I could insert the next image, IF I left out the end code, but as expected, that caused the object to appear behind other objects. So I added an end code, tried both 2 byte ff, 4 byte and 6 byte ff - all worked - but that didn't change it. So I looked at RM's post about the header code, and looked for differences, but the ones I could find - 73 00 00 00/01 02 caused a memory failure within the editor and 02 00 4e/00 00/01 01 just crashed.
So when you have the time Radmutant, could you look into these files and see if you can repeat the Magic Lamp fix? Bush 05 is the issue, the others works fine.
Another Q, can you enable the option of changing the footprint height and width = change the size of the object from e.g. 1x1 to 1x2?
____________
|
|
radmutant69
Promising
Known Hero
|
|
posted November 22, 2018 11:20 AM |
|
|
Karmakeld said:
So when you have the time Radmutant, could you look into these files and see if you can repeat the Magic Lamp fix? Bush 05 is the issue, the others works fine.
The short answer is: I can't repeat. I don't even know what was the problem with this one as the other 4 bushes also have different canvas sizes and frame sizes from the original tree that you used to import. After some attempts to fix it, I recreated the object from scratch instead.
The appearing behind other objects was because both of your bushes.05 objects have a 01 02 in their header where they should have 00 02 (what causes crash BTW, likely because of the different canvas and frames sizes). The 01 from this makes the game ignoring the end code, so your objects can't cover others at all and appear in background anyway..
|
| |
|
|
This thread is pages long: 
