Crash on load project

I am trying to get Data Tables working.

Since the documentation on the individual steps in unclear, I guessed about doing the following:

  1. I chose “Add code to project” and then edited it from the link provided (automatically opened VS2013).

  2. I added the following code into the .h - didn’t touch the .cpp

  3. ` #pragma once
    #include “CardDetail.generated.h”

    USTRUCT(BlueprintType)
    struct FCardData : public FTableRowBase
    {
    GENERATED_USTRUCT_BODY();

    public:

    /** The 'Name' column is the same as the XP Level */
    
    /** The name of the card */
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = LevelUp)
    	FString Name;
    
    /** The type of Card: 0-Summon, 1-Spell, 2-Essence, 3-Enchantment */
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = LevelUp)
    	int32 CardType;
    

    };

    /**
    *
    */
    class TERRITORIESDEMO_API CardDetail
    {
    public:
    CardDetail();
    ~CardDetail();

    };

  4. I compiled this (eventually).

  5. I tried to add the .csv to my project but this type was not in the table row type list.

  6. I clicked “compile” in VS2013 rather than build solution.

  7. Now the editor crashes when I try to load the project. It fails to find entries in many core .dlls. I "clean"ed the installation, which forced the editor to recompile the project, but that now fails to compile.

Please help!

Could you add the logs here?

The current UE4 compiler error is:
“LogWindows:Error: appError called: Renaming an object (Class /Script/TerritoriesDemo.CardDetail) on top of an existing object (Class /Script/TerritoriesDemo.TemporaryUHTHeader_CardDetail) is not allowed”

The crash log prior to this is attached.link text

I really don’t want to sound bitter about this, but the only reason I got involved in C++ with this project is because the ability to define the table row ustruct is not available in the editor, despite how long the functionality to use .csv files has been in the core. The method of compiling and adding the necessary header file to the project is not clearly explained anywhere, because everyone just skips over that bit (including the documentation on this very site) - we non-C++ people have to figure it out the hard way just like UDK, even though we’re paying for UE4. Now my project is corrupt apparently because I clicked the wrong thing in Visual Studio, which means I get to start from scratch and mess around with the file system hoping I can copy files into the right places without the path interfering with the project build, just to get back to where I was, which was with code that compiled but did not appear to be accessible from within the editor. It may even be faster to just redo all my blueprints from a blank slate.

Please, Epic - write a product that doesn’t crash the editor just because the project won’t compile. We can’t fix what is wrong if the editor won’t load without needing technical support.

If you use version control just revert back. If not try these steps:

First of all, delete your Binaries, Intermediate and Saved folders, regenerate project files and build your project in VS.

Then, delete all assets that you’ve created for this data class. If you have any blueprints already using them then delete EditorStartupMap variable from your DefaultGame.ini, start editor and try to edit those blueprints. If those are GameMode or PlayerController blueprints and editor doesn’t start then delete GlobalDefaultGameMode variable in DefaultEngine.ini.

Third, this documentation is clear enough: Data Driven Gameplay Elements | Unreal Engine Documentation

C++ documentation lacks some API details (like Slate widgets features and usability guides and couple other things etc) but overall C++ code handling is documented good enough.


P.S. And last, don’t you think that blaming Epic for you not being skilled in C++ and VS is… incorrect? :wink: You have full source access (btw no “big” engine other than this one will give you that for just $20) and Epic support — that’s what you’re paying for. Editor is just a part of product, a tool, not a product itself.
It’s not Epic’s fault that you don’t even use version control and it’s not Epic’s fault that you’ve ruined your project by using tool you’re not familiar with. It’s like blaming car producer that you drove it without getting driver’s license and got in accident. Sorry for being so straightforward but that’s how it is.

I appreciate the answer,and will try it.

If you look here you will see exactly what I do: Problem. If you can direct me to where I’m going wrong I’d greatly appreciate it.

Just fyi, I didn’t plan to use C++ - I think I made that clear. Giving the user the ability to create the necessary structure from the editor doesn’t seem difficult to me, considering other custom structs can be made. I’m annoyed at struggling to get it working - but that’s normal with anything new as you correctly point out and there’s no point complaining about that. However, the code I’m writing is copied from the exact page you reference, so if I can generate a consistent method of crashing by following the instructions then surely the instructions could be better? Surely the editor should not crash in the first place while loading up code that correctly compiles? Is that not a problem with the “vehicle”? It’s not like I incorrectly addressed pointers to invalid memory areas - all that happened was I (initially) successfully compiled a .h file that contains nothing other than a single definition.

I’m not blaming Epic for the mistakes I have made, as that is part of the learning process, but I did not expect the editor to crash when it loads the project - that’s not a C++ issue, it’s a) a problem with insufficient information and b) a weakness in the engine itself. I may have tried to avoid C++, but that doesn’t imply I am a rookie coder - I persisted with UDK for 4 years writing uscript, and while that too had a sharp learning curve and I made hundreds of mistakes, at no point did I lose the ability to modify my project!

Thank you for taking the time to reply, and I apologise for my tone, but I’ve wasted the whole day on this and am no nearer a solution. Judging by the number of posts I have found requesting aid on this exact topic, no one has documented it accurately.

I have found the solution to the original problem, though the project seems unrecoverable at this point. At least now I can continue as I’ve got the hang of what needs to be where.

The default class constructor provided by the engine when creating the class through the editor is, flatly, wrong. This little piece of information is not in the documentation - I found it in reference to a reply to a query about an ENUM that wasn’t working. The final .h file in the doc’s should look like this:

#pragma once
#include "CardDetail.generated.h"

/** Structure that defines a level up table entry */
USTRUCT(BlueprintType)
struct FLevelUpData : public FTableRowBase
{
	GENERATED_USTRUCT_BODY()

public:

	FLevelUpData()
		: XPtoLvl(0)
		, XP(0)
	{}

	/** The 'Name' column is the same as the XP Level */

	/** XP to get to the given level from the previous level */
	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = LevelUp)
		int32 XPtoLvl;

	/** This was the old property name (represented total XP) */
	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = LevelUp)
		int32 XP;

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = LevelUp)
		TAssetPtr<UTexture> Asset;
};


UCLASS(Abstract, CustomConstructor)
class UCardDetail : public UObject
{
	GENERATED_UCLASS_BODY()

	UCardDetail(const class FPostConstructInitializeProperties& PCIP) : Super(PCIP) {}
};

I don’t know what documentation problems are you talking about.

I have just:

  1. Created file LevelUpData.h with code below (its from docs):

    #pragma once

    #include “LevelUpData.generated.h”

    USTRUCT(BlueprintType)
    struct FLevelUpData : public FTableRowBase
    {
    GENERATED_USTRUCT_BODY()

    public:

    FLevelUpData()
    	: XPtoLvl(0)
    	, XP(0)
    {}
    
    /** The 'Name' column is the same as the XP Level */
    
    /** XP to get to the given level from the previous level */
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = LevelUp)
    	int32 XPtoLvl;
    
    /** This was the old property name (represented total XP) */
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = LevelUp)
    	int32 XP;
    
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = LevelUp)
    	TAssetPtr<UTexture> Asset;
    

    };

  2. Built project

  3. Imported CSV and voila!

16428-levelup.jpg

  1. Here is Data Table after importing:

Piece of cake. I just followed the documentation.

There’s no need in creating UClass. you already have it — it’s UDataTable, it’s UE’s built-in data class. What you should create is a UStruct derived from FTableRowBase. You just create header file in your include folder (Source/YourProject or Source/YourProject/Public or else if you have more complex hierarchy) write a UStruct code derived from FTableRowBase and fill it with your custom set of UProperties according to your CSV file. The documentation says about it clearly:

Before a designer can import a CSV
file into a DataTable, a programmer
has to create the row container
telling the engine how to interpret
the data. These tables consist of
column names that have a 1:1 mapping
to a given code based UStruct and its
variables, which must inherit from
FTableRowBase to be recognized by the
importer.

The first column is expected to be
named Name and contains the names by
which each row is accessed for use in
game. Subsequent columns have a
variable name for a heading and below,
in the same column, the data for that
row/column intersection.

Well, yes and no. :slight_smile:

You, personally, know that you can create a .h file in a certain directory and Visual Studio will magically compile it. As a professed non-C++ user, I selected “Add code to project” from the editor menu, an action that seemed intuitive. But at this point I am dealing with a class, not just a .h, so I’m already looking at the documentation with different eyes to yours. What I missed was that the parent class needed to derive from DataTable (or apparently anything other than “none”, which was what I chose as the sample code in the docs contains no references to class). The quote you supply in a different reply below (which I’ll remind you comes from the section regarding the make-up of the .csv file, not the .h) also makes no reference to the DataTable class - just FTableRowBase, which is, frankly, just another meaningless type definition to me.

So you see, the documentation does explain everything to those who have already made UE projects that use C++. But for those of us who plan to use Blueprints for everything but are forced to delve into C++ just to define this structure, this documentation on that topic is insufficient. Seriously, do a search for articles begging for help on this topic and you’ll find a great many, including several that say “That’s the code I’m using but it doesn’t work!” That implies the documentation is incomplete in some regard.

I’ll say it again - I should not need to learn the in’s and out’s of C++ just to create a data structure in a header file, and the editor should not crash if I can’t get it right even though the code compiles. If I want to do more complex things with classes, then I agree absolutely that I must get as much information as possible about C++, and accept that mistakes in the code may compile but cause unstable behaviour when the game itself executes. But the editor should not crash when I’ve not written a single executable line of code in a project that compiles correctly.

What exactly is incomplete in data tables documentation?

The only thing I found missing is a how-to convert BP-only project to C++ without adding class from editor. Everything else is present.