NullReferenceException in custom map.

[planetfall]

Title.

The initial save works fine, but save and load and the game loop breaks. I discovered that the game's screenshot ability doesn't work while in this state.

Interestingly, if you let the game run, the particle sim continues. Struc and hull will get visibly damaged, but particle positions won't update graphically until you save and reload.

Game version: 64 bit standalone Linux v 1.0.3b2
Computer: Arch Linux desktop, kernel version 4.7.8-1
CPU: AMD FX 4300
GPU: EVGA GeForce GTX 750
RAM: 8 GB

[GoodMorning]

Key detail:

Which map? Is it one of your WIPs?

[planetfall]

Which map? Is it one of your WIPs?

Yes.

edit: original attached.

[GoodMorning]

Looks like something broke in GameLoaded. I can't look over the scripts now, but that might help.

[knucracker]

Ok, this is what seems to be going on.

In Popper.prpl
:GameLoaded calls @Init.  That turn calles @SetState, which in turn calls @DeployFields.  That makes its way to this call:

Code Select Expand

<-newParticles[I] <-nearestShip SetParticleTarget

But, newParticles doesn't exist (looks like it might have been removed with --newParticles after the call to @SpawnBox.  Since it doesn't exist, calling newParticles[ I ] on it returns "0".  SetParticleTarget internally takes that as a UID for something and tries to cast it to a "Particle".  That returns null in most cases (unless the game object with UID == 0 happens to be a particle)... and that's where you get the kaboom.

So I can fix this in the game (already have).  The PRPL API shouldn't blow up if you give it a UID for a non particle. 

[planetfall]

Ahhh. Brilliant. Thanks for pointing that out.

Then the question remains why Init calls SetState. I frankensteined this script together from the popper in story mission 7 and some code of my own, and didn't touch the init function. I'm rather confused as to why SetState is called in Init at all. It seems to be based on the CW3 sensibility that SetFieldCell doesn't persist in saves, which if true means scripts affect an entirely different field array than the one produced by painting fields in the editor... yet the editor lets me erase fields created by scripts, which renders the entire thing massively confusing.

[knucracker]

The correct assumption is usually the one where, "Virgil was confused by different games and different development states of the same game (TM)".  It sort of looks like the call to SetState (and hence the call to DeployFields) in mission 7 isn't really necessary.  It sets the state variables and then basically just calls DeployFields.  Since fields do persist, that isn't necessary.  SetFieldCell modifies the same fields that the editor does, which is why you can see them in the game and erase them in the editor.