[+city] Parking Garage -- please help test new map before 2.3

[H-Hour]

Its in the trunk

[BTAxis]

Oh, right, sorry.

I think I figured it out. Your tile definitions are indeed wrong. What happened is that you were assuming that the letters in the borders connect to the letters in the borders of the neighboring tile. This is not the case. They connect to the *body* of the neighboring tile. So if you have "i" in the border of one tile, it can only connect to a "+i" in some other tile.

For example, take these two tiles, which in your fixed assembly are vertically connected:

Code: [Select]

tile +craft_drop_firebird
{
5 5
0 i i i 0
j +da +d +da k
j +ca +c +ca k
j +ca +c +ca k
0 ce ce ce 0
}

tile +strv_rail_btm2a
{
5 3
0 c c c 0
j +ea +e +ea k
0 i i i 0
}

These tiles can't connect, because craft_drop_firebird only has +d in the top row of the body (not the border), while strv_rail_btm2a can only connect to +i. It also doesn't work the other way around, because craft_drop_firebird can only connect to +i on the top side while strv_rail_btm2a doesn't have +i in its body at all.

The following setup will allow craft_drop_firebird and strv_rail_btm2a to connect:

Code: [Select]

tile +craft_drop_firebird
{
5 5
0 i i i 0
j +d +d +d k
j +d +d +d k
j +d +d +d k
0 ce ce ce 0
}

tile +strv_rail_btm2a
{
5 3
0 c c c 0
j +i +i +i k
0 d d d 0
}

d matches +d, i matches +i.

[H-Hour]

Thanks for taking a look BTAxis. I think you've actually inverted them and that is what makes them appear incorrect. But I think the tile definition is correct (at least between those two tiles). +strv_rail_btm2a should actually go BELOW the dropship tile, and the borders/bodies should match on the c's and e's. The +i's connect them to street crossings, and should not constitute a border between these two tiles. I've attached an image as it may be a little easier with a visualization.

[BTAxis]

Hm, okay. In that case I'm not sure what's going wrong. I'll try messing with the ump to see if I can make it work.

[BTAxis]

Okay, I got your map working (took some time to compile), but it takes extremely long to load up (over half a minute). That's worrying. I'm also getting an assert when I zoom up to the UFO on the roof of the building (attached), which may or may not have to do with the fact that the map extends slightly above 512. I also noticed some wrong levelflags.

The good news is that I made a test assembly with only craft_drop_firebird and strv_rail_btm2a, and they do indeed connect properly to one another, so it seems the tile defs are in order (at least in concept).

Code: [Select]

assembly test
{
size "3 4"
+strv_rail_btm2a "1 1"
*rm_drop +craft_drop_firebird "1 1"
}

Still no clue why the garage assembly doesn't work with the *rm_drop tile.

[H-Hour]

Yeah, mattn has been struggling with that assertion for a while now. I think he thought he had it fixed, but I guess not.

Any ideas on the long loading time? Is it the # of brushes/lighting that's likely to be causing the problem, or the scale of the textures?

My understanding was that the lighting was "baked in", so to speak, during compile so it wouldn't be loading with the map. And I don't think the brushes for this one building would be that much more complex than some of the larger existing maps (like the bomber). The scale of the textures is something that can be reduced, but I'm not sure if mattn would like that.

[Mattn]

loading times are number of brushes and texture sizes - i suppose the textures are eating to most of it (though this is just a guess, did not do any measurements yet)

[BTAxis]

mattn, would it be doable to make the loading of textures and such be part of the loading progress bar? As it stands the map itself loads up fairly quickly, but then the game gets stuck on "waiting for mission start" for some time and THEN it shows you the battlescape UI and gets stuck some more. It would seem appropriate to only switch from the map loading screen to the battlescape view when *everything* was loaded. Enough for the fact that for most maps it doesn't take all that long to get the mission started.

[Mattn]

hm. then it's not the map itself - but the pathfinding.

[Mattn]

btaxis, could you please post a backtrace for that assert?

[BTAxis]

Backtrace.

[H-Hour]

Interesting that second delay is the pathfinding. I really haven't had very much time to work on this the last week or two, but I would be interested in exploring that with you mattn (or anyone who knows the pathfinding well), to see if there's anything I can do to make that process shorter.

Right now I would say the second delay is as long as the loading screen for me.

[Mattn]

that would be duke, i'm a pathfinding novice

[MCR]

@ H-Hour:

If you want to improve your city with additional models you really should check out Sitters Homepage:

http://www.md2.sitters-electronics.nl/models.htm

Just a tip, if you need cars, toilet accessories, stairs & many other supercool models... 
I know we are using many of those already, but imho many others could & should be incorporated into our game also...

Sitters is a real low-poly/ high-detail modelling expert & we should imo use more of his skills than used already (Thanx Sitters !) to improve our stuff even more here !!!

[MCR]

...