Good vs. Evil

  • 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
58 So no, there isn't a good copy constructor. As far as I know, at least in c++ a well written copy constructor is basically a deep copy, or at least copy of everything that would be reasonable to copy and would matter to the user of the class. The default isn't, but it can't be because things outside the class don't know how it is structured.
 
57. I'm still mystified. But then I am old, and uneducated in these matters.

I have fallen behind on all the series I like watching on YouTube, this makes me sad.
 
59 Unless this is what @duckfan77 was talking about, Could you do a thing where it's like the "Save As" function for documents? Where a new copy is created, but it leaves the original untouched. But maybe that would flood the system? Idk.
 
59 Unless this is what @duckfan77 was talking about, Could you do a thing where it's like the "Save As" function for documents? Where a new copy is created, but it leaves the original untouched. But maybe that would flood the system? Idk.
60 I wish it would be so easy :P
A deep copy is basically a "save as", which JS hasn't build-in. Also, its possible to make your own function that loops over all values and make a deep copy yourself. However, the json trick is often faster because technical reasons.
 
61 and... now another thing which I actually have no idea on how to fix properly.
I have a group of inputs that either all need to be empty or they all need to follow the rules set in them (thus for example require, max,min, etc)

Problem : you can't run code before right before the browser does its checks, as the submit event happens after it checked everything (and doesn't fire at all if the check failed)
Solution to that : remove the input group if they are empty, then do the check yourself by setting the form to "novalidate".
Problem 2 : this removes the nice boxes showing the user what he/she did wrong...

I guess I may be able to get around this by checking if the form is set to "novalidate"
If it is -> remove the group if its empty-> remove the "novalidate"-> stop this event and fire it again
If it is not -> reset the form to novalidate->do the code as normal. (thus submit the form)

But.... that again seems very hacky.... anyone another idea?
 
61 decided to just don't validate those inputs at all on the client. Yes, it doesn't look as good but at least it will work
 
63 so... I am in the process of totally rewriting the stat system that rp_tracker uses to make it a LOT more dynamic.
It so happens, by pure luck that the character creation code on the client doesn't even need to be changed. I actually really expected that to blow up so... I am kind of happily surprised :)