Good vs. Evil
- Thread starter Randomguy404
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
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 
48. No it's an asdf joke.
It must have been a really long time since you watched it cause that was one of the best ones.
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:
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.
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?
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.
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.
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 >_<
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 >_<
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.