Jump to content

requinix

Administrators
  • Posts

    14,233
  • Joined

  • Last visited

  • Days Won

    369

Everything posted by requinix

  1. I've moved the thread to a place that might get some more attention. (No harm done.) It'll be pretty hard for us to figure out how to turn the design into a webpage if it's all in your head. Can you sketch it out graphically? Like with an image or using some free online sketch/design website place. Also, what purpose do you want for your site? Do you just want to talk about you, like with an email to contact you? Do you want to host information like where you will be performing on what dates? Do you want one page with everything or multiple pages for different topics? As you try to answer that, keep in mind that you are new to this so simpler will be easier - you can always add more or change what you've done over time as you continue learning, of course.
  2. No. The session is stored on the server so as long as the server isn't compromised then the session data won't be compromised. It's like my refrigerator. There's no lock on it so anyone could take and leave what they wanted at any time, so in that sense it's insecure, however the doors to my home are locked so people can't get inside.
  3. 1. It clutters the session. If you have a lot pages storing their arbitrary data in there then you start to lose track of what values are in there and why. It's the same problem as with global variables. 2. Making sure the session is clean of old data can be hard. Consider if someone browses through the quiz and then stops partway: what happens to the data? It stays in there until something either overwrites it or removes it (like doing another quiz) so the longer a user is on the site and the more they don't conform to the expected behavior for a user, the more data piles up. 3. Upgrading users through data changes becomes a problem. If the quiz works one way for a long time and then it's changed to work differently (requiring the session data be stored differently) then you have to worry about users with long-lived sessions who have old data still in there. 4. It is actually slower to some degree. Every time you fire up the session, PHP has to deserialize the entire session from its cache, and if there are large chunks in there you don't care about then it is wasteful.
  4. I mean which page (with the information) are you on? Like there's an Activity tab at the top of the page which has "streams" like unread content or stuff I've commented in.
  5. Sessions are for stuff that needs to be accessed in different parts of the site. If you want data only for the quiz (and what's more, only for that particular quiz) then it doesn't belong in the session. +1 to storing it as hidden inputs in the form. That's what I've done previously: generate the quiz questions and answers ahead of time (a dynamic quiz that pulls from a pool of questions and randomizes it all), serialize and encrypt the data, store that in a hidden input, update the data with answers as they complete the questions, then process it at the end. Assuming the data isn't supposed to be persistent.
  6. I'll try to watch for that. I browse on Condensed too and haven't noticed things missing. Which stream are you looking at?
  7. Is it lag? Are they there now?
  8. Decay? No, there's no decay here: it's just exponential growth between those two levels. Decay is something else.
  9. Refresher math lesson: The basic form of an exponential equation is a * (b ** n) + c. That's three constants (a, b, c) and one variable (n); you can throw more constants in there, like go overboard and use a * (b ** (c * n + d)) + e, but you probably won't need so many for this. It's exponential because some constant is raised to the power of some variable, and as the variable increases the result of the equation increases by much more. You have two data points that you want an equation to cover: at level 1 the result should be 500 and at level 99 the result should be 9999. That means you have two equations to start with: a * (b ** 1) + c = 500 a * (b ** 99) + c = 9999 When you have some number of equations and some number of things-to-solve-for, you can find a unique solution if the number of equations is >= the number of things. That's not the case here, which means there are going to be an infinite number of solutions. One option is to eliminate a variable. I chose "a". So b ** 1 + c = 500 b ** 99 + c = 9999 Two equations and two things so there's going to be a unique solution. ...but the math is a pain to find it. So I tweaked the equations a bit by taking the level and subtracting one. b ** (1 - 1) + c = 500 b ** (99 - 1) + c =9999 The first equation loses one of the variables entirely (because anything ** 0 == 1) and so can be solved for the other (c=499), then that can get plugged into the other equation to solve it (b=1.0979663). Fortunately tweaking the equations actually makes sense: at level 1 you should just be at the base stat so the exponential part shouldn't really be kicking in yet.
  10. No, the exponent is what's on the right of the **. 1.09 is the base, which is the one on the left of it.
  11. There are an infinite number of ways to make a curve that hits (1,500) and (99,9999). Because there's a whole bunch of stuff that could happen in between those two points. This is expressed in your screenshot by the Fast/Middle/Slow slider. The most obvious one would be the simplest: x ** 0 + y = 500 -> y = 499 x ** 98 + y = 9999 -> x ** 98 + 499 = 9999 -> x ** 98 = 9500 -> 98 * ln x = ln 9500 -> 98 * ln x = 9.159 -> ln x = 0.09346 -> x = 1.0979663 1.0979663 ** (level - 1) + 499 = attribute Note that it calculates based on level 1 being the baseline. That makes sense unless the characters actually start at level 0.
  12. Tip: with this sort of query+subquery setup, if you have a GROUP BY x, y, z in the inner query then you should probably be joining on x, y, and z in the outer query. Otherwise you'll get duplicates. So here, the inner query searches by roster_no and drill_date, but outside you're only considering drill_date. That means there could be "duplicate" rows where the drill_date is the same but the roster_no is different. That may manifest differently depending on the query, but one way or another if there are duplicate rows on the inside then you'll get duplicate rows on the outside.
  13. Use regular sessions, so a session on each device, then associate the session ID with the user record. If it doesn't match on a page load then log the user out.
  14. You're reading from an XML file but you haven't posted it, and you're getting errors but you haven't said what they are. Does that about sum it up?
  15. The only difference between the two is how they determine the start and end dates - one comes from the input and the other from the state date. The rest is the same. So how about pulling that stuff out into a separate function that takes the start and end dates as arguments?
  16. You'd use namespaces with your classes for the same reason that you'd use directories with your files: because giving each thing some long and complicated name just so that they all stay unique is a pain. Practically speaking, if you use underscores in your class names then you're already using namespaces.
  17. That's, like, half of a description. Sounds like you just want a list of different things - media types, consoles, whatever. A list. Right? That's just a basic enum table: ID column, "value" column, then use the ID for foreign keys wherever you need them.
  18. Sounds like you're overthinking this. If you want a date and time then you should use a data type that supports a date and time. Storing them separately as a DATE in one column and a TIME in the other makes it more complicated than it needs to be. Then the question is whether you use DATETIME or TIMESTAMP. They are mostly the same, but the key differences are that (a) DATETIMEs have a much wider range of dates they can support and (b) MySQL will reinterpret TIMESTAMPs according to server/client timezone configuration. Longer story short, DATETIME is nice for arbitrary date/time values that your application will manage (like your appointment example) while TIMESTAMP is nice for record-keeping purposes (such as when a table row was written or updated). But it doesn't really matter that much. It's perfectly okay to use DATETIME for everything, so if you're still unsure then just use that and move on to the next challenge.
  19. That's really easy: put an image or × on the page where you want it to appear. Unless you're talking about some amount of functionality which you haven't explained yet? Maybe there's a particular behavior you have in mind regarding this button that you should tell us about if you want help to do it?
  20. I've tweaked some permissions. Do you see editing options in your list of status updates now?
  21. If you have code and are having problems with that code then I suggest a good starting point for us to help you would be for you to post that code.
  22. I assume by "no longer works" you mean that you get parse errors from PHP?
  23. Sigh. If I were in front of your computer, trying to solve your problem, do you know what I would do? Exactly what I told you to do. If you're willing to try that then I can help. If you aren't then that means you're shopping around for an answer you like, and that is not how good programming works.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.