Due to rapid development of VCMI engine we’ve encounter a problem of adjusting wall’s graphics positions. Unfortunately, we haven’t found clear, single rule to calculate positions of those graphics therefore there is a need to manually adjust positions of all graphics for all towns or find the rule. It’s a simple but time-consuming job so we’d appreciate your help. It’ll make the development of other parts of the engine faster.
Wall’s graphics are stored in h3bitmap.lod archive (you have to unpack it). Their names follow the patter:
where xx is the town’s name of type shortcut (CS for castle, DN for dungeon and so on) and yyyy indicates which part of the wall it is.
yyyy for different parts of wall are as follows:
bottom tower - TW11
bottom wall - WA11
wall below gate - WA31
wall over gate - WA41
upper wall - WA61
upper tower - TW21
gate - DRW2
gate arch - ARCH
bottom static wall - WA2
upper static wall - WA5
Each picture requires (x, y) coordinates of its top left corner os it is present in original H3 siege. The file with sample positions (more or less positions from dungeon), which has appropriate format is here: sourceforge.net/apps/trac/vcmi/b … ll_pos.txt .
If you want me to do it I can try but I’ve never done anything with Heroes mods. So I’m “green”. Everything you need to explain step by step.
I can only play HoMM3
But ok, I can try.
I’ve unpacked h3bitmap.lod and I’ve got these files SDxxyyyy and what next?
Maybe it will be easier if you can write it in Polish on my PW account.
Of course if there is any other person, more familiar willing to do that, be my guest.
I haven’t been able to try out sieges as it crashes for me as I enter an opponent’s castle; vector index out of bounds exception in the server.
As for a formula, I’ve been dabbling with the same thing but for the spell effects. I think it might be better to use something else than the top left corner.
Looking at pictures like SGCSWA41 that has the same amount of cyan padding to the left and right as well as same up and down I’m thinking they might be using the middle of the picture as the origin, though I think this point may be different for the different types of walls. With the ARCH pictures it looks hopeless to find a good point of origin, no real calculable place in the images where they look like they’re showing off the same portion.
One thing you could do to is to change the dimensions of these pictures and see how the original H3 client responds. If you enlarge them to the right and bottom and they’re still at the same position in-game then it would be using the same algorithm with images drawn with a top-left origin.
I’d do it this way:
Get into a siege battle with the faction of your choice and take a screenshot. It should be 800x600 in size.
Open it up with an image viewer or editor that can tell you about the XY position of a pixel inside the picture (it should be (0,0) in the upper left corner, and (800,600) in the lower right).
Locate a piece of the castle you want to improve on, and find a spot on it that you could easily relocate in the picture from h3bitmap.lod. Example picture: img36.imageshack.us/i/86558320.jpg/
Here I went for the lower left part of the top left tower-thingy in the gate arch, which I marked for demonstrative purposes.
Get the XY position of this point, I noted it to be (477,255).
Locate the component’s image from h3bitmap.lod, which in this case is SGCSARCH.BMP. Now relocate the point you remembered, and notice it’s XY position. Here I noted (2,17). The picture with corresponding mark below. img198.imageshack.us/i/27303059.jpg/
Subtract X position of the latter from the former and the same thing with Y position, to make it simple:
(477 - 2, 255 - 17) = (475, 238)
Finally, this position should be inserted at the correct position in wall_pos.txt.
In this case I’d replace line 10 with “475 238”.
Wow that was fast! I had expected maybe one castle to be finished by the end of the week.
For big blobs of data (or code) you can use pastebin.
Yep it looks correct.
I was thinking of this. We would need the same job to be done for the puzzle map, which will also be a bigger undertaking as there are 48 puzzle pieces for each faction, making 432 pieces total!
These start with PUZ, followed by three letters indicating the faction, and a number from 00 to 47 for the piece number. Inferno has a duplicate of piece 47 called 48, I think it can be skipped.
When it’s time to implement the puzzle map interface it would be necessary to have this information, as it’s pretty much the majority of the work needed to implement it.
Would have to wait and see what Tow dragon or Tow thinks about it first though.
I was thinking that a formula might’ve made it easier for modders making new castles in the future, but even then they’d have to draw the pieces so they follow the formula so it doesn’t really matter a whole lot.
Yes, positions of puzzle pieces will be needed to implement an obelisk map. It’s not in my plans for nearest future, but of course that coordinates can be prepared now and wait for implementation (which may come little sooner if got them… or you can try implementing them on your own). You may also check in which order the puzzles are removed.
I suggest you and OnionKnight, to split the work to avoid duplicating it.
I think I’ve finished all 9 puzzle maps
This is Castle pic (used puzzle.pic + 48 parts): img200.imageshack.us/img200/179/puzzlei.th.jpg
I am sure that all pieces are placed correctly, but those blue seams still present (some of them will be hidden by interface, but not all of them)
I am resurrecting this thread because there are still some issues with the placement of walls and arrow shooters.
First I thought there was just a minor problem with shooter placement, and I reported it long ago on Mantis as #172. But then after playing the Arrogance4 map (attached to recent VCMI releases), I realized there are bigger problems - for some towns also wall/tower parts not being in their place (see new report #400). Here’s an example:
Creature in top row behind upper (static?) wall
Central shooter totally misplaced (for Rampart)
Central shooter graphics behind hero graphics
Two “upper towers” visible due to object misplacing at Castle (perhaps also others, see #400)
Heroes placed half a hex too low (on all battle interfaces I guess)
Upper tower shooter placed a bit too high
Lower tower shooter placed a bit too low
Now, I noticed that I can edit wall_pos.txt to adjust the position of some walls, but it seems that just by altering the values in there, I don’t really solve any of the above. Or I create others: for example, I could move the upper/lower towers a bit to make the shooters seem better positioned, but by comparing with H3 I realized the towers were fine initially and it was the shooters who were placed wrongly.
So my questions is: Same as I managed to figure out how to manipulate the wall_pos.txt file, would there be other files where I can - without real coding skills and special software - find the coordinates of the shooters and/or the hero, so that I can correct the values to what they should be?
And a side question (less likely to be in a config file, but who knows): Is there a file where I could alter the overlapping priorities of battlefield items? Above we have 2 such examples (wall above creature, hero above tower shooter), but there are some others regarding the overlapping priorities when it comes to front walls, and also in general during battles, the moving creature graphics often go behind static obstacles or other creatures (I think all these are reported somewhere in Mantis).
I know I could just wait until you guys find the time to solve this with probably less effort. But in case there is a chance I could fix at least partly some of the above (only need pointing to the right file or editor), I would like to give it a try. Thanks in advance.
I believe this is all hardcoded. The positioning of units and heroes is likely done somewhere in CBattleInterface.cpp, and the drawing order somewhere close by. The draw priority issue seems like it can be easily fixed by having objects placed higher up drawn first.
I’ll try to add shooter’s positions to that file so they could be adjusted.
There is no such file and I’m not going to make one. Currently it works like this: print dead stacks, go through all hexes from top left corner line by line, print all creatures that are not flying, then obstacles that are placed on this hex, then wall pieces. At last, print all flying creatures. The problem is that position of the stack that is taken into account is not the place where animation is shown, but the destination (eg. hex clicked by player). If you have a better order that doesn’t require the knowledge about hex under creature animation, I can change it.