Jump to content

tadanobu

Member
  • Content Count

    18
  • Joined

  • Last visited

  • Medals

Community Reputation

1 Neutral

About tadanobu

  • Rank
    Private First Class
  1. I think you're referring to the alternative suppression debugging text and appear below each unit. They should change to other values/colours as the units suffer suppression. They have to be disabled with this line of code: //TEXT BASED DEBUG RATE (Hz). 0 = NO TEXT DEBUGGING. 5 = 5 UPDATES PER SECOND. tpwcas_textdebug = 0; towards the bottom of the HPP file. My apologies: Double posted when I tried to edit
  2. I think you're referrng to the alternative suppression debugging text and appear below each unit. They should change to other values/colours as the units suffer suppression. They have to be disabled with this line of code: //TEXT BASED DEBUG RATE (Hz). 0 = NO TEXT DEBUGGING. 5 = 5 UPDATES PER SECOND. tpwcas_textdebug = 0; towards the bottom of the HPP file.
  3. Hmmm... Anyway, I tested 2.07 this morning. Had exactly same results with coslx wounds as I noted yesterday with only tpwc debug balls enabled, and also with balls and text enabled together. However, I found that running text debug alone caused no problems whatsoever that I could determine. No civ creation beyond expected values, no noticeable slowdown and that while using coslx including slx_wounds, along with asr. I found the debug text to be more useful anyway, as its visible through obstructing obstacles and landscape features. Anyway looking good.
  4. Isn't a case of can't be bothered but constraints on time I have available to test. I noticed what I thought might be a problem and, because others want to use coslx and it's been pointed out that there might be conflicts between mixing it and other mods with tpwc, asr etc, I thought I'd share my observations on here for others to investigate further if so inclined. Remember I'm not trying to pick holes in coslx and I've stressed a number of times already that the problem I've seen is with tpwc debug enabled only. coslx with or without wounds included with tpwc debug disabled works fine.
  5. Ok to clear it up a little: Read "However, I'm using only a select part of the coslx system..." as "However, apart from wounds system, I'm using only a select part of the coslx system..." Did not use dapman while using coslx. Realised it would be redundant as coslx wounds probably had similar function. While using coslx, only other mod was tpwc. Wanted to try out find cover, dodge, no-autoengage, all files prefixed as slx_anim..., but did not want to use such files as melee, tank smoke, optics and other such files. Not going to list them all because there are simply too many. I noticed the civ count climbing with tpwc debug set to 1 and went through a process of elimination until I narrowed it down to the wounds system. I could be wrong but from my observation with and without debug enabled, with and without wounds system included in the coslx mod I had consistent results over a number of trials that satisfied me that I would not include wounds from coslx for my own personal use and have now returned to using dapman's mod along with those coslx files I'm happy with. It is very possible that I hadn't included something else from coslx that the wounds system depends upon in which case there might be a problem there. But for the problem only to show itself when I activated and deactivated debug in tpwc, it seems unlikely. ---------- Post added at 17:30 ---------- Previous post was at 16:58 ---------- Right, I have just retested with tpwc and the entire coslx mod (all files not just a select few, which admittedly might have left out some necessary dependencies). Nothing else. Civ count increases above expected values with debug enabled after the first casualty. Removed the 6 files prefixed slx_wounds I thought to be the problem in earlier tests and the civ count does not increase above expected values and then decreases as casualties are taken. Put wounds back in, civs increase again. Took wounds out once more, civ numbers again do not increase. Set debug to 0 and the civ count does not increase with wounds included in coslx. Seems to suggest there might be some incompatibilty between tpwc DEBUG and coslx wounds. Since I'm interested in only a small part of coslx, then I'm not testing it any further unless what I'm using throws up something strange.
  6. Hi again, Sorry I've been unable to test much over the weekend. But this morning I tried coslx (rather than Asr) and found that if you have tpwc debug enabled in latest 2.06 pbo, you will again get the increase in phantom civs after the first casualty is inflicted leading of course to game suffering crippling slowdown. I tested it a number of times and believe the conflict arises through the coslx wound system or its dependencies. With debug disabled the problem does not occur and I have been able to run a number of games without any problems. However, I'm using only a select part of the coslx system (the ai and animation enhancements), so you might find other errors and conflicts if you choose to do so. But I'm quite certain at this time tpwc debug (please note: DEBUG MODE ONLY) and the coslx wound system seem to conflict. There are other systems in coslx that I'm not personally interested in using or testing, but anyone interested in using coslx may find this of use as a jumping off point for their own testing. As a side note I have been using dapman's ai first aid sytem (http://www.armaholic.com/page.php?id=13841&highlight=DAPMAN) alongside tpwc from the beginning with no errors whatsoever, even with tpwc debug enabled.
  7. Been having fun with 2.05 script, 0.67 bdetect. No problems to report.
  8. I did very quick test of the amended 2.04 pbo and script with 600 unit battle. Just tpwc and cba. I ran my civ player character(allowdamage false) along the us line several times and saw just one us unit, an assistant auto gunner raise and not lower his weapon.But only this individual unit. His skill in editor seems to have very low default. The grenadiers always raise their weapons to fire grenades and lower them again when returning to normal fire mode. Machine gunners (it was these units raising their weapons that first brought my attention to the problem of sky watching) now seem to behave normally. However, spheres did not show in debug mode with either script or pbo and the enable/disable in the userconfig did not work so using pbo I was unable to disable debug. The civ counter kept me up-to-date of the civs being generated so I know it remained enabled. Sorry not really able to devote much time to testing today and so the info might seem a little bit incomplete and rushed. But I'm keeping things consistent so I think my observations may still be useful.
  9. Quick update. I just ran 2.03 and 2.04 and what I noticed was that in 2.03 the balls are instantly deleted, while in 2.04 they remain after unit is killed. Forgot to mention in earlier posts that the only adjustments I have made to tpwc is enabling/disabling debug. Haven't touched other settings because I've tried to make tests as consistent as possible. Regularly reset computer. I have steam version, so auto-updated to 1.60.87580 and latest (I believe) cba 0.8.6.182. I can run a 1000 unit battle at 4 fps lol. Just tried it and yes approximately 3000 civs were created which was to be expected with debug running. But I just comfortably ran a 600 unit battle on OA's desert island using 2.03 and you'll hopefully be encouraged to know that tpwc does not really add too much overhead. Lost a couple of FPS but was running around 23 FPS when the fighting kicked off.This is what I'm used to any way. I have to say again that 2.03 script seems the most reliable. I saw no unusual behaviour even in such a large battle. With debug turned on I eventually went down to around 15 FPS. Running on a toshiba with i7 quad and geforce gt 630M.
  10. ah I just ran some quick tests of 2.04, cba and no other mods. Not looking good. As soon as they become suppressed everyone starts shooting at sky except machine gunners who now spin around firing erratically mowing down their entire squad. This was using both pbo and script versions. Units used were plain us army rifle squad and takistani militia group. Default skills in editor. Playing veteran with both friendlies and enemies on normal. Tried with and without debugging enabled. Same problem occurs. I ran arma without tpwc as comparison and no such behaviour occurs. I ran 2.03 script again which runs fine. No shooting at sky but I did notice that when units become surpressed they shake their heads at the sky every so often. Have to go out for awhile but will do some further testing later.
  11. I run arma 2 OA BAF PMC steam versions and removed all other mods except tpwc 2.03 pbo and found only machine gunners (not automatic riflemen) aimed at sky. But other units behaved normally. I also tried altering both rank and skills in the editor but it didn't seem to influence this behaviour as far as I could tell. The problem didn't seem to occur at all when I disabled pbo and ran from the 2.03 script I tested yesterday. Ran out of time then to do any further testing so I'll check it out today. This is also the first time I've actually seen this behaviour, but it was quite obvious once it started so I'm sure I would have noticed sooner. I vaguely remember this behaviour used to occur in arma and the original op flash I think up until it was patched out so its not a new occurrence. Running the 2.03 script/bdetect 0.64 produced nothing unusual in the battles I ran yesterday, except of course the initial civ count (might itself be a problem if you run debug on a 1000+ unit battle and have 3-4000 civs generated at start up-haven't tested this yet, but may do today).
  12. ok I ran 2.03 from the script above and its stable. 50 east 51 west including player character 301 civ at start (does not climb after casualties are taken. Actually decreases as they do. 298 after first casualty). The ball counter reads 210 until first casualty when it then reads 207. Thought I'd provide figures for you to make out what you will from them. Maybe they'll provide some insight into what's going on.
  13. Ok I've done some quick tests of earlier script versions and what I've noticed is that from the very beginning the balls created a basic civ population every time. Hadn't noticed at that time because I always ran battles with civ pops anyway and there wasn't any extra overhead being generated from them. Up until 1.04, that civ population reaches a maximum figure then stops. I've also noticed that it falls as casualties are taken. Unfortunately on version 2, when you start implementing bdetect, the problem kicks in. The civ pop climbs to an initial figure, remains static only until the first casualty is taken and then starts to climb out of control until it reaches thousands. Hope this helps.
  14. I have just ran an 140 unit battle 3 times:first with debug disabled which ran over 1 hour without civ count increasing and no noticeable slow-down of fps and no momentary freezes;second with debug enabled using other objects as markers(snowmen) which I allowed to run for around 20 minutes again with no problems;third time I enabled debug with the original spheres and the civ count increased to 1000+ within 2.5 minutes. By 5 minutes I was experiencing momentary freezes at which time I suspended the game. This using 2.02 and 0.64. I've done this a number of times today with the consistent results. If I have time tomorrow I'll try running game on earlier iterations of the script to see if I can pinpoint where the problem first arises.
  15. I replaced the ball objects in the tpwc script and found that the civ count no longer increases. I tried other signs but anything with an EP suffix in the class name seems to behave exactly as do the balls by increasing the civ count. This was not an exhaustive test of such classes, however. What I found were that game objects such as ammo crates etc do not cause the same problem. I now have soldiers running around with pub signs or snowmen on their heads when they're suppressed, but civ count remains stable.I'm sure you can find a more appropriate object or elegant way to resolve this.
×