Summer Work (Day 6)

Big success


    Over a week since I started this project I have finally achieved orbiting planets! All scripts compile without warnings or errors and the simulation works as intended. 
    The major problem I was dealing with yesterday was with UObjectIterator. It ended up, not surprisingly, being user error rather than the engine being broken. The just of the problem was that I was trying to get pointers to actors in the world, which is not possible with this iterator and as I later found out, not necessary. I found that there was also TActorIterator which has some differences that I don't understand but which are better for my use. Basically, the code had to go from this:
for (TActorIterator<ACelestialBody*> Itr(GetWorld()); Itr; ++Itr) {
  bodies.Add(Itr);
 }

To this:
for (TActorIterator<ACelestialBody> Itr(GetWorld()); Itr; ++Itr) {
  bodies.Add(*Itr);
 }

    Moving a single * solved the problem. So as I understand it, instead of trying to get pointers to the actors, we are instead getting references to the actors and converting them to pointers when we add them to the array of pointers.
    Interesting note here, before I switched to using the actor iterator from the object one, I tried to print the value of the celestial body that was updated it returned this:
Apparently this is what happens when you try to get the direct value of an actor and not its name.

    So at this point the code was compiling with no errors for the first time. I decided to run the game with two planets in the scene to see if it would work. Answer... no.
The editor froze for a few seconds then crashed. It took me some time to figure out what was wrong. I eventually remembered the debug feature that VS has where it will tell you of any unhandled exceptions that were thrown (something that crashing unreal did not do). Doing this gave me the place where the editor was having issues. It turned out it was with the UpdateVelocity function on the CelestialBody.cpp

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
void ACelestialBody::UpdateVelocity(TArray<ACelestialBody*> allBodies, float timeStep)
{
 for(int i = 0; i < allBodies.Num(); i++)
 {
  ACelestialBody* otherBody = allBodies[i];

  if (otherBody != this) {
   float sqrDst = (otherBody->GetActorLocation() - this->GetActorLocation()).Size();
   FVector forceDir = (otherBody->GetActorLocation() - this->GetActorLocation()).GetSafeNormal();
   FVector force = forceDir * gameMode->gravitationalConstant * this->mass * otherBody->mass / sqrDst;
   FVector acceleration = force / this->mass;
   this->currentVelocity += acceleration * timeStep;
  }
 }
}

On line 10 it needs to multiply by the gravitational constant that is held in the gamemode. The problem with this was that gameMode was nullptr and so the whole editor crashed. I then added to the if statement a check to make sure the gamemode existed. The editor didn't crash anymore but the planets also weren't moving because that part of the script wasn't running. I had three ways of solving this: 1) set the gameMode in BeginPlay for each celestial body, 2) set the gamemode on each celestial body from the game mode when it adds the bodies to its own array, or 3) just hardcode a number for the gravitational constant. 
    I had already tried number one and that resulted in the nullptr error so I went on to 2. I tried this: 

for (TActorIterator<ACelestialBody> Itr(GetWorld()); Itr; ++Itr) {
  bodies.Add(*Itr);
  *Itr->gameMode = *this;
 }
This had no red squiggles but errored out when I tried to compile. The error had to do with an "unresolved external symbol". I tried googling around for a solution but all I found was people adding third party libraries and not adding a new public dependency module to the Build.cs. Because I could not find a way to fix this I resorted to the third option. 
    I plugged in 100 to test, started the editor, and voilà; orbiting planets! I was actually so excited to see this finally work I actually pumped my fist in the air. I played around with this for some time, messing with moons, moons of moons, solar systems, and other wacky configurations. I now see just how important those debug lines are from the Sebastian Lague's project. That will probably be the next challenge, but as of right now I have no clue how I'm going to do it. 


Here's one test of a planet with two moons:

Comments

Post a Comment

Popular posts from this blog

Polishing the Foundation

Image
     This sprint was relatively uneventful; mainly cleaning up the existing foundational elements of the game (the first person character and spell component) and continuing to improve the necessary elements of the game like the pause screen. Player Character & Spells      The improvements to the player character come in two parts; the ability to have, use, and change spells, as well as interaction via an interface. Both of theses are as simple as I could make them. Utilizing inheritance from USpellBase using the spells is only really a single line, and changing out the spells we can use the NewObject factory to make a new spell very simply. FirstPersonCharacter.h FirstPersonCharacter.cpp      As for the interaction interface, it only consists of two functions right now, one to fire an interaction event and one to check if the object can be interacted with. This second function is used mainly to show UI on the player's screen like...
Read more

Progress Update #13

Image
  Niagara Asteroids in UE4     These past few days I have continued work on asteroids. Only that now I have ditched instanced static meshes in favor of getting my hands on the new-ish Niagara particle system.  Learning Niagara     I have decided that since this is an entirely new subsystem of the engine I would do everything in blueprint first, then transition everything to C++ when I knew it was working reliably. Additionally, because Niagara is still relatively new, the official documentation is sparse if existent at all. So with most tutorials at this time geared towards blueprint implementation, starting in blueprint will give me the highest likelihood of finding a solution to any problems I may come across. The Niagara Workflow     The first thing I learned about Niagara is that the workflow has changed significantly from what cascade was. Where in cascade (to my limited knowledge) you worked in one particle system where e...
Read more

A New Chapter

Image
     This week has presented the biggest change probably since the release of Mini Solar System; I was offered a full-time position as a junior programmer at Studio 369 which I was happy to accept. I start on Monday and I couldn't be more excited to work with the team there! However, this did mean though that my priorities shifted quite instantaneously. I went from working full-time on "RPG_Game" to preparing for this new job. This mainly meant getting up to speed on networking as that is the one area of Unreal Engine I feel I have a lack of knowledge in (I'm already proficient in UI, AI, gameplay, materials, and general backend work), and since 369's specialty is networking I figured I would come prepared. I did do a little work on "RPG_Game" but it was minimal just to tie up some loose ends. Unreal's Multiplayer Framework      As explained by the Unreal Engine documentation, "multiplayer programming [is] inherently more complex than programmin...
Read more