[BUG] Bugs in crate code

I think there are a couple bugs in the crates code.

Firstly, the ping ID needs to be stored in an array, not a single variable, since there can be multiple crates at one time. It should be like this in the SelectivlyPlaceCrate and CheckCratesRule functions:

CRATES_PingIDs[playerIndex + 1]

instead of just:


You may want to double check for sure though.


Deleted a bunch of stuff that no longer applies.

There’s another bug with crates too; they’ll never spawn you a free ship, because the Crate_Ships table has a comma right after the last brace, which means the table isn’t valid, so you’ll never end up with a free ship. I think it messes up a few other things with the crates when you’re supposed to get a free ship too.

good catch !

What file is Crate_Ships in?


Never mind. I found it. You are correct.

Another bug:

In the SelectivlyPlaceCrate function, you use the Subtitle_Message_Handler function to display a message and play a sound when a crate is spawned. However, this function checks for the local player, but there is no guarantee that every player will be iterated through (the loop can be exited early), so not all players will see this message or hear this sound most likely.

I edited post #1 in this thread because I was looking at the wrong version of the crates script, and was posting the wrong code sections. The other stuff I mentioned later still seem to be accurate though.

Next, in GetBestCrateLocation at line at line 130 of crates.lua, cratePosition is sometimes {0,0,0} which causes errors later in the code, and prevents the crate from spawning at all. (Though there is no error in the log.)

So I turned the crate position into a random unit vector when this happens by inserting the following code:

-- if the crate position hasn't moved from the map origin, create a random unit vector
if ((cratePosition[1] + cratePosition[2] + cratePosition[3]) == 0) then
	local theta = srandom(crate_seed, 360)
	local phi = srandom(crate_seed, 180)
	cratePosition =
		cos(theta) * sin(phi),
		sin(theta) * sin(phi),

theta and phi need to be in radians.

And technically, you don’t need the local keyword on them.

theta = srandom(crate_seed, pi)
phi = srandom(crate_seed, pi / 2)

No, Lua uses degrees.

Also not sure about the local bit.

No, [url=https://www.lua.org/pil/18.html]it doesn't[/url]: Quote: All trigonometric functions work in radians. (Until Lua 4.0, they worked in degrees.) You can use the functions deg and rad to convert between degrees and radians. If you want to work in degrees, you can redefine the trigonometric functions:


“Most of them are only interfaces to the homonymous functions in the C library, except that, for the trigonometric functions, all angles are expressed in degrees, not radians.”

Fair enough.

(At least I had a source to back up my statement – even if that official source was wrong! lol)

The source is not wrong. You chose the wrong source.

No, the source was wrong.

Until implies every version prior – not “up to and including.”

Interestingly enough, the source code for Lua 4.0.1 includes this tidbit:

** If you want Lua to operate in radians (instead of degrees),
** define RADIANS
#ifdef RADIANS
#define FROMRAD(a)   (a)
#define TORAD(a)     (a)
#define TORAD(a)     ((a)*RADIANS_PER_DEGREE)
static int math_sin (lua_State *L) {
  lua_pushnumber(L, sin(TORAD(luaL_check_number(L, 1))));
  return 1;

So it could be entirely possible (somewhere) to have compiled a different version of Lua 4 that runs in radians… Lua 5 (or rather 5.2.3, which I have source code for) doesn’t allow this option.

Okay, yeah.

1 Like

Many of these bugs are really ancient, and I’ve already post a topic about some of them that I’ve found:

(P.S. I think the line numbers have changed a little in the file comes with HWRM 2.1, but basically the main codes are the same)

360° = 2*pi, not pi :stuck_out_tongue: ^^

1 Like