Upper Floor Movements

[missinginreality]

Hey Folks, this is first post here tho been reading the forums avidly since got CMSF. First thing i ever bought after trying the demo. Awesome Fun!

Oh and man the CF team are like, responsive! I couldn't register to the forum from my email so i sent another and they fixed it in like an hour. Man that's good.

Anyway, onto the post, hope it's in the right place.

been doing some exhaustive testing on the whole movement through buildings thingo and thought would share the following with the group.This came about from wanting to figure out what the problem is specifically with units moving on "above ground" floors between buildings to get to the guts of the issue. here's what i found out and some deductions [possibly right or wrong I don't know] from the consistent behaviours demonstrated by the pathing.Might be of use to BF for their development also.

Oh this is with 1.05 by the way.

1 - I note a significant difference between movement behaviours on GF compared to anything above GF. [sorry, that's first floor in game terms, ground floor, earth level - I'll try and stick to 1F for ground level floors from now on.] thus have concentrated on 2F+ movement.1F seems easy.

2- My reasoning behind the problems are the fact that pathing does not recognise that 2 buildings are next to each other.Whatever configuration adjoining walls are in, pathing AI appears to still be treating them as external walls rather than adjoining walls.Thus in the editor it doesn't allow one to add a door into a 2F+ wall when adjoined to another building nor does pathing allow movement between adjoining 2F+ levels when adjoining walls are deleted as there seems to still think there is a digital gap separating the 2 buildings as separate code objects.

What demomstrated it for me on the coding level was when i put 2 buildings together with all walls and only 1 external door to get the units in. they'll happily blast thorugh the 1F connecting wall and move to the adjoining building [1 blast takes out both connecting walls] but move them up a floor, they blast the walls out between the buuildings so there is visually no walls between the two levels yet wont cross the digitalcode gap separating the buildings.THIS SEEMS A REALLY IMPORTANT CLUE TO WHATS GOING ON SO I PUT IT IN CAPS NOT SHOUTING

3- The workaround to use wallless balconies sometimes works sometimes doesn't.

4- 2 adjoining buildings having both their joining walls deleted still appear to pathing as being separate thus doesn't appear to allow the units to cross the gap between the buildings even though visually there isn't one.

5- deleting one adjoining wall and leaving another with a balcony and door still appears to the pathing as an uncrossable gap between buildings.

6 - i tried putting two buildings half a tile apart and connecting balconies without balustrades together - visually it is a seamless connection across the two buildings yet pathing does not perceive it as such hence my theory on the fact that two buildings together cannot consistently be crossed above ground level.

7- I say concsistently coz there is a partial workaround that takes serious micromanaging based on the chaps suggestion of joining walls having balsutradeless balconies. the confusion is that units standing on balcony of building A look like they are in building B coz the balcony is actually part of the floor of building B.if a face command is issued across the other side of the room of building B along with a move into that level then most if not all of the units will eventually get there in the end but it takes a lot of toing and froing.

Oh and sometimes they just ignore everything and move OK

8- Tho no programmer I have some limited experience in code and 3d work and would envisage that a different conditional state for the pathing code when 2 buildings are abutting i.e to ignore movement restrictions on walls missing above 1F or passing between buildings when within a certain distance would put paid to these problems. Obviously the pathing AI stops units walking of the edge of balconies, perhaps code could be aware when there was a balcony or floor abutting and remove this restriction for that time.

9- the other funny thing i noticed was that 2 buildings next to each other with connecting balustradeless balconies cannot be crossed. again this leads me to think that pathing ai just prevents units from moving across the intervening digital code gap that exists between separate buildings.

Oh question - in the editor what is the relevance of the little arrows that seem to represent the door direction next to the different building size icons. is this something relevant for where the building entry is facing? But seeing as the building can be rotated on the map and doors placed anywhere i'm confused by that.

That's all for now.Hope this is seen as constructive input for development rather than criticism coz I have heaps of fun with CMSF and grateful for all the work that's gone into it.And you fixed the blasting issue. Nice one, makes for heaps more fun in MOUT

[missinginreality]

Oh and something else that highlights the digital code gap between the buildings is when your inside a building and delete the first adjoining wall, the external wall on the next bulding is in the "external type" texture not internal wall type. So I'm wondering if there needs to be a bit of extra code in there to say that, when two buildings are next to each other one of the walls is deleted and the other becomes internal type.It would need a separate distinct new type of wall INTERNAL as opposed to EXTERNAL as they all are at the moment.

But I'm no programmer and what's going on so far with CMSF is awesome. Much gratitude and praise. Spend heaps of time in the editor making lots of little actions to play with. Much Thanks

[Thomm]

Good observations. You will most probably be pleased with respect to the progress that 1.06 will bring regarding these issues.

Good point about the internal/external walls. There is certainly room for improvement. There is also a mean complication: buildings can partly overlap each other, meaning that part of the wall can be interior and another part exterior.

Best regards,

Thomm

[missinginreality]

Thank you Thomm, yup that's a good point about the overlapping walls thing with a smaller building butting against a bigger one. Would mean the bulding models would have to be effectively coded to be single tile units both in x, y and z cubically, if you get what i mean, underneath the visual model. yues looking forward to 1.06 already!

[missinginreality]

just noticed something else that seems to demonstrate the "codegap" between buildings when units are above ground. Here are 2 single story buildings next to each other on different elevations with clear path from roof of one to door of another yet movement is not allowed between the two?