|
| Thread: Researching how to add new objects |  This thread is pages long: 1 2 3 4 5 6 7 8 9 10 11 · «PREV / NEXT» |
|
radmutant69
Promising
Known Hero
|
posted December 24, 2017 10:02 AM |
|
|
No... I thought you want to make a background object from an existing foreground object...
Next time I should read such requests more carefully I think.
|
|
radmutant69
Promising
Known Hero
|
|
posted January 14, 2018 01:48 PM |
|
|
Hey Karmakeld! Remember this one? 
I've just found out how to make it centered via hex editing. I think you no longer need to fix uncentered images manually.
We just have to editing these values at the end of the object file:
These are that 'exactly 8 bytes' before the xx 00 00 00 at the file's end that we need to keep when we make new objects. And these determine the 'coordinates' of the image compared to its entrance.
It works kinda like the moving of the capture flags. Also this means I found another way to to place objects out of the map's border
Edit: beware of potential crash danger if you're experimenting with this btw... backup your .aop files anyway.
Edit2: it worked with the Bone quest hut too (after a lot of crashes and stuff.) So i can guess it is confirmed now.
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted January 15, 2018 09:00 PM |
|
|
Yeah I remember that portal
Great discovery. So do you have a clue about how those coordinated work/are read or did you watch the changes of your editing till it was right?
Still if I'm not mistaken, that specific portal was centered on the grid, wasn't it? Although it's still great if we can just move the entrance info to the image, rather than having to redo it all..
Editing the entrance code, I've found that seems to (always) be placed at the upper part of the image, like this entrance from the Mansion Quest Hut, inserted into a Sawmill.
That showed me where to place the Mansion - manually  and as the image shows, placing the new image in the lower right corner, would just have been too easy..
But only you know which method is the faster, hex vs. image editing.
Still it's great that you found out what the end code does. Now we just have to locate the animation speed
____________
|
|
Baronus
Legendary Hero
|
|
posted January 16, 2018 09:10 AM |
|
|
|
This end! Yes I thought that there must be object size, positon in picture and entrance. Great!
|
|
mirage
Promising
Hired Hero
|
|
posted January 16, 2018 02:52 PM |
|
|
|
sounds great. i hope it means we can now repair all my bad objects. am i right?
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted January 16, 2018 07:55 PM |
|
|
mirage said:
sounds great. i hope it means we can now repair all my bad objects. am i right?
Sorry Mirage, but your objects are simply beyond repair  haha.
Sorry, just had to tease you there 
We found that a secure method is to extract an image that is about the same size as your new image and/or has the same passability info/size as you want your object to have (you can compare the sizes in the ResHelper if needed).
Then you insert your image in e.g. Rock.Green.26. Save it as h4d file. Open your file as well as the original rock.green.h4d object in hex editor and copy/paste header and footprint. Then your object will be perfectly placed. As I displayed in the screenshot above, if you need larger images you can chance entrance info (if needed), to determine where you need to place your object in the original image.
Alternate method is to edit the code at the end like Radmutant did, but that is only for aligning entrance with image if these two doesn't match - we found that this issue likely comes from inserting images into objects like the snake skeleton, which are larger than the original image.
It seems that objects which are passable can import images that are larger than the original, while objects with entrances/impassable info will crash the editor if new image is larger than original.
But as long as you use a suited object/image as base for your new object, it seems to work in most cases.
A lot of info I know  ..
I'll post screenshot guides tomorrow for easier understanding.
But Radmutant is really the one who can answer if he can fix your uncentered images, with just hexediting. My method requires the original images, which I believe you deleted..?
Baronus said:
This end! Yes I thought that there must be object size, positon in picture and entrance. Great!
I don't think any of us questioned wheter or not these info is found within the file or not , but rather where or how they're being read. But by now we know several of the codes and where they're placed, although we still have a few uncertain ones.
I can post some details tomorrow as well.
Perhaps then others can help searching for the remaining ones.
|
|
radmutant69
Promising
Known Hero
|
|
posted January 17, 2018 06:04 PM |
|
|
mirage said:
sounds great. i hope it means we can now repair all my bad objects. am i right?
Well I tried to do my best but some of your objects have another serious problems beside being off-centered. For example a few of them are crashing my editor and your 'quest creatures' are still background objects thanks to the Holy Snake Skeleton...
I think we will have to extract/export these images when I'll have some time and try to import them again.
Also note that I still didn't look into the necropolis objects file but I will I promise
|
|
mirage
Promising
Hired Hero
|
|
posted January 17, 2018 08:41 PM |
|
Edited by mirage at 21:35, 17 Jan 2018.
|
Karmakeld said:
Sorry Mirage, but your objects are simply beyond repair haha.
Sorry, just had to tease you there
lol 
Karmakeld said:
We found that a secure method is to extract an image that is about the same size as your new image and/or has the same passability info/size as you want your object to have (you can compare the sizes in the ResHelper if needed).
Then you insert your image in e.g. Rock.Green.26. Save it as h4d file. Open your file as well as the original rock.green.h4d object in hex editor and copy/paste header and footprint. Then your object will be perfectly placed. As I displayed in the screenshot above, if you need larger images you can chance entrance info (if needed), to determine where you need to place your object in the original image.
yeah i know and my method is even better cause im using only a few objects to import my images. i can easily change object types after that, right? but this wont help on my old objects and i dont wanna make them again. especially the animated objects.
Karmakeld said:
Alternate method is to edit the code at the end like Radmutant did, but that is only for aligning entrance with image if these two doesn't match - we found that this issue likely comes from inserting images into objects like the snake skeleton, which are larger than the original image.
yeah f*ck the snake skeleton
Karmakeld said:
It seems that objects which are passable can import images that are larger than the original, while objects with entrances/impassable info will crash the editor if new image is larger than original.
But as long as you use a suited object/image as base for your new object, it seems to work in most cases.
A lot of info I know ..
I'll post screenshot guides tomorrow for easier understanding.
no the radmutant told me its a code after the object types like 0101000100030001 etc and that means its a 'background object' and 'allows any images'. but that can have an entrance. i saw a stupid flagable holy ground from h3 and that was a zombie dwelling
Karmakeld said:
But Radmutant is really the one who can answer if he can fix your uncentered images, with just hexediting. My method requires the original images, which I believe you deleted..?
my bad... but he is right we can export it from objects. i just never thought about that...
radmutant69 said:
Well I [url=https://www.4shared.com/rar/uQ0yAqsAca/Mirage_objects.html]tried to do my best[/url] but some of your objects have another serious problems beside being off-centered. For example a few of them are crashing my editor and your 'quest creatures' are still background objects thanks to the Holy Snake Skeleton...
yeah but at least most of them are centered now huh? thx...
holy snake skeleton lol
radmutant69 said:
Also note that I still didn't look into the necropolis objects file but I will I promise
meh you wont. and i finished the pyramid dwellings but that sucks in town. i will use the anubis temple stuff instead. and will you ever make the 4th level lich?? cause i dont wanna make the dwelling for 3th and the dark knight one and then again when you change your mind...
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted January 17, 2018 10:13 PM |
bonus applied by Galaad on 09 Jun 2019. |
|
So you just confirmed that using the Snake Skeleton will most of the time create off-centered objects.
Well here's my guide:
Step 1:
Find and export the object you want to use to insert your new image (both extract (h4d) and export (ora) the object). In this case I want to mirror the Witch Hut. I'll be using the Sawmill R to insert it in.
I've mirrored the Witch Hut, but as it's entrance isn't a quadratic square, simply mirroring it (copy-pasting it to the same position as in the original image) like this,
will leave it off-center like this (the same thing will often happen if using the Snake Skeleton as I did here):
Step 2:
I'll be using the Gem vein's entrance, as it matches how I want the Witch's Hut to be like, when mirrored.
Step 3:
As the Witch Hut's is a single framed object, I've deleted all 'animation' frames and shadows, and renamed base_frame and base_shadow to frame 001 and shadow 001.
I then imported my single framed image and saved that as a h4d file.
Step 4:
I want to replace the entrance of the Sawmill to that of the Gem vein, as it can show me, where the Witch's Hut needs to be placed compared to the Sawmill.
Next I place my new h4d file in the Data folder, and view it in the editor. Now it looks like this and I now know where to place my mirrored Witch's Hut.
Step 5:
Now to replace the Sawmill R image with my mirrored Witch's Hut in Gimp.
To make sure I get right, I'm comparing the original Witch's Hut with the Left Sawmill.
Finished result, saved. Next is to import it with ResHelper and save as h4d file.
Step 6:
Open the 3 objects' h4d files in Hex Editor.
My new mirrored Witch's Hut image looks like this (top image).
As I've used the Sawmill R image to insert my new image, I'll be using the header (middle images) and footprint codes (lower 2 images) of that object. I simply copy and paste them at the start and end of my new image. This will transform it into a readable object.
(footprint v)
So the import worked, but as of now it's typed as a Sawmill and the entrance info isn't how I want it.
So I'll start by replacing the entrance info. I'll copy that of the Gem Vein R and replace it the one of the Sawmill.
Next, I'll replace the type. I replace mine with school and sawmill with witchs hut. Note that I didn't change the 2 bytes between mine and sawmill, doing so will corrupt the object and crash the editor. I left the word right as it doesn't affect my object.
Step 7:
So let's view the result in the editor ....
____________
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted January 24, 2018 09:36 PM |
bonus applied by Galaad on 27 Oct 2019. |
|
mirage said:
Karmakeld said:
We found that a secure method is to extract an image that is about the same size as your new image and/or has the same passability info/size as you want your object to have (you can compare the sizes in the ResHelper if needed).
Then you insert your image in e.g. Rock.Green.26. Save it as h4d file. Open your file as well as the original rock.green.h4d object in hex editor and copy/paste header and footprint. Then your object will be perfectly placed. As I displayed in the screenshot above, if you need larger images you can chance entrance info (if needed), to determine where you need to place your object in the original image.
yeah i know and my method is even better cause im using only a few objects to import my images. i can easily change object types after that, right? but this wont help on my old objects and i dont wanna make them again. especially the animated objects.
Changing object types is often rather easy and should cause little problems in most cases. I have though found that in some cases, you should stick to changing only the names, and NOT the bytes in between e.g subtype and object name, as that can cause corruption.
Using only a few objects, you should be aware of the issue with front/background objects, but using adventure/interactive objects, should help solve this.
mirage said:
Karmakeld said:
But Radmutant is really the one who can answer if he can fix your uncentered images, with just hexediting. My method requires the original images, which I believe you deleted..?
my bad... but he is right we can export it from objects. i just never thought about that...
Well did it work then??
mirage said:
Karmakeld said:
It seems that objects which are passable can import images that are larger than the original, while objects with entrances/impassable info will crash the editor if new image is larger than original.
But as long as you use a suited object/image as base for your new object, it seems to work in most cases.
A lot of info I know ..
I'll post screenshot guides tomorrow for easier understanding.
no the radmutant told me its a code after the object types like 0101000100030001 etc and that means its a 'background object' and 'allows any images'. but that can have an entrance. i saw a stupid flagable holy ground from h3 and that was a zombie dwelling
Well he mentioned he made a discory about this that couldn't easily be changed, but no exactly how it's determined. Nice to know.
Sure you can change the entrance at any point, but my conclusion is based on how the objects are in their original state. I'm not saying I couldn't be wrong, only what my tests, both with succes and failure, have shown me.
------
In relation to the foreground/background code, I've compiled these infos (with the help of Radmutant and others) with description about where they're found in the object files. Feel free to add or correct any info I might be wrong about. All infos are displayed in the image below - in this case I looked at Sawmill (left).
Blue show the objects size e.g 2 x 3 tiles. (02 00 03 00)
Orange seems to be the animation speed. For the Sawmill it's displayed in the ResHelper as speed 166, hex code 06. Point of Power is 142, hex code 7. This area definitely calls for some more looking into.
Grey seems to decide how the entrance looks like, 3f in this case. The following bytes (not sure how many) will change number of passable/impassable tiles the object has and their placement. The lenght is linked with objects tile size. Larger size = more bytes follow.
Edit: Okay so position 09 is related to how the passability info looks like, but the actual entrance info seems to be at position 10/0a.
Yellow - type, subtype, name etc. First byte 04 tells that mine is a 4 letter work etc.
Green indicates flag positions horiz/vert. -1c (28) and fd (253) (those 3 bytes after each, should be 'move to 00 right or ff left').
What we don't know/understand is how 28 and 253 translates to 'understandable positions' when compared in Gimp, yet.
Red is where the image code starts. 1a = 26. This object consist of 26 frames. 00 01 01 00 is start the of the image. The code of non-animated objects, often starts after this code ff ff ff ff 02 (2 frames).
Violet seems to be entrance placement compared to image (the is at the end of the code - Radmutant know more about this than me). In decimals it's (Horitz.) 166 3x255/a6 3xff and (Vert.) 164 3x255/a4 3xff. As with flag it seems ff or 00 moves position to left or right. But decimal numbers doesn't corespond with coordinates in Gimp. ResHelper somehow reads the Horizontal and Vertical Footprints of images/objects (in this case it's listed as Horiz. 90, Vert. 92 - this matches the top of passability info, which matches the image when viewed in Gimp.). But Hex code, if viewed as positions, is placed beyond and below the entrance - I guess if you added another tile, then it would match the bottom of that. That is the BOTTOM of entrance tile, while the TOP of passability is what is read/displayed in ResHelper. Sadly Namerutan isn't here to inform us how his program reads these info.
____________
|
|
Baronus
Legendary Hero
|
|
posted January 24, 2018 10:45 PM |
|
Edited by Baronus at 22:46, 24 Jan 2018.
|
Baronus
Very good! I think that position is calculated from right up corner. So x will be small eg 28 but y high eg 253 because picture is right down. Its raw/tga system.
|
|
mirage
Promising
Hired Hero
|
|
posted January 25, 2018 03:28 PM |
|
|
Karmakeld said:
mirage said:
Karmakeld said:
But Radmutant is really the one who can answer if he can fix your uncentered images, with just hexediting. My method requires the original images, which I believe you deleted..?
my bad... but he is right we can export it from objects. i just never thought about that...
Well did it work then??
well it should work i guess... i exported the images but didnt try to import them again yet. [url=http://jmp.sh/HWNwX8b]here[/url] is a zip of the oras if you want them...
but most of the objects are working as well since they are 'repaired'. i dont care if they not perfectly centered and now even the worst objects are only a few pixels out of the tiles center. and i wont see that ingame anyway. only the creature quest huts are suck now.
Baronus said:
Its raw/tga system.
what?
|
|
Baronus
Legendary Hero
|
|
posted January 25, 2018 05:28 PM |
|
Edited by Baronus at 17:30, 25 Jan 2018.
|
Baronus
If you eg save as tga by irfan, you are asked what corner you want as start! Of course maybe H4 creators have selected it ingame looking at tga. In H3 its upper left.
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted January 25, 2018 10:54 PM |
|
|
Baronus said:
I think that position is calculated from right up corner. So x will be small eg 28 but y high eg 253 because picture is right down. Its raw/tga system.
Hmmm, could you show how you calculate that position?
If I view the flagged Sawmill in Gimp, flag postion is approx. at these:
Top of flag 118,76
Bottom of flag 118,88
Tip of flag 149,83.
Also the size of the layer that the Sawmill is displayed in, only measures 192 x 174, so 253 is beyond the image border.
____________
|
|
Baronus
Legendary Hero
|
|
posted January 25, 2018 11:30 PM |
|
Edited by Baronus at 23:35, 25 Jan 2018.
|
Baronus
Mill is ingame object not a layer. Layer is only interface. Its possible because flag is higher than object. But it can be something another too...
|
|
radmutant69
Promising
Known Hero
|
|
posted January 26, 2018 02:43 PM |
|
|
Some notes:
Baronus said:
Mill is ingame object not a layer. Layer is only interface.
Yeah but when we talking about 'layers' here we usually mean layers inside the imported .ora images and not the H4 layer file type. Our problem is the decimal coordiantes or positions displayed in Gimp and ResHelper have seemingly no(?) connection with the hex values in object files. So we can't calculate the correct values in these files easily.
Baronus said:
Its possible because flag is higher than object. But it can be something another too...
It's possible because the flag is another image attached by the game itself when you capture a flagable object and it has a flag code. But the flag (in theory) can be anywhere as it has no connection with the object's images. But yeah this code also cannot be calculated from Gimp coordinates... I think.
Karmakeld said:
Violet seems to be entrance placement compared to image (the is at the end of the code - Radmutant know more about this than me).
No. I don't I just blindly trying out random values when I want to change this stuff. But according to my experiments and some new info you sent me this code probably moves the layers (all in one) inside the image. This is why in some cases I can't move the images to the correct place, because sometimes the image isn't much bigger than the layers inside it and it seems if you set a position out of the image's border it causes crash.
|
|
Baronus
Legendary Hero
|
|
posted January 26, 2018 06:04 PM |
|
Edited by Baronus at 18:06, 26 Jan 2018.
|
Baronus
So better is tell frame as we see it ingame def to dont do confusion :-)
Method is easy. Build rectangle eg full green in flag size eg 341 / 392. And some objects as fullred rectangles. Insert in map editor and make screen capture. Then open capture in Gimp and calculate values. Or rectangles with 1px periphery and transparency inside and compare...
|
|
Karmakeld
Responsible
Supreme Hero
|
|
posted January 27, 2018 12:19 AM |
|
|
radmutant69 said:
Some notes:
Baronus said:
Mill is ingame object not a layer. Layer is only interface.
Yeah but when we talking about 'layers' here we usually mean layers inside the imported .ora images and not the H4 layer file type. Our problem is the decimal coordiantes or positions displayed in Gimp and ResHelper have seemingly no(?) connection with the hex values in object files. So we can't calculate the correct values in these files easily.
Baronus said:
Its possible because flag is higher than object. But it can be something another too...
It's possible because the flag is another image attached by the game itself when you capture a flagable object and it has a flag code. But the flag (in theory) can be anywhere as it has no connection with the object's images. But yeah this code also cannot be calculated from Gimp coordinates... I think.
Karmakeld said:
Violet seems to be entrance placement compared to image (the is at the end of the code - Radmutant know more about this than me).
No. I don't I just blindly trying out random values when I want to change this stuff. But according to my experiments and some new info you sent me this code probably moves the layers frames (all in one) inside the image. This is why in some cases I can't move the images to the correct place, because sometimes the image isn't much bigger than the layers frames inside it and it seems if you set a position out of the image's border it causes crash.
That sounds plausible. Is it the same for passable/non-passable objects or have you only encountered the issue with non-passable ones?
I'm just thinking if this is related to the issues of inserting new images, (hex code of larger/smaller images) - this could be what you refered to.
Now what's funny in relation to the above, is that shadow frames apparently can exceed the image border and that will show when inserted in the editor. The shadow spot to the upper right, isn't visible in Gimp, as it's outside the border of the image, yet it isn't automatically erased as one would guess.
Just for curiosity sake, I might try the same with a base frame, just for tests. Also it would be worth testing if an exceeding image can be inserted into 'original' object or if it crashes the editor.
Baronus said:
So better is tell frame as we see it ingame def to dont do confusion :-)
Method is easy. Build rectangle eg full green in flag size eg 341 / 392. And some objects as fullred rectangles. Insert in map editor and make screen capture. Then open capture in Gimp and calculate values. Or rectangles with 1px periphery and transparency inside and compare...
Okay so not to confuse layers and frames, this is how each layer/frame looks like in Gimp:
 .
Each layer is named either Frame or Shadow. This shows how each layer can be positioned different places in the image (you probably know this already).
I took this screenshot of the Sawmill (frame if you will, as seen) in the editor while flagged, and placed it on top of the original image. This allowed me to locate the Gimp coordinates I listed in my previous post.
I'm not 100% sure, but I guess this is what you suggested I should do, to calculate the values, right?
As I wrote, I can read the coordinates alright, but we can't match them with the hex values 28, 253. What we're saying is, that none of the hex values translates to image (Gimp) coordinates.
If you want to know the measurement of each tile, for pixel comparison, I've measured them to be 61 pixels wide (horiz. across) and 30 pixels high (vert.). Each of the 4 sides measures about 30 pixels. I suggest you look at the Adv.Object.Default as it shows 3x3 tiles - you can even view this in the editor - in case you wanna do your own study. Yet, this just doesn't bring us any closer to understanding the hex values.
Still I'm not sure how to calculate the value, the way you suggest, so really it would be great if you had an imgur (or any other free photo hosting site) profile and could show us your suggested method with an image *hint hint*
If you mean that we should somehow compare with the image size values, then the image measures 192x174. These values can be found when viewed in decimal.
Okay so Baronus made me think (shame on you Baronus )
I've found the image positions. Easiest viewed as Decimals. At 000000e5 - hex value 17 = 23 and 00000184 - 05 value 5. This matches with ResHelper info.
Flags are animations positioned at 0,0.
Well I've found some new info but it's getting too late to dig deeper tonight. Will continue later..
____________
|
|
iliveinabox05
Honorable
Famous Hero
|
|
posted March 21, 2018 07:12 PM |
|
|
Sorry I'm a little late to the party, but while looking back through old posts to figure out what I need to do in order to get a new / edited object into the editor to test passability editing, I stumbled across an image on the second page of this thread showing where the flag data is located.
I then went back and looked at Namerutan's documentation for objects, and I have discovered where / how the flag data should be inserted if it is absent
If you have an object that does not have a flag, check out the first 2 bytes of the file (which Namerutan has labeled as file format). If it is not 06 00, change it to that. (Warning, if the first two bytes were 03 00, you need to remove another field near the end of the file or things will likely crash, so let's ignore that file type for ease of testing).
After you have changed the first two bytes to 06 00, navigate down to the sub type code and sub type text. AFTER these fields, you skip the next byte (which is for the object depth), and this is where you should insert the flag data. The first byte of the flag data must be 01, which probably means true for a flag being present. Then there are 8 bytes of data, which I'm guessing are two 4 byte integers to specify an x and y offset for the flag's location.
I know you've been waiting for this Michael
This is something that should be quite simple to add to my resource editing app
|
|
iliveinabox05
Honorable
Famous Hero
|
|
posted March 21, 2018 08:52 PM |
|
|
Also, just wanted to confirm that Radmutant is correct about finding where the extra data starts at the end of the file.
The 0x 00 00 00 00 is a 4 byte Integer which tells you how many Shorts (2 byte numbers) follow.
So, 03 00 00 00 means that three 2 byte numbers follow, as in:
03 00 00 00 | 00 01 | 10 30 | aa 00
Before that are two 4 byte Integers for an x and y offset to draw the entire set of frames at.
Additionally, if the file format (first two bytes of the file) is 03 00, then there are an additional two bytes after the x and y offsets.
|
| |
|
|
