Jump to content

aka_tom_w

Members
  • Posts

    8,130
  • Joined

  • Last visited

Posts posted by aka_tom_w

  1. Originally posted by W1ll1am:

    iLikeThisGame,

    another way to tackle LOS tables is to store for each spot, for several directions (or pizza slices) from that spot the distance to which LOS extends in the best case.

    With this, you establish whether's a likely LOS/LOF for a pair of units u1 and u2 as follows:

    - los(spot(u1), dir(u2, u1)) >= dist(u1, u2) && los(spot(u2), dir(u1, u2)) >= dist(u1, u2)

    If this expression returns false, you're done. Otherwise, you perform a LOS check (and take into account all dynamics such as vehicles, smoke, vegetation, posture, etc.). Total: 50x50x2 table lookups (worst-case).

    The downside of such an approach (and the downside of LOS tables in general) is that it is expensive to repair these tables when obstacles (buildings, etc.) are removed.

    William

    ref: http://www.cgf-ai.com/slides_gdc2005.html slide 38

    just a note

    to make that link work the comma needs to be removed smile.gif

    web page in link above, its from a slide show from a video gamers conference..

    [ October 08, 2007, 03:15 AM: Message edited by: aka_tom_w ]

  2. The idea of more flexibility with respect to time has not gone unnoticed.

    I think in this thread both Huntarr and Rune have said its being discussed.

    I would suggest you could now interpret that as

    Heard

    Understood

    AND

    Acknowleged

    HUA!

    So I will say it again, the issue has gone up the chain of command all the way to the TOP, so therefore I would suggest an appropriate solution and response is being formulated. smile.gif

    (so maybe just give it some time, because what ever they decide will have to be tested to see if some beta tester or beta scenario designer (more importantly ;) ) can break it, abuse it, or find some gamey exploit smile.gif )

  3. Programers have a saying, a Creed if you will..

    I think it goes something like this...

    "The LAST bug will not be fixed until the LAST user is dead"

    so for now CM:SF is a work in progress

    the Marines Module willl improve CM:SF (probably with a new pay to play game release and a small patch to update CM:SF for free with new "marine module" fixes and updates, BUT NOT new Marine module centric units (you pay for those).

    so if the core game engine is patched or upated the patch will be free, IF new units are added to the game you will pay to update the units you have available in both games (CM:SF and the Marines module)

    I hope that helps

    [ October 07, 2007, 04:17 AM: Message edited by: aka_tom_w ]

  4. I suck at math smile.gif

    but, this sounds good to me:

    "Closing off a typical tic-tac-toe grid equals 36 independent square-corners" but only "16 shared corner points." 16+9-center equals 25 LOS checks versus 9 of the present center-point action spots. In this model, this equates to 5x the LOS checks (four corners, one center) for the price of less than 3x the "LOS computing power." Bottom-line, I have no idea if this is easily programmable but I assume that such a map-grid LOS table-check would resolve a huge number of LOS issues presently observed.... "

    I like the suggestion

  5. Bertram

    is this your explanation of current system of "Action spots"?

    THe 8x8 tiles used for spotting and is this action spot map at least a part of the cause of some of the other issues we are seeing?

    In the action spot is not the LOS *spotting) generalized and abstracted to a single point in the dead center of each 8x8 tile like the printed center dot in the middle of the hex in Panzer Leader/Panzerblitz map board?

    IF that is the case I am wondering if that is not causeing at least some the problems we are seeing?

  6. Originally posted by Chelco:

    You know? One cool thing I experienced a few days ago is how info on enemy contacts is transmitted via the communication links. I had a dismounted US Cav. commander on top of a hill and his platoon waiting at the hill's base. The Cav. commander spotted all type of units, but the rest of the platoon was out of sight so when I clicked any of the troopers, no enemy icons appeared. Silly me, the commander didn't have a radio so I moved a CFV closer to him and a few seconds after the commander mounted the CFV (remember it's equipped with good comms) all the other units became aware of the enemy contacts. Extremely cool.

    That is COOL!

    And I have never seen it, but I have never tried to test for it or look for it either...

    But I will be looking for that behaviour now!

    Thanks

  7. how about this...

    The more time Steve and the beta testers spend dealing with this "stuff" the less time they have to work on v1.05.

    Oh you say....

    Are they actually working on v1.05 already? :confused:

    Well what do you think?

    I think that might be a higher priority and a more effective use of their time. :eek:

  8. "It's also interesting to note that only 'important' bugs end up in the database - a clear sign that the current system isn't as efficient or as useful as it could be."

    Clearly, you MUST admit it must be the developer's choice to determine and establish which bugs are "important" in the data base. Remember there is only one brain in a Jar, its not like they have a huge vault somewhere full of brains in jars. (the bugs are fixed by just one person, the old fashioned way ONE AT A TIME.)
  9. Every developer can do things the way that works best for them, but personally I'd quit and work at my local grocery store before I went the route of having to manage a bug database that was open to the public. We've got one internally for beta testing and that's enough to manage. Important bugs mentioned here are topics of conversation amongst testers and they do get entered into the bug database if they warrant inclusion.
    This may be one of the most enlightening nuggets of wisdom Steve has offered. Everyone reading should know it is absolutely, completely true.

    "and they do get entered into the bug database if they warrant inclusion"

    So what does that mean, it means the bug needs to be able to be replicated and it needs to be deemed an actual bug meaning the behaviour in the example is not what was meant or intended to happen in the game by the designer/developer.

    You if can let them know which scenario it happened in and under which SPECIFIC circumstances, then they can test it and replicated and note for fixing.

    smile.gif

    [ October 03, 2007, 05:34 PM: Message edited by: aka_tom_w ]

  10. Originally posted by thewood:

    I don't dare comment with any intelligence on your specific scenario, but in tank v tank battles, you can always find situations where a tank can fire on another tanks that can't fire back. I would think that could be a real problem hiding behind a wreck and part of the tank sticking out.

    just two cents.

    ...this was a known bug sometime ago, but it should not show up in V1.04 :(

    I thought it was fixed

    [ October 03, 2007, 12:23 PM: Message edited by: aka_tom_w ]

×
×
  • Create New...