Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 44

Thread: X-null mod / map Template

  1. #11

    Default

    Quote Originally Posted by own3mall View Post
    The more I read these threads, the more I am thinking about just writing my own system from scratch using PHP and MySQL... There would be the upload section, admin section, and display / search section... doesn't sound too hard. Problem is, I don't have much time these days now that I have a relatively boring programming job dealing with insurance, which I understand nothing about rofl.
    Hi Own3mall well thats effectively what we are doing, All we have is a database so we are having to build Index, Display and data Entry, The existing Database structure is simple but I will get a full map and description of its structure posted

  2. #12

    Default

    Ok here is the tablemap Openoffice or office should open it - as you can see its straight forward
    http://www.mega-clan.co.uk/moddatabase.doc - The Template example I posted is just an example on http://www.x-null.net/forums/showthr...d-map-Template is just an example and can be totally scrapped and done fresh was more just proof of concept.

    So As you were saying above about writing it all from scratch we effectively are the only thing we are trying to do is keep the existing Database structure so my own efforts on AAAA have not been wasted.

    But really all we need is -:

    Record Index Searchable
    Record Display
    Data Entry

    We have now added the Patch fields I guess these dont need to be displayed as will be used by the Patch
    Have added the Fields that will be used to sync the databases

    So what ever ideas you have we can do its just built on an existing database so I know a few of the field names are not ideal but they should not cause any problems

  3. #13

    Default

    Thanks. That will help a lot. So is the plan for me to modify the shit out of KFM to make it essentially the upload tool that places the mod info into the database and still works as KFM as well?

  4. #14
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    own3mall, the task for you is to build an admin page, with at least 4 things:

    1. Login page
    2. User account management panel (create, remove admin, reset password) accessible only for SuperAdmins
    3. Mod/Map management panel (where you will add new maps and mods to database), it needs to cover all the fields we've spoken about
    4. Upload panel (your KFM), where we'll upload files (maps/mods) so we can choose from them later in Mod/Map management panel. Just make sure you can't rename, delete or remove file that is already being used in database, so you need to add a modal window with information that selected file has to be unlinked from Map/Mod DB entry before performing such operations. Or, you would need to add a feature where your KFM will automatically update all DB fields that use this file, to reflect changes.

    This is just HTML right now. If you want you may start to write PHP backend also.
    If you're going to write logic, make use of MySQL transactions.

    About the logic:

    1. We have to use transactions for our syncing, so if query fails on one of the DBs, all queries in transaction are rolled back.
    2. All queries has to be executed on all Synced DBs. (except SELECT)
    3. Every query has to be saved in Sync Table in all Sync DBs, before executing it. (except SELECT)

    Pseudo-code:
    PHP Code:
    function executeQuery$query_string ) {
       
    //for each DB in DBs array 
       
    $sync_query 'INSERT INTO $sync_table VALUES($sync_version, $sync_date, $query_string)';
      
       
    //begin transaction
       
    for(each DB in DBs array) {
               
          
    mysql_query($sync_query);
         
    $results =  mysql_query($query_string);
       }
       
    //end transaction

       
    return $results;

    4. Every DB has to be running a Cron Job (Windows Shedule), that will execute Sync PHP script every few minutes, hours or something. It has to check if it's own Sync Table latest version isn't older than versions in other DBs. If it's older, it should get the queries from most up-to-date DB, and execute it on itself, so it will insert and update the data to relfect changes in this most up-to-date DB.

    5. During any inserts/updates we need to put a lock on Sync Table, so Sync Script won't try to update the DB between one DB insert and second DB insert.

    Pretty easy, I might do some simple backend logic, like executeQuery and some sync'ing stuff myself if you don't really get it.

    EDIT:

    We may also, just forget about running queries on every DB, and just make sure that Sync Scripts will execute often enough to grab latest changes from other DBs.
    It's easier to do, but we have to make Sync Scripts execute more often and make more queries to DBs.
    If we do this like I described it above, we don't have to run them so often, because we are sure that we have the latest changes if our DB didn't go down. If it went down, it will auto-sync sooner or later.

    But I'd go with easier approach as I see some problems with the other one.

  5. #15

    Default

    I don't think we should sync DB's at all... What's the point of this? I am going to try to get something together... just don't expect it too soon. Here's what I cooked up... I think I'm going to take this a step further and write my entire solution as an open source package. I'm actually quite excited about the possibility. It will work for all games.

    I think we can do better in all aspects... however, I will try to deliver an upload form . admin system that works with heatsinkbod's setup... that's the plan. Again though, I'm not sure how much time I have to work on this.
    Attached Files Attached Files

  6. #16
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    Because we want to make it a general database. This gives us a reasonable set of advantages with almost no efforts.

    First of all, when one DB goes down (eg. DoS, DDoS, Ping of Death etc. that xNULL is often a target of), people can still use it. When we bring back the other DB, it gets autosynced with latest changes, so no manual data migration/merging is needed. When Heatsinkbod will move their servers to new destination or host provider, he can freely shutdown the DB without any loss in user experience. When it's back it will automatically get updated.

    This introduces reliability. Single DB would be good if we were an organisation of some sort, or at least have some funds. With projects like this it is very common that domains expire, services fall. Distributed DB gives us a bit of stability and security in this field. When one site goes down (for various reasons), the other ones will still be functional.

    That's also why we try to run our custom masterserver, so once GS MoHAA masterserver goes down, our Reborn powered servers will be still trackable in the net.


    We have to make some decisions, we have to decide what we are after. We can even change to DB structure, but there must be a person that will do data migration from current DB structure. The system has to be flexible, and we must separate logic from view (MVC) so we can easily use different templates.

    If you're up to this, you can freely start writing it.

    EDIT: We could even write it using different technology like Wicket, DJango, .NET, Ruby on Rails, etc. be please keep in mind that most host providers offer only PHP, and if they offer some other technologies, you have to pay more. So I'd stay with PHP (even that I prefer Wicket which is a Java framework)

  7. #17

    Default

    Quote Originally Posted by own3mall View Post
    I don't think we should sync DB's at all... What's the point of this? I am going to try to get something together... just don't expect it too soon. Here's what I cooked up... I think I'm going to take this a step further and write my entire solution as an open source package. I'm actually quite excited about the possibility. It will work for all games.

    I think we can do better in all aspects... however, I will try to deliver an upload form . admin system that works with heatsinkbod's setup... that's the plan. Again though, I'm not sure how much time I have to work on this.
    Sounds good - but at the same time is this not what Joto is doing on the SCAPP side http://www.x-null.net/forums/showthr...scapp+database with .net ?

    For our side here on X-null / AAAA for MOHAA - the only constraints I have is I cant rename the field names without a lot of grief on Drupal my side but if your new frame work can use the existing fields and happy we can add whats needed and perhaps change the functions of some on the existing DB we can still get where we all want to be also not forgetting the support fields for the patch.

  8. #18

    Default

    Here's what I came up with by following your documentation... it doesn't work yet... it's just the form. I need to specify which fields are mandatory and which are optional. Still, in my opinion, there is too much that has to be done in order to upload a mod... this is not simple at all, which is why I would still have gone with a kfm implementation. Let me know what you guys think.

    http://dinofly.com/test/upload_form.php

  9. #19

    Default

    More reflection on this...

    KFM has a list view, I could make it default this view and make it a lot better... I really think kfm is the way to go.

  10. #20

    Default The Way to go

    Well you done some great work on this own3mall, I honestly dont know the best way to go - Razor has had some great idea's on this some of which are beyond my skill set but I am still learning ))

    I did the AAAA thing based on my own skill set so worked out a solution for what I felt could not be found or trusted to survive for say the next couple of years at the same time had seen what Joto was working on which would be the ideal solution but no disrespect think Joto is working on to much same as Razor so I I did I quick fix based on Drupal but the core was database so when I saw X-null talking about it it was on the same path I wanted but I needed support also..........

    By Survive I mean in another 5 years will it still be running to support MOHAA - so many site have died and many sites like X-null, modtheater and AAAA could all be gone in a few years so whats left ???

    Well not a lot its hard enough now to find some of the old mods and maps without coming across all the dead links and missing files so from my view its about keeping all the hard work put in to the mods and maps by the developers.............

    So the share DB was to keep it all alive for longer best we can and who can say whats the best solution so the bigger the better support so kind of think we need to be more future proof or all this effort now could be lost in the future.............

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •