uaktags / darkcurse Goto Github PK

https://drive.google.com/drive/folders/10SFfdPy1uIZ2EtU-DY6wnIosOVFmwO8Z

Add a button within the Inbox page, point it to /inbox/compose/new (compose view)
Compose view needs to have an input for usernames (1+). During submit, check the username exists and is not self

Reply should take the current msgId, read its body, and use that the footer of the body of the new message.
This will show a simple message trail that is common in email clients. For the user, they'll easily be able to reference what they're responding to.

Right now we have the crons running via node-cron and we should really look at having a separate service run this. The frontend server should just be worrying about rendering to the client while the backend server handles the heavier tasks.

Fortifications are necessary for Daily Citizen production, Higher Gold yields, and Turn production.

Fortifications need a db table to show individual bonuses that each fortification level.

Fortifications have a UserLevel requirement to be unlocked and a cost attributed to it to boost you up the next level

Each Fort has a name, health (max, current, [percentage??])

Activate link on player's profile for the viewer to choose to Message that player
open a new Compose page with the user as the default recipient
keep default body settings (empty) for compose window

For the training, I wasn't looking around to see if we had any examples of passing messages back on error/success but also felt the entire page didn't need to be rerendered, so I went the route of using AJAX. This added jquery and bootstrap-toaster to the mix, which is another dependency towards bloat, though still minimal. However, the Bank provides an example of just using res.render to bring the page back with the messages.

A decision should be made on which and go with that. Toasts would be great if we add in a messaging queue service though using websockets.

Due to the fact that I've been adding more and more features to existing controllers, the tests that were working before are failing and no new tests have been made. This is a fatal flaw of myself as a developer as I don't properly write tests like i should, and this should be fixed before merging back to Moppler.

have a field in the db for recipient's status and sender's status
Function should be callable via the button press on a message via the inbox or the message itself
/inbox/delete/:msgid ? then check that the user is either the recipient or the sender, and update the status accordingly

• Datatables
• Pagination
• Have it, on first load, navigate to the page with your name
  ref: https://stackoverflow.com/questions/43671648/how-to-programatically-jump-to-row-in-paginated-datatable

Right now the UserModel contains the gets for Offense/Defense/Spy/Sentry stats as well as the GoldPerTurn that the user should receive. As these only go up or down when being purchased or killed, the stats should get stored into the database. As we approach Attacking, we're not going to want to do these additional calculations as we waste time going through arrays of units calculating their bonuses.

The content of the page should go all the way to the bottom (or to the sticky footer if we add one).

This is with 77.5vh on the row's height:

I feel like that's a bit hacky though.