Jump to content

[HOUNDS] CptTrips

Members
 View Profile  See their activity

  • Posts

    332

  • Joined

  • Last visited

Community Answers

2

See answers

Recent Profile Visitors

1967 profile views
  1. [HOUNDS] CptTrips
    I was playing with this tool last night. Very nicely done. I don't think it gets enough attention. Thanks and cheers.
  2. [HOUNDS] CptTrips
    I've seen that happen alot If I spawn too near the IP or come in at an angle too extreme for it to get stabilized for a good run. It basically ran out of time to get within proper constraints for the drop before it reached the drop point. It is circling around to get lined up better for another run. Just as a test, try increasing the initial leg before the drop wp further out and make sure there is sufficient distance between the drop WP and the actual target triangle. Like at least 10 nm I think.
  3. [HOUNDS] CptTrips
    That's what I did in the sample mission I attached. Huey's aren't good again armor. I had two groups. A single Apache tasked with concentrating on the armor group. And a Client Huey group with door gunners to follow behind and let the door gunners mop up the supply trucks. Gave the huey some rockets too because...why not.
  4. [HOUNDS] CptTrips
    You could tweak a skeleton mission like this to your tastes. Cheers.Sample Convoy Attack.miz
  5. [HOUNDS] CptTrips
    You might start with some of these hints to avoid common pitfalls. https://www.reddit.com/r/hoggit/comments/s2n89h/sp_dcs_people_frustrated_with_the_ai_build/
  6. [HOUNDS] CptTrips
  7. [HOUNDS] CptTrips
    That was the error from the original log I posted before I disabled CSAR. I've put it back to the original mission now. Seems logical to get that working first before changing more variables. Others hitting my server were experiencing the crash so that argues against it being my local game machine. I realized I neglected to add StopGapGUI. Lua to hooks. So I'll try that this morning as well as turn off pure scripts. Don't see how those would effect this problem, but first step is to get a proper test environment established. If that still doesn't help, then next logical step would be to see if you hitting my server can repro the behavior. I dunno why others haven't seen it. Maybe I just set it up wrong. Still verifying that. I do remember a lot of the event problems I heard rumor of seemed to coincide with the versions since they added Dynamic spawn. That's been fairly recent. If it's "timing related" as ChatGPT suggests, my machines might be slight faster or slightly slower, just enough to hit the unfortunate state. But, one step at a time. It's not vital I get this working. No worries. I just hate mysteries. Cheers.
  8. [HOUNDS] CptTrips
    I’m just thinking out load here so bear with me. I just want to document some ideas while they are fresh. I vaguely remember seeing some discussions of problems others were having with the DCS event system. I *think* one of the issues is that when a client dies, DCS swaps the client object into a static dead aircraft object. It is possible that by the time the event code executes that has happened and the initiator is not a Client object but now a static. And the static would not have the .getPlayerName method implemented. This bait and switch was causing all kinds of problems. Event initiators were not always the object you were expecting. That sounds a lot like this case because the error in the log was: 2025-02-12 03:43:17.517 ERROR SCRIPTING (Main): Error while handling event [string "--[[ 250114 CSAR 1.9.2 ..."]:496: attempt to call method 'getPlayerName' (a nil value) So I take that to mean the initiator object did NOT have the getPlayerName method implemented as expected by the time it reached the event handler. Possibly because the initiator object had already been swapped out to a static wreckage object. Looking at the recent Moose git hub fix diff that I suspected might be related to the same type of problem I noticed: {See image below} Note the clause they added. Looks to me they added a check to make sure that unit actually had the “.GetPlayerName” method implemented. (i.e. The method reference was nil or not.) I could not find the exact discussion I’m remembering, but here is a reference that looks like it has some similar issues and work-arounds. Event Handling Problems NOTE: When you test this, make sure you are testing against an actual Dedicated Server and not the server you can run from the client. I have seen those not perform exactly the same in all cases. (Thanks DCS.) So to some extend ChatGPT may have been referring to this as “timing issues” sometimes being involved in errors like this. So in some cases the initiator object might still be a client object, or might have already been switched to a static dead aircraft wreckage object by the time the event handler code executes. Or I could be full of it, but something to consider. $0.02.
  9. [HOUNDS] CptTrips
    Just a datapoint... I tried turning off the CSAR but I still get a crash. I ran locally on my game machine as SP and did not get a crash. Not sure what that implies. I will DM you shortly with the login. I'm setting it back to the original mission. It will be back up in a sec. Thanks.
  10. [HOUNDS] CptTrips
    I'll look into that. I'm currently looking at the log a littler closer to see if I can see another clue. You might try the autostart first. I didn't do a manual cold start. Not sure why that would matter. I didn't hear any CSAR message. The game locks the instant of impact. As a debugging test, would you mind logging into my server and trying my test case to see if you can repro it that way? That would eliminate my game machine from the equation. If so I will DM you the login info.
  11. [HOUNDS] CptTrips
    I'm got some more possible test cases to try but let me specify my test case so we can test the same canonical action. 1. Log onto a MP Dedicated Server running the mission. 2. Go straight to [Olf Orte] UH-1H and spawn. 3. Perform Autostart sequence. No ground crew rearm\refuel. 4. After started, take off climb a couple of hundred feet and intentionally nose into the dirt and explode. 5. Client crash. null
  12. [HOUNDS] CptTrips
    The only Mods I have installed on either the server or my game machine are the mods you specified as required for the mission. They were freshly downloaded and installed the day I downloaded your mission. I'll test again and see if I can narrow down a pattern.
  13. [HOUNDS] CptTrips
    Hi Devil. Thanks for the quick response. Currently I am running on a Dedicated Server on a separate box from my client machine. Others, hitting the server with their machine remotely have seen the same crashes, so I assume it is not an environmental issue specific to my machine. I just recently pulled the mission so I assume it is the latest code. I haven't dove in deeply yet debugging. I wanted to just check if it was already a known issues. I suspect it has something to do with the CSAR code. I did see a hint that Moose recently fixed something concerning getPlayerName. https://github.com/FlightControl-Master/MOOSE/pull/2209 The mission doesn't appear to be using Moose, but maybe they saw the same problem and came up with a fix on their framework to get around it. I haven't reviewed that fix or whether it could be adapted to your script. Maybe that is a path your code guy could research. I seem to be able to repro it well, so if there is any testing I can do for you to help (like running a test version of the mission with additional script logging statements), let me know or I can give your code guy the pwd to my server and he can go try it himself and see if he can repro. Cheers, CptTrips
  14. [HOUNDS] CptTrips
    Hey guys. Looks like a lot of fun. Appreciate all your work. My squad has been trying it, but we found that when a player crashes their Huey, it is crashing their game. In the log I am seeing some errors involving getPlayerName. Have you seen any thing like this? see attached log. Thanks in advance, CptTrips [Edit] I did consult the Oracle (i.e. ChatGPT) . [10:58 PM] Yes, there have been some known issues with Unit.getPlayerName() in DCS, particularly when used in scripting environments like MOOSE or mission scripts. Here are some common issues: Returns nil for AI Units This function only works for human-controlled units. If you try to call it on an AI unit, it will return nil. Timing Issues in Multiplayer In multiplayer missions, getPlayerName() might return nil when called too early (e.g., right after a player joins but before they fully occupy an aircraft). A workaround is to use event handlers and delay checking until the player is fully in the aircraft. Issues with Clients in Multiplayer In some cases, getPlayerName() may not return the correct name when used with dynamically spawned units or when checking from a server-side script. Desync with Slot Changes If a player changes slots, the function might return outdated information for a short period. Using S_EVENT_PLAYER_ENTER_UNIT and S_EVENT_BIRTH event handlers can help ensure accurate retrieval. Workarounds: Use S_EVENT_BIRTH or S_EVENT_PLAYER_ENTER_UNIT to detect when a player spawns in. Add a slight delay before retrieving getPlayerName(), especially in multiplayer. Ensure the unit you're calling it on is actually a player-controlled aircraft. dcs.log
  15. [HOUNDS] CptTrips
    YEah. Boggles my mind. How hard could it have been to have them launchable. I mean its just basically a dumbed down cruise missile.
×
×
  • Create New...