Announcement

Collapse
No announcement yet.

Sitephyre & Virtuoso WIP

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    at the expense of me working on my own games, though that's sort of me developing anyway)
    I gave up on creating games. It's just too spread out for my taste. If I was going to build a game, it would be a 3D FPS. It would also have ZERO content that I didn't make (or wasn't originally made specifically for my game). Reality set in one day and said "Too much bullshit, you are never going to finish this" and I concurred.

    Now I click 2 buttons to start my server, open my editor and a browser, and I'm ready for anything/everything. "One ring to rule them all" if you will. It took me a long many years to realize that I actually hate game creation. The only exception being if I only had one job in the creation of a game. Like if I was JUST the programmer, I could do that, but it isn't in me to ever really collab so, being "just the programmer" is blocked by the exact situation that would make me "just the programmer"

    My most enjoyable game creation activities were when I had just one thing to do. Like, when I helped Phenom, Bluntz and Killpixel with some simple QC stuff or my various single-focus radiant projects. Get in, make it happen and get out. No tedious, never-ending list of a million things to do. I actually had to train myself how to look at my current project differently for this very reason. Right now, I'm not building a massive CMS. I'm building a database (done) and predefining all of it's interaction (current focus). If I started building a CMS...

    RE: Reality set in one day and said "Too much bullshit, you are never going to finish this" and I will concur.

    I was never able to train myself that (ex) "I'm just making a model" and later i will be "Just programming some game code". This is probably due to the fact that game creation has too many steps before you see results, whereas straight programming (even in multiple languages) can lead to at least some POC results, really quick. I could spend a month just perfecting one model and it will still need plenty of work just to get it functioning properly in a game. Export disasters have discouraged me immensely, as well.
    Last edited by MadGypsy; 02-03-2014, 12:13 PM.
    http://www.nextgenquake.com

    Comment


    • #32
      I design games because all I do is play games. So at this point, after years of coming up with ideas, that I should start making some.


      Which has resulted in me making zero games and procrastinating a lot because league of legends or quake/outside activities/work/college
      twitch
      wew lad

      Comment


      • #33
        Today should be the day that I have an entire abstraction layer for my database complete. I think I only need to write one function to be finished. I'm procrastinating though cause that one function is gobbledy gook and I'm taking a pause to see if I can think of a better way.

        As it stands a line as simple as this will do everything you would expect to happen for what it does.

        $db->delegate('sign_in', $_POST)

        That one line will validate all data, encrypt all necessary data in 1 of 3 flavors, configure all prepared statements and bind_(param/result)s, execute the query and return results/true/false (whatever applies). The case "sign_in" isn't even something that needs to be typed. We can do it like this

        $db->($_POST['some_hidden_field'], $_POST)

        Since "some_hidden_field" can have any value I tell it to for a page, the above line becomes the copy and paste line to handle ANY form submission.

        basically this simple
        Code:
        <?php
        	include 'lib/database/sp_query_manager.php'
        	$db = new QueryManager(/*user level*/);
        	
        	if( ( $_SERVER['REQUEST_METHOD'] === 'POST' ) && ( isset( $_POST['case'] ) ) )
        		if($db->delegate($_POST['case'], $_POST))
        		{
        			//successful submission
        		}
        ?>
        <html><head><title></title></head>
        <body>
        	<form action="" method="post">
        		<input type="hidden" name="case" value="/* prepared switch value */" />
        		<!-- any kind of form fields -->
        		<input type="submit" name="submit" value="Submit" />
        	</form>
        </body></html>
        The system is smart. It doesn't matter that $_POST will have too many params in it my prepared statement executioner knows what it needs out of that, even down to this shit 'sssi'

        I also altered my prepared statement executioner (henceforth known as do_prepared()) to properly accept SELECT queries that have no parameters to bind. It even knows the difference between a statement with nothing to bind (ok) and a statement that is being fed empty params (error). It also knows the difference between no expected return results and fubar'd return results. There is an ass-load of decisions being made. I'm pretty sure that I have every possible situation handled. The goal is to never have the script "crash". I want it to have the mentality "Well, that didn't work, Imma go do condition now and then see what the user wants to do."

        All errors are logged and bubble up to the calling function as false, where an ambiguous message is selected from a handful of possibilities. So, meaningful data is kept from the user as much as possible. The user doesn't have to know that QUERY INFO failed on DATABASE INFO, they just need to know their shit didn't work.

        My current method is to encrypt data in and decrypt & escape data out. It's the only method I could think of to make sure that SQL injection never makes it to the database as a readable query. Not that it really matters. Prepared statements can't perform multi-queries and no average user will ever be connected to the database with a DROP permission. Actually, an average user doesn't even have DELETE privileges beyond the private message table.

        My system from the beginning was to create 5 possible host level users with increasingly more powerful permissions BUT even the highest user is using the lowest possible permissions for any given action.

        For instance SELECT ON ENTIRE DATABASE is a guest level permission. You could be the Admin and something simple like displaying a thread will happen with guest level permissions. You could say that the 5 permission levels represent a hierarchy of what is possible and any/every user can only access levels <= their own.

        The system is so strict I have to buck a guest up to user upon sign up or they couldn't even write to the user table. I take that level right away after the query is sent and the guest has to sign in, in order to get static user level.

        There will be a few other places where there will be "exception" privileges but, in a few places where I started to see this happen, I was actually able to adjust the install script in another way and not have to make it an exception.

        An example was when I had one node to rule them all. I was forced to give users DELETE privileges on that node (for private message situations) and I really didn't want that. My "work around" was to basically clone the node and make it a private message version. Now users have DELETE privs on that and the main node is still restricted for deletion from the user. The private message node works just a little different from the main node as well. The main node can be literally anything and it's type determines what will be joined to the node. The message node on the other hand is just one thing and there is only one thing that could ever be joined to it a reply node...

        oh shit, I just realized something. Hmmm, I think I can make my table structure shorter by 2 tables, which will slim up my permission list and my queries...

        Yup, Imma go do that

        //old
        node
        {
        name: aName
        }

        link
        {
        parent_name:aName
        child_name:linkName
        }

        some join table
        {
        name:linkName
        }

        //new
        node
        {
        name: aName
        }

        some join table
        {
        link_name:aName
        }

        I know why I was doing the extra link table before. My line of thinking was, you can't be specific about what will be joined so the link table just holds the names and it is up to a switch to decide what the actual joining node will be. However, I just realized it doesn't matter. The switch will still decide the joining node and simply get every row where link_name = row.name. This also eliminates child_name from the equation entirely...

        Ohhh wait, nope I did this because of FOREIGN KEYS and not wanting one end to delete the other. Deleting a child deletes the link but not the parent and vise versa.

        Anyway...lol. I'm glad I didn't actually "realize something". I need to stop going backwards in my thoughts. I've spent months on this, I should know by now that everything to this point has an absolute purpose. I'm not saying that there is no way to improve my stuff, but at this point the system is so highly customized that "improvements' would probably involve large changes. I'm not going down that road.
        Last edited by MadGypsy; 02-05-2014, 10:39 AM.
        http://www.nextgenquake.com

        Comment


        • #34
          I still have this link table thing on my mind. I believe I could eliminate it. I'll eliminate the foreign keys too. Then the node table and it's join node will not have any actual connection aside from some name matching when a search is made. This is small beans, though. I have another link node that I can't remove because it links users as friends/enemies. So, in reality I can get rid of one table (and I will)
          http://www.nextgenquake.com

          Comment


          • #35
            Tricksy Script (episode 3)

            This episode focuses on php and things you cannot friggin see.

            I had a situation similar to this

            $prefix = a decrypted encryption; //lets pretend ABD45 is the DEcrypted hash
            $table = $prefix."_table_name";

            now $table should be "ABD45_table_name"

            except I get the error equivalent of 'table "ABD45" does not exist'

            Did you catch that? At the very least it should say 'table "ABD45_table_name" does not exist'

            But that's not what it says, so, where did the rest of the table name go? I'll tell you where it went and I think I went bald trying to figure it out. Apparently, what you cannot see is, the prefix is actually ABD45\0. That last little chunk is a null character. Completely invisible and deadly to string concatenation. I applied a simple trim() to the decrypted output and *magico* all kinds of stuff started working.

            So what have we learned? If you are only getting the first half of a string concat, it's probably because it ends in an invisible null character which is terminating the printing of the post null string.

            you should do somethin about that.

            Oh, and we learned that decrypting will probably put that null character in our results;
            Last edited by MadGypsy; 02-05-2014, 08:07 PM. Reason: lol, I automatically typed semi-colon after results. I guess it's all starting to turn into code.
            http://www.nextgenquake.com

            Comment


            • #36
              I haven't encountered anymore tricksy scripts so, I don't have a new "episode" of that right now . I guess that's a good thing and all but, I rather enjoyed writing about microscopic things that increase your experience level.

              I went back to programming after my little model vacation and set out to start rubber stamping things "done". In the process I mildly reworked the system to make it's use even easier. Now all you do is feed a class a case and an array of vars to do something with. The system completely takes over at that point and does everything imaginable to the data - validation, sanitization, en/decryption, comparisons, queries, everything...

              //signature
              $data->(case, (Array of data || nothing));

              //ex1
              $data->($_POST["case"],$_POST) //where $_POST["case"] = "sign_in"

              //ex2
              $data->("recent_posts");

              I don't know how to compact the processes any more than that. Now is where I start working on a template system. I want to build pages with little more than a small list of tokens. Those tokens will also be "cases". Those cases get fed to $data->("right here"), returning arrays of data that are used to populate the pages. Of course some kind of way some html templates will be gathered within the process, and used as containers to write the array data to.

              I guess you could say that the end result is to write something like this
              Code:
              {HEADER}
              {MENU}
              {NAVBAR}
              {AD_COLUMN}
              {CONTENT}
              {RECENT_POSTS}
              {MEMBERS}
              {FOOTER}
              and have an entire qualified and populated web page appear instead, based on the tokens. My example is rudimentary and the idea is not a new one. PHPBB3 uses a similar system and there are open source template systems that already provide these functions. I write my own stuff, so now I need to go work on a template system.

              I see a lot of preg_replace in my future.
              http://www.nextgenquake.com

              Comment

              Working...
              X