This is fine

Last night I sent out a request for a meeting today in the Skype group. No responses until I asked if they were okay this afternoon. I still went down to school all day today but the lack of any response hampered my morale and what i could do.
I did get what i set out to do done at least. Figure out how to actually take inputs into the program.
My issue was fairly simple but it took some digging to find; the game state had a function called notify which checks a OSEvent and sets a variable depending on what button is pressed, these variables is then used in the game state’s update function to call movement functionality within the player. The issue was that i never called the notify event. Thankfully since the method is grabbed from the lecture example so i was able to study that and find out where the function was supposed to be called.
This turned out to be in the os_event_dispatcher class, more specifically in the process function which is essentially the update function. This function loops through a vector of OSEventListeners but it did not include the one in my game state. So where should it be added? The os_event_dispatchers also included a function called attach which simply adds an OSEventlistener to the list process goes through. After a quick search this function was called in the abstract_game class. In my game this translated to the game state’s initialization. I spent some time trying to figure out why the same type of initialization didn’t work as i thought i needed to include something but it was just the namespaces being different again. In the end all i realy needed to was added this line of code in the beginning of the game state’s initialization:

helium::ServiceLocator::get_service()->attach(this);

Which adds the game state’s OSEventlistener to the list in the process function.

I also noted that in the example version it resets the keys variables each update loop but i couldn’t find out where this happens so i simply added a simple for loop that rests every variable in the keys list at the end of the game state’s update loop.

In other news Tommi talked to me about how he had corrected my first hand in again. Turns out he had corrected the same hand in twice but he told be why my visual leak detector couldn’t’ find the leak. the issue was that i hadn’t added a destructor to the LinkedList class. A simple fix so i guess that’s out of my hair for now at least.

The rest of the group has agreed to assemble tomorrow as of writing regarding the planning of the rest of the project and Gustav eventually leaving the project. We should should still be fine.