Members | Sign In
All Forums > Mission Scripting

What does this Assertion actually mean and how do I fix my mission? "pos.x < SPACE_SIZE_W*2"

posted May 21, 2012 00:22:07 by madings
I get the following exception every time I try to create a particular genericMesh object. I'd correct it but I don't know what it means.

Assertion Failed!

Program: C:\Program Files\Artemis\Artemis.exe
File: .\OBJGenericMesh.cpp
Line: 83

Expression: pos.x < SPACE_SIZE_W*2

((standard boilerplate text about
assertion failures telling you to use
JIT and so on not shown))

I assume this is a check to see if my object is outside the bounding box from 0,0 to 100000,100000 however it isn't. I know it's at position x=90000 and z=90000.

Also, I never got this error in version 1.61 of Artemis. It only appeared after the recent upgrade.
[Last edited May 21, 2012 00:25:54]
page   1
7 replies
aodendaal said May 21, 2012 06:10:34
Can you share the snippet of mission code that's loading the generic mesh?
hobbyist game developer
madings said May 21, 2012 06:45:36
Okay. I narrowed it down to these lines. Note the lines between the <!--HERE--> comments. Those are the lines that if I remove them, the crash no longer happens, but those lines are vital to what the script does.

<if_distance name1="WG03c" name2="Artemis" comparator="LESS" value="40"/>
<if_timer_finished name="lockgate_WG03"/>
<!-- play cool warp sound, play at the start so it runs while the other stuff is being done below -->
<play_sound_now filename="wormgate_warp.wav"/>
<!-- set destination marker to just under the destination gate -->
<!-- location (1111,0,1111) is a dummy. The real location is set by copy_object_property below. -->
<create name="wormGateDestMarker" type="genericMesh" x="1111" y="0" z="1111"
<copy_object_property name1="WG03d" name2="wormGateDestMarker" property="positionX"/>
<set_object_property name="wormGateDeskMarker" property="positionY" value="-500"/>
<copy_object_property name1="WG03d" name2="wormGateDestMarker" property="positionZ"/>
<!-- lockout the gate pair for a bit to give the ship time to move away after it arrives -->
<set_timer name="lockgate_WG03" seconds="20"/>
<!-- trigger spinny disorenting effect -->
<set_timer name="warp_howlong" seconds="8"/>
<set_variable name="is_warping" value="1"/>

For reference, the WG03d object was previously created with the following statement, and thus has a positionX of 48000 and a positionZ of 50000:

<create name="WG03d" type="genericMesh"
colorRed="0.3" colorGreen="0.8" colorBlue="1.0"
x="48000" y="0" z="50000"/>

The intent of the above code is to create an object called "wormGateDestMarker" which is located at the same X,Z coordinates as WG03d, BUT is located at y = -500 so it will be down below the destination. I am doing this because that's how I record the destination where the ship will end up after it goes through some funky warp effects. At the end of a timer, I'll teleport the ship to the location of the destination marker, (but with Y=0 instead of y=-500).

Once in the past I encountered a weird bug where if you tried to make two objects occupy the same space, it placed the second one at some totally random location instead. I wonder if that's happening here and the random location its picking is out of bounds. The main reason for me using y = -500 was specifically to avoid that collision. But maybe the new version of Artemis has different collision detection. I don't know. I'm at wits end trying to figure this out.
[Last edited May 21, 2012 06:49:54]
madings said May 21, 2012 07:30:21

I have verified that it IS indeed caused by putting two objects at the same X,Z coords (regardless of Y).

I replaced the three lines above in the "<!--HERE-->" section with these instead just as a test. Since I wasn't confident that the position of WG03d was set right, I hardcoded the numbers instead as a test, like so:

<copy_object_property name1="WG03d" name2="wormGateDestMarker" property="positionX"/>
<set_object_property name="wormGateDeskMarker" property="positionY" value="-500"/>
<copy_object_property name1="WG03d" name2="wormGateDestMarker" property="positionZ"/>
<set_object_property name="wormGateDestMarker" property="positionX" value="48000"/>
<set_object_property name="wormGateDeskMarker" property="positionY" value="-500"/>
<set_object_property name="wormGateDestMarker" property="positionZ" value="50000"/>

When I did that I got the SAME EXACT ERROR.

So then I changed the last line to this:

<set_object_property name="wormGateDestMarker" property="positionZ" value="51000"/>

And I NO LONGER GOT THE ERROR. By putting the second object at a new location not where the first was, it didn't trigger error. But my entire system depends on setting wormGateDestMarker to the same exact location. So then I tried experimenting with how close it was allowed to be, changing the number several times.

It turns out, it only needs to be different by one measly unit.

This line makes it crash, every time:

<set_object_property name="wormGateDestMarker" property="positionZ" value="50000"/>

BUT, if I change that value to 50001 or 49999, it works. Its only when the coordinate is EXACTLY the same that it crashes out.
madings said May 21, 2012 08:04:13
Nope. I spoke too soon. It still behaves weird when I make it one number off. It seems to push the original object about 5000 units aside when I put the second object right next to it.
aodendaal said May 21, 2012 13:13:49
Maybe it's the pushRadius of the player's ship that determines the minimum distance the 2 objects can be together? I see you've created your wormhole with a pushRadius of 0.0 (I'm not sure if it's supposed to be a float or integer) but all the player's ships in the default vesselData have pushRadius of 150, so maybe that's the minimum distance you have to create the objects?
hobbyist game developer
madings said May 21, 2012 17:19:52
Ugh. What a messy annoyance to have to work around an artificial limitation that doesn't even need to be there. As long as at least ONE of the two objects has a push radius of zero it should be okay. In fact I KNOW it's okay if I move the ship naturally slowly toward the wormhole in the game it's fine. Why I consider this a bug is that the behavior is different when you approach the object with impulse power than when the script teleports you there. When I approach with impulse power, I can be right on top of the object, no problem. Only when I teleport to the same spot that I could have legally impulse'd to does it make a problem. If the behavior of pushRadius when I teleport there is different than the behavior when I move slowly there, then that's a bug.

The other thing that makes this a bug is that the behavior with regards to the Y axis has changed. It used to be that the pushRadius was calculated correctly using all three coordinates. If I put the gate more than 150 units up or down the Y axis, the "collision" wouldn't occur. Now it seems to be 2D only using X and Z and ignoring Y.
[Last edited May 21, 2012 17:23:14]
madings said May 22, 2012 07:08:51
Error discovered!

This is due to the fact that I had mistakenly believed version 1.651 was the most recent version of Artemis, based on what was in the forums. It's not. What is incorrectly labeled as version 1.65 on the website for download is actually version 1.652 and is *MORE* recent than the patch posted in the forums, despite what you'd think from the filenames, which call it version 1.65.

Version 1.652 fixed an error with how teleportation and object pushing worked, which was the problem.

In version 1.651, if I teleport an object where another object was, even though it was above it and they weren't *really* colliding, it would bump the older object *really* far away, sometimes so far away that it was off the edge of the legal map space, thus triggering the assert failures.

1.652 apparently has fixed this, I assume as part of fixing the similar assert failure that the drone ships triggered (which I now assume had something to do with them being launched at a position too near existing ships thus triggering the same push-bump error and teleporting an object really far off the map).

Thom, if you're reading this, please please please change the name of the download file for version 1.652 so it really does reflect the fact that it's version 1.652 and not 1.65. I thought I had to apply the 1.651 patch to make it newer when it was actually a downgrade to do so, leading to wasting a lot of time trying to debug a problem that was already fixed.

Login below to reply: