Good vs. Evil

GamerwithnoGame

Over-Achiever
Jan 29, 2015
2,808
1,507
224
51. Its never easy, dealing with these things. It took me a long time before I was ready to admit I had a genuine problem. Its a good first step though :)
 

GamerwithnoGame

Over-Achiever
Jan 29, 2015
2,808
1,507
224
48. @triggerfinger12

upload_2019-1-18_9-0-19.png
 

lenscas

Over-Achiever
Jul 31, 2013
2,015
1,799
248
50 I worked a bit on arena_keeper again.

There was a moment where I decided to rewrite what I had in typescript in react however after I wrote some code I decided against it so, now I'm back with the rust code.

My current plan is to move all character handling into an agent instead of having that be done by my components. This has the following benefits:
  • Game logic and view logic both should be able to run in their own thread.
  • More precise re rendering of components whenever a character updates. Instead of the whole list being re-rendered only the components showing that character are.
  • No more charWithIdType. Characters are stored in a hashmap, which means that I do have access to a key.
  • I can easily decide which order I want to show my characters in.(nextKey=nextKey + 1 or nextKey=nextKey - 1)
  • I don't need to pass so much stuff around/components are less dependable on each other.
  • The game logic is MUCH easier to move to a server if I for some reason decide to do that. No idea why I would but.. its a nice side effect.
  • Maybe more?
Right now the only reason that the agents work in the same thread as everything else is simply because there seems to be a bug in Yew preventing agents that have the "Public" reach from being created. Once that is fixed I should be able to change the reach to public and it should work.

The reason I decided against using typescript with react is simply because it didn't was as fun. For one, I had to implement things that either Yew already did (agents) or code that I already wrote. Sure, that was something that would quickly stop but still. The other reason is that I wouldn't learn as much from arena_keeper if I wend that route which brings me to the last reason: I already use react+typescript at work, using something else for my own projects is nice.
 

lenscas

Over-Achiever
Jul 31, 2013
2,015
1,799
248
50 so.... today wasn't the best day.

I worked some more on arena_keeper but hit a nasty bug. For some reason it appeared like this simple piece of code was totaly miss behaving.
Code:
js!{
console.log("in buy before? test", @{id.to_string()})
};
let m_chara =self.to_be_chosen.remove(&id);
js!{
console.log("in buy after?", @{id.to_string()})
};

What this should do is print the current id, remove the value with that key in the hashmap and print the id again.
This, seemed to work EXCEPT when I used it to remove the first one in the list. In those cases it would print the correct id as expected but REMOVE the last one.

Now, if you have no idea HOW this could even happen, I am totally in agreement with you. To make matters worse, debugging Rust code that compiles to WASM is a pain to debug. I can't use normal debug tools, there are no source maps to map the WASM code back to the Rust code and all I can print are strings.

For those that are curious about what was the cause of this bug: the piece of code I showed worked perfectly fine. It was my code that renders this list that broke. Rather than simply removing the component corresponding to the removed character Yew reused it by shifting which character belongs to which component up. (so, the component that renders character 1 now renders character 2. The component for character 2 now renders 3, etc, etc) and discards any components that are left.

It does this by calling the "change" function of the affected components, which in my case simply returned true as I totally forgot that yew works this way. This meant that they never got updated to the new character they are supposed to render and thus just showed their old one >_<
 

duckfan77

Popular Member
Mar 18, 2013
80
683
118
51 I mean, I can understand the pain of debugging with just strings. I've worked on what are effectively embedded systems that I can get console prints out of, but not do single step execution, and because of the hardware linked to the system, testing locally for single stepping it isn't an option, let alone viewing variable states.