Jump to content

missinginreality

Members
  • Posts

    468
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by missinginreality

  1. Hi Folks. Is there any way to get red arty delayed rather than just pound a support zone at the start? I've tried having it as a reinforcement and having it as a reinforcement along with its hq but nothing seems to get it going. I've even sat some blue guys in the zone waiting to get pounded. They have clear LOS into the area and not under any stress so there's no reason why it shouldn't go off?
  2. I concur with that one. Would be great to have a hold fire command that doesn't need micromanaging to enable units to infil more successfully.true that at the moment it takes a lot of work to stop them popping anything that moves in their sights while trying to sneak them someplace without giving away their position.
  3. Dima - have been trying a few different things and it appears not to be an issue with night and day but the fact that any unit mounted in those little UAZ jeepy things can't see anything. I can walk a blue unit up to 6 jeeps stacked with red guys and sit them there. Even with an AI plan set to assault they just drive over them even under fire. Only when the AI dismounts do they suddenly notice the blue chaps under their noses. Have tried with Syrian SF and regulars both seem to not sight when mounted. Maybe has something to do with the fact that the "man" unit symbol disappears when they are mounted and it just becomes the single vehicle icon. Whereas when blues are mounted you get the man and vehicle icon together??
  4. I read somewhere a while ago about this but couldn't find the thread again, sorry. Syrian SF seems totally unable to see Blue units at night. I've sat a team metres away from 3 mounted [in those little jeeps] SF squads and they just hang out then drive off when the AI tells them to. AI is set to all top levels i.e fanatic, crack, +2 leadership, active, assault etc seems to make no difference. Only daylight.??
  5. Just wanted to say that I think it's awesome you folks at BF read the forums and respond to things and take the thoughts onboard here. Nice one.
  6. 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?
  7. Now that'd be a useful thing.As would being able to use the panic/stop/evade button in WEGO. Sometimes it's a bummer to watch yr dudes committed to a waypoint that ends in disaster on the way.
  8. Yup that's what confused me - the front of the building? Not sure why there is a "front" and what relevance it has in terms of game and positioning etc.Can BF add anything I wonder?
  9. EB- I wondered about that as I was reading the posts but I haven't seen eveidence of it, seems that some of the dudes are in a good place for LOS while the others just hang out without contact instead of getting into a good position. I would've thought that even if just one guy made contact the others would group closer to him. Reciprically, if my unit is moving and comes into fire sometimes the rest just keep on with their movement order rather than take neccessary ocver before exposing themselves. Will playtest this a bit today after I've done some work.
  10. Thanks mate, yep that'd be choice wouldn't it? I swap stuff around for various scenarios I'm building with the thought in mind for a campaign plus related terrain mods and such like but yea, doing it for individual scenarios is like, heaps of hassle remebering which folders to move out in and out of the mod dirs.Would certainly be great if we could actually ADD new terrain type textures rather than replace the existing ones.
  11. Just playing with mods and thought would share this - start of a camo and pavement tile WIPs.
  12. Thought i'd add in a cents worth re Javelins. I've noticed that sometimes they don't just fly off and change course suddenly but will circle around and around corkscrewing down to finally reach the target. Very pretty at night mind. Oh and man the arms outstretched dudes in the middle of a firefight are the funniest thing. If a little suicidal.
  13. Just a quick query - in the editor when one goes to select buildings, each type has a little arrow pointing to one face which I am assuming is the entry? but then one can rotate the building and change where the doors are and they appear on different walls anyway so i was wondering is there a significance with the way the arrow points to the icon. Cheers
  14. 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!
  15. 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
  16. 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
×
×
  • Create New...