Jump to content

KevinM1

Moderators
  • Posts

    5,222
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by KevinM1

  1. In other words strings need quotes around them. And, logical OR is two bars So: if($logged['level'] == 'owner' || $logged['level'] == 'head mod' /* ... */ )
  2. If I have a page with a lot of markup, I'll put in a few comments just to keep things clear for my own sanity. Otherwise, I don't use them.
  3. Are you sure that $row['comments'] has a value? Where does $importedjobnumber come from? I'm just wondering if your second query is returning what you think it should be returning.
  4. 1. Like someone else said, it sounds like you need a WHERE clause at the end of your SQL statement in order to narrow your results. I'm guessing, based on what I've read, you want to determine if a user is banned or warned. The simplest way to retrieve this info would be to do something like: SELECT warning, banned FROM tablename WHERE username = $user Naturally, you'll need to tweak it in order to work, but that should give you an idea. 2. Speaking as Nightslyr and not a guru, no one cares that you have ADD. The other members in this thread have been more than helpful to you. We're all volunteers here, even those of us on the team with our fancy little badges under our names. We take time out of our day because we enjoy PHP, and like to help others as most of us were helped here or elsewhere at one time or another. That does not mean we're obligated to help you, or that we somehow must do more for you than any other member seeking help. This isn't middle school or high school. There's no PHP Freaks special education department or customized IEP for certain members. You will not get special treatment here. As someone who was born with a permanent physical disability, one that prohibits me from walking, forces me to use an electric wheelchair for mobility, and an aide that must come daily for such simple things as going to the bathroom and bathing, I say stop using your disability as an excuse for failure. You succeed or fail based on your own efforts, not due to life dealing you one bad card.
  5. Yeah, it tends to stem from a mix of pride ("I'm not a real coder unless I roll my own") and distrust of third party solutions. At least, it did in my case.
  6. function findwinner(isplayer){ me=(isplayer)? 1 : 2; for(n=1;n<=8;n++){ if( (moves[ways[n][1]]==me) && (moves[ways[n][2]]==me) && (moves[ways[n][3]]==me) ){ iswon=true; break; }} if(iswon){ if(isplayer){ playerwins[level]++; playerstarts=true; writetext(3); }else{ pcwins[level]++; playerstarts=false; writetext(2); }}else{ if(done>{ draws[level]++; playerstarts=!playerstarts; writetext(1); }else if(isplayer) pcturn(); }} theres the function for ya And this tells me...? Also, why is this kind of game logic being executed by JavaScript anyway? This sort of thing should be on the server, with the rest of your game code. JavaScript should merely be used to enhance the experience, not be a critical piece of the software. The game should be able to work without any JavaScript. @kratsg: synchronous page execution is the default behavior - full page refresh when submitting info to the server.
  7. Gayner, you need to brush up on the basics. First, trying to echo out the result of an update query is nonsense. Literally. It won't work, and certainly won't magically do what you think it should do. Second, you seem to be confused about what JavaScript is, what PHP is, and how they work together. Third, I don't even see a JavaScript function here. Instead of blindly writing code in an attempt to somehow stumble onto a solution, take the time to learn how things actually work.
  8. I think it's a phase all young coders go through. I was the same way, too.
  9. It's possible with AJAX.
  10. There are two acronyms that every programmer should try to adhere to: KISS - everyone knows this one. DRY - Don't Repeat Yourself. Essentially, if you're repeatedly writing the same block of code, or repeatedly have to address a certain problem, your design is off somewhere. Storing the same weapon data in two different locations and with two different techniques is a clear case of this kind of design problem. With what you're trying to do, a database is the way to go, as you'll need a way to tie various items to characters. That kind of relationship is difficult, if not impossible, to maintain in XML. XML is better suited for static data whose relationship with other system components is also static. Example: character class info from, say, World of Warcraft. A Hunter - its abilities, leveling stats, types of weapons and armor it can use - remains the same regardless of what race the character is, or faction, or gender. This is the kind of data that benefits from being modeled in XML. You also should be doing only what is absolutely necessary to access and manipulate the data. Just like with machinery, the more 'moving parts' the greater the chance of failure. Keep at it. The knowledge you're gaining with this project is invaluable, not just in terms of game making, but programming in general. As an aside, I understand where you're coming from, at least partially. I'm also disabled. I was born with a physical disability, have had over 40 surgeries because of it, and require an electric wheelchair for mobility. The internet is the great equalizer - a place where everyone can be a participant, and where its inherent anonymity means our ideas can be judged on merit and not prejudice. So, again, keep at it. You may also find that reading other threads on the forum to be beneficial. I learned the bulk of my PHP skill by reading other threads, trying to come up with solutions to other people's problems on my own, and hanging out in the Application Design sub-forum.
  11. I think you need to take a step back and look at your project with fresh eyes. Remember what I said earlier, about using the best tool for the job? I can't help but feel you're trying to use a hammer to insert a screw. XML is just one tool available for you to use. Don't think of it as a cure-all, or a replacement for the database. Just so the rest of us get an idea as to what your overall design is, as well as to spur you to think about your design critically, here are some questions: What's the difference between the weapon data stored in the database and the data stored in the XML file? Do you need this data stored in two different places in two different ways? What are all these various config files for? Can you combine/streamline them? What are you trying to do here, specifically? Obviously, you're attempting to return weapon data, but for what purpose? Is this part of your combat system? Are you merely trying to give a character a new weapon as loot? Like I said earlier how you intend to use this data is an important consideration when deciding how to store it. It seems like this is an opportune time to really think about this before moving on.
  12. Put it between the textarea tags: <textarea><?php if (isset($message)){ echo $message; } ?></textarea>
  13. Simply add something like: <input name="name" value="<?php if (isset($name)){ echo $name; } ?>" />
  14. Why are you explicitly exiting the script, and where are you attempting to echo the bonus value?
  15. Well, it works as planned in IE8, but I'm guessing it chokes in IE6.
  16. On the PHP side, you can trim it down. Try to think about it in the following way: I. Has the form been submitted? A. Yes i. Validate each entry ii. Does everything check out? a. Yes 1. Process info b. No 1. Record the errors 2. Output them to the screen B. No i. Show the form So, a quick sketch of this in code: <?php if(isset($_POST['submit'])) // if the form has been submitted { $errors = array(); if(!empty($_POST['name']) && /* regular expression to check it for well-formedness */) { $name = $_POST['name']; } else { $errors[] = "The name is invalid"; } // ... if(empty($errors)) // if there aren't any errors { //process } else { foreach($errors as $error) { echo $error . "<br />"; } } } ?> <!-- display just one form -->
  17. What? Presence of client side validation does not somehow turn off server side validation. In fact, both are often used in conjunction - JavaScript to give the user dynamic feedback to make the experience more friendly, and the server side stuff (PHP in this case) to do the heavy lifting. Tie your JS code into the form's submit event. If it checks out, allow the form to be submitted (where the PHP validation code does its job), else, display errors. Along those lines, your PHP code is way, way larger than it needs to be. Use the JS to display individual errors next to the appropriate field. You can inject error messages straight into the DOM if validation fails. Have the PHP merely build up a list of errors and spit them out at the top of the page as a last resort. That'll save you a ton of code, as you won't need to write out your form's markup for each condition. And, just in a general sense, always remember that JavaScript is best used to enhance existing functionality. Client side validation is no exception.
  18. Or, you could use __autoload().
  19. Ah, beat me to the punch. To the OP, a couple of things - 1. You should brush up on your loops. They're integral to coding in general, and all have their uses, even the erstwhile do...while() loop. 2. Storing things in a database vs. XML files has its pros and cons. A database makes it easy for your script to add/edit/delete info. It should be used for storing dynamic data - users, a particular player character in your game, a character's inventory, etc. XML should be used for data that is more static - the abilities available to a particular character class, base character stats, their leveling stats, etc. Application-wide data that doesn't change very often. For this kind of data, which you typically only need to read once and don't have to bother with saving anything after its use, it's far more economical to get it directly from a XML file rather than fetching it from a database. Weapon data could fit equally well in both storage mechanisms. How you use it, and how often you need to modify it should be considerations. Example: My game (don't we all try writing one? ) stores items in the db. Why? Because I need to be able to relate that info to individual player characters' inventories. My character classes, including the attacks available to characters of that class at certain levels, are stored in XML files. I only need to read that info at certain times, and I don't need to relate attacks to characters as all characters of a certain class will have the same attacks available to them at the same level. The point of all this is to realize you have options, and to make you informed of them so you can make a decision based on knowledge. There isn't a one-size-fits-all way to address this kind of problem. Instead, you'll need to use the best tools for the right part of the job.
  20. As always, PHP's online documentation is the place to start. In particular, look at SimpleXML.
  21. You may want to consider storing the weapon data somewhere else, like say a XML file. That way, instead of having to do these kinds of contortions to obtain the data and hard code the base values into your code, you can simply read in the data from the external source. It'll make your game more flexible as you'd only have to modify the file to add/remove/change weapon data. XML, in particular, is a great way to store this info given its hierarchical nature. You could have a file with the following layout (rough sketch): <weapons> <weapon> <name>Big Club</name> <baseBonus>2</baseBonus> <description>It's big, it's clumsy, but it hurts when it hits</description> </weapon> <name>Eastwind Katana</name> <baseBonus>2</baseBonus> <description>Forged by the warrior monks of the Hidden Vale</description> </weapon> <!-- etc --> </weapons> Simply access the file when needed. Also, this kind of project is perfect for learning OOP. Items (weapons, armor, misc) map to objects naturally, as do things like status effects and special attacks/spells.
  22. Interesting. The following statement is wrong, however: As the code below works without alerting out array methods: <html> <head> <title>Blah</title> <script type="text/javascript"> window.onload = function(){ var oArray = new Array(); oArray["_KEN"] = "Enter"; oArray["_K03"] = "Exit"; oArray["_KHL"] = "Help"; for (var key in oArray){ alert("Key value is: " + key + " Value is: " + oArray[key]); } } </script> </head> <body></body> </html> You/the article are right about the length property returning 0 if the keys are strings. Unfortunately, it appears as though the length property doesn't work for objects at all, as I get 'undefined' when trying to alert it out. I guess the safest conclusion is that for a real associative array, one should create a custom object that has a method to return its length.
  23. First, your select element should have the name, rather than one of its options. Second, your options need values. Third, what is it you're trying to do exactly? Putting up random code, malformed HTML, and saying it doesn't work isn't much for the rest of us to go on.
  24. Again, if you are certain that the keys will only match one value, then simply use an associative array like I showed you above. Example, since it seems like you're having a hard time understanding me... Your array should look like: Your array... ( ["_KEN"] => "Enter" ["_K03"] => "Exit" ["_KHL"] => "Help" ) The ids are the keys, and the values are mapped to each one. You can add to the array, or retrieve individual values with the functions I showed above. Also, JavaScript has a for...in construct which works similarly to PHP's foreach: for (var i in myArray){ alert("Key value is: " + i + " Value is: " + myArray[i]); } Like I said originally, arrays are arrays are arrays. They behave in nearly identical ways regardless of what language you use to create and access them. What you can do in PHP you can do in JavaScript with only a few minor syntactical changes. This is pretty pointless as an array is also an object in JavaScript, and would be used in exactly the same way.
  25. What do you think extract() is for?
×
×
  • 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.