Jump to content

donaldseadog

Members
  • Posts

    1,086
  • Joined

  • Last visited

  • Days Won

    60

donaldseadog last won the day on April 5

donaldseadog had the most liked content!

1 Follower

About donaldseadog

  • Birthday 01/30/1956

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    near canberra, australia

Recent Profile Visitors

32,536 profile views

donaldseadog's Achievements

Rising Star

Rising Star (9/14)

  • Very Popular Rare
  • Dedicated Rare
  • Posting Machine Rare
  • Collaborator Rare
  • First Post Rare

Recent Badges

109

Reputation

  1. This appears to have been corrected in beta relese 2024.001
  2. This scenario, and other thoughts, have spurred me on to write a small tool for modifying some attributes of in game platforms to better simulate surface (and semisubmerged) drones. Attached is a game save from this scenario where the suicide boats are low RCS and VCS and increased speed (I over did speed, so now max 55 kts). It should open and play with HCDB2 database but retain the platform mods (described above). A slightly different game play results. This scenario has spurred me on to write a tool for making minor modifications within the game to existing game platforms to better simulate this type of USV (and also UUVs) AGIvsUSV1.hpo
  3. TonyE has come up with a lead which has given good results, further testing and AIWindow.dll interrogation shows that a key identifier (unit's UUID) is not being generated for new units formed when a unit within a group is split by virtue of splitting the group (F8) but is copied from the original thus two units have the same (meant to be unique) Unit UUID. If the new and original units are together again in the same group then only one will land. In the screen shot, centre window, the data is for the selected group's units, the numbers should be unique.
  4. A third run, nothing new learnt: ABA group of 5 launched and then ACA group of one joined so that two ac from ABAjoin ACA and the orginal ACA joins ABA, then the two ACA ac joni ABA so have AB000 (3 original ABA ac), AB001 (1 orginal ACA ac) and AB002 (2 ac split from original ABA then rejoined) RTB all land except AB002, the two ac that were split and rejoin ABA.
  5. Nothing to show anyone here but I went thru a number of permutations of patrol, split, join and rtb and only one caused a problem. ABA, a group of 8ac; 2 split off into AFA which rtb and all landed, 3 split off and rejoined ABA, rtb base the three original (AB000) landed none of the split/join ac (AB001) landed but stayed loitering/landing, ACA, a group of 2 patrol and rtb, all landed, ADA and AEA, two groups of 3 ac set off to patrol same area, AEA joined ADA then RTB, all ac of both units landed. A second run: ABA, a group of 4 t/o, 1 ac split to new group ACA, group ABA joined to ACA so have: AC000 one ac split from original ABA; AC001 two ac joined from orignal ABA; RTB ACA and AC000 (the single ac split from ABA to form ACA) lands, remaining AC001 fail to land. A somewhat involved build up of 'glitches'? starting from the initial group split?
  6. This might be useful? I've stripped out the other air groups other than AEA and reduced its unit number to 3 (still single aircraft units). It is continuing toward landing (on final, wheels down, full flaps?). The two game saves are from TDs test and a second apart xxx.0004 2 sec prior, xxx.0005 1 sec prior, to landing. I think the LandAirEvent triggers during xxx.0005 or next second of play for xx.0004. At that point there are two units remaining in AEA, one unit landed and readying and two zero aircraft PHUnit^.MyPlanes listed for AAC. TESTm(3).0009.zip
  7. An interesting aside, you can join (F7) the carrier group AAC to some of the stranded units of air group AEA and one (sometimes but not always more than one) will then go thru normal landing. If join two units then only one lands and the second is stranded as an inflight air unit of the carrier group. That stranded unit can be split from the carrier group and sent to land F6 in the normal manner and it lands normally.
  8. I ran TD's TESTm.hpm in 2024.001 with my AIWindow addon caputring the moment that the group AEA's landairevent triggers. AEA consisted of 9 units each a single ac. Sceenshots attached respectively show the group now consist of 8 units (unit 00 not there) (leaving the game run no more land), the event data for the landairevent that to me only indicates that the whole group is to land on unit 00 of group AAC, and the interesting info for the base carrier that there is a single landed f/a 18 (60 min ready time) and 8 zero ac planes - so the code here is listing down thru the carrier PHCUnit^.MyPlanes. To me some of the landing process for the remaining 8 units has occured but not completed? I'll keep lookiing to see if I can glean out info more useful.
  9. If the order of magazines is now correct I think bases should be good also. I did check sum type tests comparing the magazine.csv file before and after a import/export/import cycle (with no edits) and it passed while before this new PE the same test would fail. But the test doesn't pickup correct magagazines assigned to the wrong platfroms/bases. To me the biggest problem in correcting DB is that the errors were random, so could be anywhere. I pondered using LazGUI to run thru the DB loaded into the game and look for weapons in magazines not used by mounts of that platform, but kind of hoped people with th eproblem would nut out something else
  10. I added landAirEvent to my catchers mitt in AIWindow, it doesn't seem to have as much info as I'd thought it would thinking about otherevents like Join and Split. I was a bit after my brain's 8.30 curfew so another run tonight and I might gleen more out of it, but I didn't see anything differing between the working air groups and the disfunctionals. Looking at what I see I assume when a land order is given (either from within course edit or raw from the game play) that the course is edited to put a leg to the landing point and the landairevent at that point. the landair event seems to indicate if it's the whole group to land or if it's a unit of the group (so far only seen this if the landing unit is a patrol in a group eg carrier group). when the whole group it gives no info on the units or their structure. What seems to happen is that not all units land but also one ac from at least some of those units does land. Another thing is that the receiving unit (base unit) seems to get a plane entry allocation but with no ac in the plane, ther will be one of these (usually) for each unit that is hng up without landing clearance. So I'm guessing some of the landing processing is occuring? Maybe flight leader of lead unit isn't keeping track of his group makeup
  11. Control Tower defect The units that are stuck I think come from units that had originally been part of the original group but had been split off (F8) then joined (F7) back to the group. Maybe when the LandAir event was written for the group it cocks up the number of ac in those rejoined units as I think usually the rejoined units do get one ac to land. Should we get more data re that?
  12. the MS access runtime won't let yo ulook at that much detail (Mine won't anyway), but most of it you can see in the annex_mags.csv file in commondb/res folder
  13. OK, this type of corruption I think I can capture as it it caused by a magazine item having a weapon ID = 0 (thus the unknown weapon), but there are other corruptions that place a valid magazine in the wrong place so catching only this type of corruption isn't sufficient. It probably shows up in TE's LazGUI export.dll.
  14. I did some tests last night and one thing I found was that the only time I tried to link to an existing pfdataxxx.mdb file it failed, I had to import from the commondb files. I was able to import a known problem db and correct the magazines, export, test in GE, import and export again (to double check) and re test. All was good. I also did some new modifications of platforms and tested that their magazines were correct and that the magazine.csv files were unchanged if the magazines weren't altered and all good. I can not think of a way of actually correcting a corrupted database other than going back to a good one and redoing the modifications. One of the problems is that the corruptions seems to have been random, so it's hard to know where to look. Do you have a note of what changes / additions you've made? Are there many?
×
×
  • Create New...