Jump to content

Volcano

Moderators
  • Posts

    8,310
  • Joined

  • Days Won

    13

Everything posted by Volcano

  1. Actually, after a discussion, we discovered that Sean and two of the backup TGIF hosts (myself included) will be out this Friday (not all for the same reason) and will not be available. So, it seems like the best thing to do is to put TGIF on hold this Friday, and resume it next Friday on 14 OCT, when the Firefight 79 campaign begins. I will leave the above scenario in the lobby, as well as the most recent Battlezone scenario, so if the community wants to try to get a game together at that time then by all means, you may use either of those scenarios if you like. Or take the Friday off and rest or go out on town. 😃 So, until next Friday the 14th...
  2. 7 OCT 2022: Border Dispute 2013-4363-FMU SPECIAL CONSIDERATIONS: Draft? Yes. Random CO selection? Yes. Minimum # players: 8 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.
  3. Whoops, I missed your post. I guess you figured it out since you were there, though. 😁
  4. 30 SEP 2022: !Battle for Lawfield Corridor v14-smaller-4363-OMU SPECIAL CONSIDERATIONS: Draft? Yes. Random CO selection? Yes. Minimum # players: 8-10 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.
  5. An update on the Firefight 79 campaign plan: I'll start it in two weeks from now, 14 OCT. This may be best anyway since I might not be available on 7 OCT anyway. So, if anyone wants to participate, then it will get going around that date. 👍
  6. Best thing to do would be to copy the UK voices into the ES voices folder, then say no to overwrite. Then once that is done, all the ones added should be automatically highlighted in Windows, and you can cut and paste those to a separate folder. Then you can record over them, or made new files but replace the filename, and then copy them back into the ES folder. Essentially SB is looking for those files but if they aren't present, it doesn't care - it just doesn't play a sound IIRC. Hopefully that answers the question...
  7. OK thanks for the info. Seems we have a few more bugs to work out...
  8. Right, this is a known issue all the way back to SB1 (that you can remain in the vehicle with no turret crew until you jump away, then you are locked out). It would certainly make more sense to eject the user to F8 view when the occupied crew position is damaged, but there are technical reasons (I believe it is another problem that goes back to the 'no external view setting' that can be set in single player, rhetorically where does the user get thrown to when dead in such cases?). Need a sort of purgatory for the dead, where they are at map view but not in any vehicle until they select a unit to jump to, I suppose.
  9. That said, we will look into the behavior where vehicles seem to auto-burn when killed by HMG, I'd say that is the main issue here. With that old behavior removed (if it is what is happening here), then we can improve things by either introducing some kind of post-death fire occurrence that happens reliably, no matter how the vehicle is killed, and of course look into updating the Ural trucks at some point.
  10. Sorry, but that is not practical. It is not going to happen where every single truck is gone back over and special fire damage cases are added on fuel tanks, just for a purely visual case of fire after it is destroyed, at least not anytime soon. So it has to be stated here clearly to avoid a false assumption that something will change here in an update: it likely will not. These old trucks like the Ural die, but as I said above, here it is again (maybe better summarized): People expect vehicles to burn now for visuals, that is understandable, but the best way to do that is if we introduce some kind of post-death fire ignition probability, as I said. These vehicles die the same as they did before. This is not a vulnerability issue, its a purely visual issue. The Ural truck is old, and needs to be updated in general. There is only so much that can be done to it, in its current form. We do the best we can to make the new features work with old models, but it only goes so far (think of the missing 3D crew on some of the oldest vehicles). When old vehicles are updated, they get all the new feature support (think of the M1064 recently). Older models will not visually get destroyed as nicely as newer models do, given how it all works, no matter what we do. Sorry, but that is just the way it is when working with a mix of old and new models. The more vehicles SB adds, the more challenges come with with it like this. We just have to accept that some vehicles don't get visually destroyed in the same way as newer ones will. Beyond that, I see no reason why the maingun hit in the same place that causes a fire with HMG doesn't also cause fire, but that might be some special behavior going on determined by how a vehicle has died (as in, something that may be the case going back to SB1 where vehicles killed by HMG will burn automatically - the assumption being that it was probably some ancient behavior created because it was very hard to tell if vehicles were dead or not when the vehicles lacked visual detail: we should investigate this).
  11. Ah, well that makes more sense - and it's why this should be clearly described in the post. Yes, I think the assumption is that the AI gunner will always be able to "see" through a vision block of some kind (so standard behavior is that they can always see), but some vehicles do not have one as we see (but remember that the base behavior existed from SB1 where all the modeled tanks did have one). Now of course with a vision block/unity sight view available you can certainly pull off shots like that, I have done it myself by using the coaxial MG tracers/impact to figure out where the gun is pointing in elevation, then fire. The targets in the video are certainly within range to do that, but the AI doesn't also use the coaxial MG like this, it just "knows", but the overall effect is the same. However... In any case, its getting into the realm of where the AI gunners have to be dumbed down, and in this particular case there would need to be something specified on certain vehicles where the AI AFV essentially goes "blind" if the vehicle doesn't have a vision block view, and the commander is disabled. That would be the issue here (apart from improving the overall degraded AI gunner using the unity sight, of course).
  12. Out of curiosity, were you both in the same tank (multi-crew) when this issue was noticed, or two different tanks?
  13. So what exactly is the problem? If we can limit the guesswork from these reports as much as possible then that would be best (to make sure there are no false assumptions). Just describe plainly please. Is it that the AI gunner is still shooting with GPS and GAS damage? If so, why wouldn't he shoot? He can use the unity sight view, and the target is point blank range, but then again maybe I am missing the obvious without a clear description. Then again there cold be other damage, its very difficult to see what the text is in the video thanks to video compression artifacts.
  14. Yes, your assumption is right. Anytime something like this doesn't work, just replacing the vehicle with itself should fix it. You should never have to remake a scenario from scratch.
  15. Well, not sure why an extremely detailed description is necessary (because my explanation is the same either way), but OK: PCs placed on the map always have infantry unless you specifically go out of your way to remove them manually. You can see this by right clicking on the vehicle and selecting troops, where you can then dismount or detach them. When you destroy the vehicle, the troops still exist in the vehicle, it just destroy attached troops too. Once the scenario begins, it basically spawns dead troops in the vehicle, and here is where you get the duplicate IDs. If you really want to get rid of them, you could select the vehicles in question and select troops -> detach, then manually delete them all, but either way it doesn't matter.
  16. Well, I imagine you are hitting it with a volume of HMG fire, right? Not like consistently hitting it with one or two HMG rounds causing an explosion. If you hit it with the same amount of maingun fire, in the same places, then I don't see why it wouldn't do the same thing - but that is the issue I would think - one shot maingun versus rapid fire HMG or autocannon. Given that it has no armor, you would have to hit it with a lot of maingun fire, I suspect. So, with maingun, you would rarely see the truck explode. Also keep in mind that I think the supply version of the Ural has box in the cargo area that will cause an explosion, which is likely the version you are using here (or the fueler?), in which case the same explanation applies.
  17. Late reply here but as Grenny said and to elaborate a little bit -- Right, you cannot get the attached routes and waypoints that way, but I "copy and paste" units all the time using the Unit Templates feature. Just select your units and save them as a template, then place them on the map (they will be in the Default submenu). This is a good way to duplicate APC/IFV infantry platoons where you set them of a very precise composition, with vehicle and troop ammo types and so on.
  18. OK yes, IIRC once troops are destroyed, they are all split up to be one unit per soldier. Once they get revived, they are automatically rejoined, but I think in some cases the user has to rejoin them manually (depending on distance I think). This is OK. When playing a scenario, if it is saved in progress, you will end up seeing a long list of these Duplicate IDs from dead infantry. So, its a complicated situation. The Duplicate IDs to be concerned with are infantry IDs that match vehicle IDs (both a vehicle and infantry appear as the same unit designation in that dialog), in which case can cause critical problems with confusion between whether the unit is a vehicle or soldier (which was the original issue, years ago).
  19. I am not tracking. Out of necessity, I sort of swoop in and read bits and pieces of posts and I often reply without the full context because of it. If there is something somewhere that I am supposed to look at, then PM me the details please.
  20. Well, just because you saved an older scenario in newer versions doesn't mean the duplicate IDs would go away. It sounds like they are originally older scenarios, and the duplicate IDs were broken at that time, and its no surprised that they would still exist. They have to be manually fixed there. Not saying that is what the issue is, but if it is, then it is expected behavior. These are would be fixed by either removing the troops and replacing them, or by renaming the parent unit (with the troops inside) to some other name, then back again to their original name, or by renaming the troop units. Also, it's important: There is something that I remember that is tricky about the duplicate ID test. IIRC, when you load the scenario in the Mission Editor, it doesn't automatically check the duplicate IDs except I think for the first party. You have to actually swap to the other sides in the drop down bar in that dialog and press the "Check for duplicate IDs" button. Otherwise, once the mission begins in EXE Phase, then I think it checks all sides automatically when you open the dialog (that might be what you are observing here, or not). (However, if this is not what you are seeing, then I will need to take a look at the scenario.)
  21. AARs will not help, really. The fact is: if there is something wrong with the logic, then it would be apparent in a simple stripped down scenario. I was saying to reproduce the situation shown in a series of simple routes and see what happens. If it works there, then it should work elsewhere. If it doesn't work with 500+ routes and waypoints, then it implies that its a problem with the relationship between the routes and waypoints in the area. Otherwise what is expected here, that we go in with a hammer and bang on the code based on assumptions? So, I am simply stating what would be needed to give it a serious investigation, that is all.
  22. 23 SEP 2022: Future Wars-Oncilla-4362 Reminder: Please try to get the map before game time if you don't have it already, by using the Map Transfer Manager and querying the following UID: 7e0e7e2e-27c9-4aad-9a85-8974d8496cd5 SPECIAL CONSIDERATIONS: Draft? Yes. Random CO selection? Yes. Minimum # players: 8 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.
  23. I might at some point -- It's not like I don't want to do it again (although I always was unsure of the interest though), it's more about it being a huge ordeal to coordinate between all the teams involved and I just haven't had the time. Certainly it is far easier to run a campaign that requires very little coordination. But who knows, maybe I'll do it again in the coming years, given how long ago it was.
  24. To panic and bail out of the tank. 😛 In all seriousness though, the loader is usually the most junior member of the crew, usually trained in very basic operation of the tank (pull this trigger to fire the gun for example). Certainly a CMOH winning loader could hop between the loader position and load a round, then back to the gunner position and *maybe* fire the gun and possibly hit something, but the problem with that behavior in SB is that every loader would be Audie Murphy, with the user operating the gun just as effective as being without the gunner/commander (just waiting a long time to load), which probably isn't quire realistic as a norm.
  25. Another thing you can try is uploading to YouTube, with an unlisted link, or to DropBox, or OneDrive, GoogleDrive etc. Any of those would work.
×
×
  • Create New...