Little help with walls needed

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: … 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 :wink:
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:

  1. Get into a siege battle with the faction of your choice and take a screenshot. It should be 800x600 in size.
  2. 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).
  3. 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:
    Here I went for the lower left part of the top left tower-thingy in the gate arch, which I marked for demonstrative purposes.
  4. Get the XY position of this point, I noted it to be (477,255).
  5. 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.
  6. 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)
  7. 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”.

Phew, that got long.

I’ve made this config for all factions. Can someone test it in VCMI?

Mine is longer :stuck_out_tongue:
Why there is no [/spoiler] tags on this forum? :frowning:

601 500
528 350
468 291
469 127
523 32
568 35
399 274
476 238
511 347
488 79
593 511
548 451
468 309
468 186
529 57
565 31
403 271
459 220
509 364
491 103
591 516
547 452
474 298
487 190
546 66
579 36
400 253
470 187
516 365
513 79
594 514
560 451
484 316
479 151
531 71
568 27
408 254
476 221
521 376
501 92
591 512
535 445
477 323
486 164
542 66
560 26
401 262
473 240
508 372
503 97
599 495
558 448
470 296
476 180
522 56
564 15
395 260
470 164
521 305
493 53
585 508
552 440
482 304
475 189
533 69
567 30
407 266
477 235
510 380
498 107
599 505
545 441
486 306
497 184
525 80
547 27
392 253
482 236
521 382
507 130
607 505
508 346
467 299
470 147
520 41
575 28
408 254
485 232
508 346
489 97

OK. OnionKnight, thanks for explanation.
I just want to be sure. I’ve used your example.

So on first pic I’ve got [485;251] on second [9;13], so it should be [476;238].
Am I correct?
If yes, I can do it. Which Town should I start?
I do not want to make something was done by others.


Ok. I’m a “little” bit to late :wink:
Good job. So I do not have to do anything with this? ;(

Maybe this will be useful for some other job.

We are aware of many bugs in sieges and we are fixing them. I hope everything will be fine soon.

Thanks for the config, I’ve uploaded it to SVN. It looks very good.

We tried to find a better formula but nothing looked promising. Anyway, it’s no longer important since we have good positions :slight_smile: .

Wow that was fast! I had expected maybe one castle to be finished by the end of the week. :slight_smile:

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.

Nice. Added this to mine bookmarks.

I think I’ll do this one as well. I still have 3 days of free time.

Ivan, great and fast work, thanks!

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’ll consider adding it.

Then I’ll make format like this:
X Y N (N=1 - removed first, N=48 - removed last)

I’ve already made first 3 factions (Castle, Rampart, Tower), Inferno almost finished.

I will edit this post as soon as finish next faction (so anyone can work on other factions - just post here)

Finished Inferno, Necropolis and Dungeon. Starting Stronghold soon.

I don’t think I’m up to speed as I’m mostly focusing on the code, but Boulie might want to help out.

I think I’ve finished all 9 puzzle maps
This is Castle pic (used puzzle.pic + 48 parts):
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)

Config here

LOL great you do !! :sunglasses:
all these parts… ooh… :unamused:

Wow. All walls & puzzles in just a couple of days. Impressive work Ivan!

thumbs up :wink:

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:

Major problems:

  • 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)

Minor problems:

  • 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. :wink:

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.

Thanks for your reply. If you add shooter position, I can make the corrections.

For the rest, I’ll just wait for the hardcoded fixes. :stuck_out_tongue: