set an custom Attribute " Pressure" for select TriggerVolume
and,i go back to ueeditor,to select the Attribute to an TriggerVolume,play in the ueeditor,ue4 is runing well
but,if i stop runing,and set the custom Attribute " Pressure" back to none,
play in the ueeditor again,
ue4 is crashed,
i try 4.13,4.16, also crashed
is this a bug?
i found delete this about the custom Attribute “Pressure”
if (Pressure->IsOverlappingActor(ActorThatOpens))
{
doingsamething();
}
and back to ueeditor,select the Attribute to none,run ueeditor again, ue4 not crash now
This is 100% normal behavior and it is actually OS that stops UE4. ATriggerVolume* (any varable with *) is memory pointer, in reality this is integer which contains memory address pointing to data, in this case object of ATriggerVolume. Problem is this is just integer, it is not smart and if objects is detleted or pointer is set in wrong way it points to invalid memory and if you call any function from that pointer (in this case Pressure->IsOverlappingActor()) OS will detect it’s pointing to unallocated memory and to prevent entire OS crash it will stop the application, UE4 has 0 control over it or else it (or your code) will able to prevent that situation which it should do in all cost.
Now “None” in blueprint system as well as reflection system means null in C++, null by C++ standard is integer 0, so your pointer is set to address 0 which for sure is invalid, but on other hand by setting pointer to 0 you know that this is state where pointer is not set, it is “None”, so you can detect that and prevent any function execution on that pointer. It is better situation having invalid pointer pointing to something random (which usally happens when object gets deleted, for example when it gets garbage collected, varables with UPROPERTY() will be automatically set to null), because it is hard to find out if it points to something correct, in worst case scenerio point can point somewhere allocated and random and OS will accept it and you will have invalid data in all varbales in that object, and most likely get crash on next used pointer in that object also pointing somewhere random but nonallocated.
Keep in mind that C++ code is compiled to machine code, a native CPU language (in case of PC it is x86 instruction set, different “CPU architecture” usally means different instruction set), it is not “grab my hand” scripting or manage language like C#, if your code is bad it will cause error in CPU level and OS is only on guard to prevent the error to flip over entire system.
What you writing in UE4 is not some special game code, it is module of the engine which will be included to engine code it self (UE4 is modular in similar nature as linux kernel if you ever work with it). So you not really writing special game code, you actually extending the engine it self, if something goes wrong in your code it will effect rest of the engine. For example if you loop a code infinity and create deadlock, you will deadlock entire engine not just your code. So if crash happens in your code it will crush entire engine, that the cost of having low level access via C++.
So if you know object pointer that can be null, you should check if it null before using it:
if(Pressure) { //this works the same us Pressure != nullptr
if (Pressure->IsOverlappingActor(ActorThatOpens)) { doingsamething(); }
}
You can short it this way:
if (Pressure && Pressure->IsOverlappingActor(ActorThatOpens)) { doingsamething(); }
If you use && operator, condition on left side is checked first if it fails condition on right side is not checked so crash won’t happen.
Extra note. Also not all crushes are CPU/OS related, UE4 is written under convention of “code assertion”
In other word UE4 code checks in many points of it’s code if conditions are correct before doing anything, if condition fails it will crash it self leaving suicide note in logs (you can find Saved/Logs of your project) with info on what condition failed (it will look like “if” statement which was flase but suppose to be true), you then need to go to engine code that error info points to and see what went wrong, you can also run debug and VS will show in stack list what pert of your code triggered unfortunate event. Some check are equipped with error message to directly inform you what went wrong. All of this is to prevent hard to debug hard crashes (like mentiond above where OS stops the application), by assuming that specific condition is bad and may cause instability later on. It is better situation then random crash because you can check whats gone wrong. You code can also use it it is check(condition) function.
Now as you ask “if this is a bug”? If crash (controlled with assortion or not) happens in empty project without your code involved it then it is a bug and you should raport it, if crash is caused by your code then it is bug in your code not the engine, or rether you introduced a bug in to the engine and it’s your responsibility to fix it. Remember you are not user anymore, as developer you will need to learn how to handle crashes by yourself