Jump to content

"Random" crashes


Recommended Posts

I've seen a few people report "random" crashes and I think I've found a pretty reproducible case that surprised me - probably because it's not what I think and is actually my fault....


I'm using the bad guy spawning method from the old RTS Prototype:

// Spawn an AI guy when key is pressed down
function spawnAI(%val)
{
  // If key was pressed down
  if(%val)
  {
     // Create a new, generic AI Player
     // Position will be at the camera's location
     // Datablock will determine the type of actor
     new AIPlayer() 
     {
        position = LocalClientConnection.camera.getPosition();
        datablock = "DefaultPlayerData";
     };
  }
}

// Bind the function spawnAI to the keyboard 'b' key
moveMap.bind(keyboard, b, spawnAI);

The camera is pretty high up, so when I spawn the unit (unmodified DefaultPlayerData) it falls to the ground. Not a big deal, max falling speed seems to limit damage to around 5~7 points. The thing is, the game hangs just as it hits the ground, every time.


Once I track this down - and I'm sure it's something I'm doing somewhere that seems innocuous - I'll be sure to post it here so everyone can comb their projects for whatever it is. My current best guess is it's an undefined sound file, missing sound file, or something in my onDamage() or onImpact() callback. Of course, it could also be in the AI scripts - you know which ones - which is why I'm so unsure.

Link to post
Share on other sites

Well, my thoughts on this one are that it's probably something I'm doing, and it's not a "crash." To me, a crash is an unexpected program exit - this is a hang/lock-up/freeze. So in all likelihood I've got a "look for this thing until you find it" when "this thing" doesn't exist. However, it did just crop up when I replaced the boombot with the soldier, and it persisted when I replaced the soldier with TorqueOrc (from TGEA). So I'm going to revert back to boombot and see what happens, then work from there.

Link to post
Share on other sites

Can't seem to reproduce that in the latest devhead at least on either of the empties, or any of the areas on outpost, like forrest, river ect... Since it's spawning from camera position, can you slap up a camera bookmark folks can toss in on one of those for doublechecking since that'll let folks jump right to it?

Link to post
Share on other sites

That you can't reproduce it is a good sign that it's on my end, as I suspected.


What I think most of the "random crashes" can be attributed to is stuff like infinite loops, where it looks harmless until the right conditions are met.


As far as a camera bookmark, I tried it from various heights and positions. It would be silly to place fifteen or thirty bookmarks for this test. I really just have to catch the spawn at the onImpact() and see what it's doing.

Link to post
Share on other sites

I had the same issue involving AI see this thread: http://www.garagegames.com/community/forums/viewthread/140222 and it did occur when AI were falling down when spawned at the start of a mission.


It had to do with an uninitialized value in the playerdata datblock as far as I recall, but I don't remember which one it was, but I did found out it happened when networking this field. I'll see if I can trace back which field it was.

Link to post
Share on other sites

Ah, yes. That's probably it right there. The AI Tutorial scripts (the tutorial-less tutorial scripts) are far simpler than the UAISK and don't really do any logging at all, and this sounds exactly like what is happening. So, two things to do: find which field and ensure that all datablock fields for all datablocks get initialized on creation to something that can be networked in the engine.


Thanks for the pointer Rich!

Link to post
Share on other sites
More reproducible crashes is good! Someone expressed the opinion a while ago that it should be very, very hard to crash the engine using scripts. I agree. The more cases like this e can find and fix, the better.

 

Man, I wish the same could be said about MB...

Link to post
Share on other sites

Alright, I've narrowed down the onImpact() issue - and it was crashing because of that one. I duplicated the entire DefaultPlayer datablock in the derived datablocks and the crash stopped happening. So what I'm wondering is if anyone has been tinkering with datablock loading. I remember when 1.1 was being prepped there was a load order issue where derived datablocks weren't being loaded because their parent wasn't loaded yet. Some work went into a system where if a datablock was a child of another and it couldn't be resolved it went into a dirty list and the resolution was attempted again after the first loading pass was complete. Ultimately, it seems that my derived player datablocks didn't get initialized with some or all of the parent's values, because it works fine when I fully define each "child" datablock.


And now to find my infinite loop....

Link to post
Share on other sites
derived datablocks weren't being loaded because their parent wasn't loaded yet

Let me be clear - you mean 'loaded' as in created on the server from a script file? Like:

 

datablock FooData(Foo: Bar) {};
datablock FooData(Bar) {};

 

Because AFAIK this sort of copy-constructing doesn't make it across to the network at all - the object doesn't retain any 'parent' information.

Link to post
Share on other sites

Ah, but it is supposed to. Otherwise what's the point? Why would I ever inherit from another datablock when I would have to duplicate everything anyway?


And it has been working correctly for a long time - DemoPlayer "inherits" from DefaultPlayer and is able to benefit from all of the same weapon state information that resides therein....


And in your code snippet that Foo datablock would at one time have failed as Bar hasn't been defined yet - but the system is now set up to make another pass and attempt to resolve any outstanding inheritances.

Link to post
Share on other sites

The copy stuff gets resolved on the server before data is sent to the client. It's basically exactly the same as a copy constructor - FooData(Foo:Bar) means copy all the fields from Bar first, then apply the overrides/additional fields below. Then Foo gets sent over the network with all those settings. It's not saving network bits, it's saving typing.

Link to post
Share on other sites

Right - but it still has to be resolved correctly on the server. The problem was related to something that Steve posted many times about - the order in which you exec() your scripts.


The issue I ran into should not have been an issue - my exec()'s are in order and DefaultPlayer is loaded when the derived datablocks are declared, so resolving the sound issue by manually copying the entire datablock definition isn't how it's supposed to work. In fact, until about three weeks ago, it worked as billed. The only thing I can think of is that either something changed on this front in the engine (unlikely) or I found another way to defeat the system inadvertently (much more likely).


Edit, edit, and edit again....

// Foo.cs
datablock PlayerData(Foo : Bar )
{
   /// ....
};
 
// Bar.cs
datablock PlayerData(Bar)
{
   /// ...
};
 
// loader.cs
// this should have failed pre-1.1 - should work now but I wouldn't count on it too heavily
exec("./Foo.cs");
exec("./Bar.cs");
 
// this should work always
exec("./Bar.cs");
exec("./Foo.cs");
Link to post
Share on other sites

Right, I get that. I was just confused when you said 'loaded' since I usually take that to mean the datablock loading phase of networking.


The whole copy cunstruction thing is kind of bizarre, especially the deferred name resolution. It's like TS is pretending to be declarative/immutable in this one very specific area, which is probably so rarely encountered anyway due to datablocks being created in the editor.


Meh.

Link to post
Share on other sites
  • 3 months later...

I know this post is a bit old, but I came across this very same issue recently and tracked it down to a scripting issue. The reason I bring it up here is the scripting problem arose from using a change to the PlayGui.gui that originated from...dun dun dun...Richard's RTS tutorial. The culprit was removing the GuiControl(DamageHUD) from the PlayGui. Obviously there are player scripts that will be trying to alert the player they just took fall damage and use the 'DamageHUD' that is no longer there.


Of course, if the goal is to ultimately remove the DamageHUD (because it does get in the way of AIPlayer click commands) then the scripts that deal with push/popping the damage direction gui elements need to be removed as well. For some reason, the scripts feel it is necessary to report to the player the damage direction they just took fall damage from...lol. Anyways, fixed an issue I was having with crashes due to player landing, cheers!

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...