Jump to content

suma

BI Developer
  • Content Count

    3202
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by suma


  1. What you wrote makes sense and agrees with my observations - that there are no terrain shadows, slopes are only shaded relative to angle from the sun. That is not really a terrain shadow implementation, but a workaround. Nevertheless, it works fine and looks good in most situations.

    There are terrain shadows. They are a lot softer than object shadows, but they are there. If they should be visible, the sun needs to be lower than is the hill angle. If you set time e.g. to 6 AM, you should see shadows under steep hills.


  2. Strange. I have run the mission, switched to the map, and I can see our units blue, enemies appearing in read, our units fire at the enemy, enemy is soon killed and disappear, but no orange appeared to me even for a brief moment.

    Tried it once more and seen the problem. It seems it is a bit random - sometimes it shows, sometimes not.


  3. At distance yes but not when you walk right past a group of friendlies to mount the vehicle and they fire on you the instant you get in.

    If you want that I don't see that it would be hard to script but harder to prevent.

    As this should be already fixed (see http://forums.bistudio.com/showpost.php?p=1996146&postcount=2) perhaps you might want to check the new version first? If you still see something you think should work in some other way, feel free to report it.


  4. I'm still having getin problems.

    In this one BLUFOR kill the enemy AI infantry and the driver of a truck.

    Your're a BLUFOR M2 gunner.

    When all OPFOR are killed dismount the M2 and go and get in the truck,as soon as you mount the truck your killed.

    http://www.sendspace.com/file/s24e4x

    I confirm I can see the problem. There is one short moment in which the vehicle is still considered enemy (even if harmless) and already active (there is a driver), and in this moment BLUFOR units engage it. I will check what can be done to prevent it.

    I have attached a repro which is a bit simplified (less units, shorter distance to run).


  5. Using 83261 on Veteran, all BLUFOR died, but several of the OPFOR with weapons also were killed. I agree that more emphasis should have been focused on the firing OPFOR rather than the vehicle. Wouldn't they be seen as more of an immediate threat? Given that BLUFOR has two .50 cal MGs, all the OPFOR should have been wiped out.

    AI currently prefers attacking the truck, as it thinks it is likely to contains soldiers in cargo space, therefore by destroying the truck they hope to kill those soldiers as well. Moreover, the truck is easier target for them at that distance. I agree in this particular case their decision might be wrong, but it would be hard to come with a general solution. Unless there is some case where the mistake is more obvious is shown, I would prefer not trying to fix this.

    Moreover, it seems at that distance they are actually unable to realize directly the soldiers are enemies. What you see is therefore like this:

    - BLUFOR fires at OPFOR truck, because it is recognizes as a target.

    - OPFOR soldier fire at BLUFOR, as they can see they are firing at OPFOR target, therefore they must be BLUFOR

    - BLUFOR recognize OPFOR and start engaging them, but they are already late

    When you delete both the truck and the MGs, both sides are just standing and nobody is firing.


  6. Looking up/down doesn't work for me either, gun moves, but the view stays the same

    Edit: Alt key doesn't work either, the view just stays as it regardless of mouse motion.

    Confirmed. It is result of fix http://dev-heaven.net/issues/22974, which has broken the head movement completely.

    A fixed version should be ready tomorrow.

    ---------- Post added at 20:30 ---------- Previous post was at 20:30 ----------

    Yes mouse is messed up.

    I am seeing a problem with units firing on empty vehicles.

    I have some BLUFOR come across an EMPTY URAL(ZU-23), they ignore it as there's no one near it, there's no enemy in the game yet as it's just a test.

    However if you try and have the BLUFOR get in the truck using a getin waypoint they attack it for a while before getting in and driving off if it's still drivable.

    Great. I understand what is causing the issue, it is how condition in http://forums.bistudio.com/showthread.php?p=1994314#post1994314 was implemented. Fix should be easy.

    ---------- Post added at 21:13 ---------- Previous post was at 20:30 ----------

    I am seeing a problem with units firing on empty vehicles.

    I have some BLUFOR come across an EMPTY URAL(ZU-23), they ignore it as there's no one near it, there's no enemy in the game yet as it's just a test.

    However if you try and have the BLUFOR get in the truck using a getin waypoint they attack it for a while before getting in and driving off if it's still drivable.

    I think I have fixed it, but not having your repro, I am not sure if I have fixed exactly the problem you have seen, as what I have seen was a bit different (they got near the car, and instread of getting in have destroyed it). If you can attach your repro mission, I can verify my fix fixes your problem as well.


  7. Interesting idea. I am afraid such conditions are a bit too much complicated (target state needs to be knows very often), but perhaps something similar could do. One simple attempt: as long as there are any group members alive in group owning the vehicle, the vehicle in working state is considered to be dangerous, as the group members might still crew it.

    A change like this was implemented in 83273. It takes the distance of the units in group into account as well to certain extent.

    The careful and experienced part of me tells me I should not mess with thing like this at all as this stage, as I can easily break many things. The brave and adventurous part of me tell me it is only beta and if it does not work out well, we can always revert it. Please, test extensively - as a result of this change AI can engage empty vehicles which were not engaged before, provided there is some crew ready to board them.


  8. I guess that's a confirmation, even if "DCDeadBody" != body count for some reason.

    However the longer you run the mission the more the gap between CAN FIRE count and (real) body count is noticeable.

    It does not necessarily be equal. The event is triggered when a unit sees either a kill, or a dead body. It is triggered only once in each group, but it can be triggered multiple times if multiple groups see the dead body. On the other hand, it does not have to be triggered when nobody discovered the body.

    The primary reason why this "danger cause" exists is to provide some reaction when safe units encounter a dead body without seeing the shooting, which is typical in stealth scenarios.


  9. As far as AI logic goes, I would say have the AI treat an "empty" vehicle as hostile when:

    The vehicle was most recently hostile while occupied AND known hostile forces are still within ~250m (or more?) of the vehicle.

    OR

    Known hostile forces are within ~50m of the empty vehicle AND no friendly forces are closer to the vehicle.

    Interesting idea. I am afraid such conditions are a bit too much complicated (target state needs to be knows very often), but perhaps something similar could do. One simple attempt: as long as there are any group members alive in group owning the vehicle, the vehicle in working state is considered to be dangerous, as the group members might still crew it.


  10. So, AI now knows when vehicle is empty even behind tinted windows and inside the hull? Is this a joke? Coop players will again jump from vehicles when deadly AI unit is spotted... in order to keep it safe (i.e. mission objective)...

    If you see that, by all means, provide a repro and I will check what can be done against it. Or would you prefer the "engaging obviously empty" unfixed instead? Or what other options do you see?


  11. I have no leverage, other than my credit card. :) And Suma, you and I all know I'm going to snap up the next title voraciously, but nevertheless, I think the word 'unacceptable' is fairly well chosen.

    From a business point of view, what you write is contradictory. If you still buy products from us, and are still decided to buy even more, you show us with your credit card then they are not "unacceptable" for you. "Bad", "shame", and other words could describe what you feel, but "unacceptable" does not seem to fit.

    I understand we could do many things better than we do. However, let me present the same choice in other words. Let me, for the sake of argument, assume that we are unable to fix more bugs and polish the product more than we currently do. Would you prefer the scope of the product to be reduced in all areas (landscape size, number of vehicles, number of weapons, number of missions) to 30-50 % of what it is now? We are not only a bussiness, we are still to certain extent (even if it is now less than say in 2001) a kind of "partisan" company, a bunch of guys playing with their toys. We sometimes do some work just for the heck of it. Yes, I could perhaps fix some bugs instead of implementing butterflies, but the downside of it could be I would pretty soon leave the job because of frustration.

    As for the leverage, I would say you have other leverage. You have leverage of voicing you oppinion, and you also have a leverage of the option to help us. I cannot repeat it often enough, for many bugs the most important thing to have them fixed is to have a high quality bug report with good repro steps in it (I intend to write a blog article about it soon, which should explain this in more detail).

    I agree with DMarkwick that having 977 open issues by itself does not mean much. Almost each shipped product has a huge list of open issues. As long as the issues are "annoyances", and not "showstoppers", such situation seems acceptable to me.


  12. Confirmed static units not being attacked.

    I couldn't reproduce the invulnerable unit problem.

    Thanks for reporting. Exactly the kind of issues I was afraid of. Fortunately this one was very easy to fix (83212). If there is nothing more serious waiting for us, it seems like a win, but still more testing will be needed to confirm this.


  13. From what i've experienced, "CanFire" event is reported extremely rarely, maybe something is missing there.

    That is quite possible. Once I see some repro, I will be probably able to tell more quickly. Note: this intention of this event is to handle a situation when you can fire on a target which could not be fired on before.

    Finally a different question: neartargets target position accuracy is shared for all the units in a group right?

    Yes, it is shared in a group. I can imagine it would be possible (and not very hard) to simulate reduced the accuracy when we can be sure some particular unit cannot see the target, but nothing like this is implemented now (and even as simple as it sounds, it would require to proceed very carefully with implementation, and it would require lots and lots of testing once implemented).


  14. @ Suma

    Are you talking about the danger.FSM in \ca\characters\scripts\danger.fsm used for:

    	class CAManBase: Man
    {
    	fsmDanger = "Ca\characters\scripts\danger.fsm";

    To me it looks like there is no reaction defined in the "EnemyNear" or "CanFire" event:

    Is see a following reaction on canFire event, in the Stop to Fire state, which should make the soldier to stop for 4-8 seconds (or shorter when target is destroyed) on a fire opportunity (duration controlled by the Timeout and Destroyed condition):

    _stopUntil = time + 4 + random 4;
    if (vehicle _this==_this) then {_this forceSpeed 0;}


  15. Any planning on further working on AI target selection/prioritization?

    I see the AI still having problems in CQB, meaning moving units usually prefer keep moving instead of stop and fire on target, when threat are very close.

    In these cases Neartargets info and knowsabout tell the threat is well known, usually.

    I bet this problem can be somewhat related to the (low) frequency of visibility checks ?

    Near targets visibility is checked very frequently, therefore I doubt this is the cause. Most likely there is some reaction to the situation missing or handled improperly. There are reaction like this in Danger FSM for events "EnemyNear" or "CanFire", perhaps some tuning for them would be enough.

    I think getting a repro sample and a CIT ticket might be able to get it enhanced/fixed faster.

    Exactly. If you are able to create a good repro (esp. if the repro is short, located on Utes or Desert, and full automated, not requiring any interactions from the player), I can check the cause and we shell then see if it is fixable easily or not. Posting in a CIT is preferred, but if you feel that too clumsy, you can also post it here and somebody else can create the ticket later.


  16. [83156] Fixed: AI units no longer firing at empty enemy vehicles (http://dev-heaven.net/issues/5183)

    While the fix itself can be considered minor, it was done in quite sensitive area of code (it can affect what targets does or does not AI engage anywhere in the game), if the fix is to stay in the game, extensive testing is needed now, especially in campaign missions and other complex missions, to confirm some key aspect of the AI target selection is not broken by the fix.

    The fix consists of:

    - changed conditions when an enemy vehicle is considered as "finished"

    - changed criteria when AI engages a target

    - changed criteria when AI stops firing at a target

×