Ok need to do the same on map but need to see if we are going in the right direction on this...........
Ok need to do the same on map but need to see if we are going in the right direction on this...........
James once we get going I am going to need to sync all these fields with your database for maps and mods never synced at field table level before but think it can be done
Hi James yeh understand I am wide open as well at present - At present the AAAA database is all one so the map and mod database is live on AAAA and I have setup the extra fields within AAAA database - The plan is at some point to export and sync all these fields so somewhere the mod and map database fields as a database will also run somewhere else.
I have had to keep them on AAAA at present because otherwise I have another problem of changing my side to link to an external database and this would be a nightmare on Drupal so the way round was as the AAAA database is already running and has some small contentent but a good start is to continue but sync the database for Xnull somewhere else so at some point once we got all this working is - : can you setup another sql database for all this to be sysncd to ?
uhm I would go for a separate database.
Best would be even a separate database for mods and for maps.
Then also own site with own address.
The 4 fields can have the same name, talking names please. Like InstallationServerSide, InstallationClientSide etc.
No need to include map or mod into the name as for the auto-installation it wouldn't matter what type of content it is.
Thy type of the content (map/mod or whatever) is identified by an extra field (dunno if you allready have that included).
Hi Joto - Yeh no problem with the separate database they are just accessed and stored that way on AAAA but for the X-null side they can be separate, - Both Map and mod already fall under 2 different databases hence your 4 fields exist twice James are you able to create a separate database here so we can do some testing ? I will do some testing on MYSQL my side on syncing / replication from AAAA to a new database so the fields on the xnull side are stored as Joto has suggested.
This needs to be a two way sync so anything that is updated on Xnull side is also sent back to AAAA - I guess for your fields Joto these dont have to be stored or synced on AAAA but they dont have to be accessed AAAA side but could be good for backup purposes so if Xnull is down they can still be accessed perhaps as a fall back.............
I am not trying to over complicate it but the plan was to build on what I had started and hopefully we end up with a linked database that has a framework and other sites can get RSS feeds and have read permissions so they can display the data on their own template style on their own sites stuff like that.
I will need to read up a bit more on whats possible on the sync/replication - I was not to concerned about locking on updates as I dont see that anyone record would both be updated at same time.
I am flexible on the site or where I just assumed it would be stored on xnull ?
I can rename the fields I just abbreviated as they were long field names..........
Have not added the game type fields yet thats on my list ))
Last edited by heatsinkbod; September 1st, 2012 at 05:44 AM.
Ok have now added Game type -:
MOHAA
MOHSH
MOHBT
MOHAA SP (as in single player)
Have changed the mod fields for Joto (note these fields will exist twice on two different databases one for mods as here and then maps)
http://www.mega-clan.co.uk/moddatabase1.php
This test link is showing errors one I noticed was on the "mod screenshot" - this is not because of a null record but because my test site is not configured to display the file from the record - its a mod screen shot and on AAAA I use imagecache and resize stuff - I think on my test link Apache is not configured to use these but think this will be quick fix once we start to run and change the PHP for Xnull
At present this is all just the mod side - I need to learn for this and then make all the changes together on the map side the same just dont want to end up going round in circles with all the changes
With ref to above as Joto mentioned about site I think we just need somewhere to host the database for this side thats separate from existing Xnull database
Last edited by heatsinkbod; September 1st, 2012 at 06:48 AM.
Ok So some of the updates http://www.mohaaaa.co.uk/AAAAMOHAA/c...tle-server-mod this will be displayed completely different on Xnull but what I am after is the fields any more we need, Joto - I have left yours hidden I presume they are for back office only.
Was thinking of the existing field "Mod compatable with Reborn"
At present for selection its like
2.5
3.0
3.5
All
But perhaps also it needs 2.5 or above things like that - I have scoped in ther on the options so these can be added by user but better we have more scoped defaults perhaps
Last edited by heatsinkbod; September 1st, 2012 at 07:08 AM.
imo there should be only one central database, and not 2 which needs to be synced and stuff. Whats the purpose of having 2 databases ? And then syncing ? omg no please.
To the database field names: Make the names please more universal, at current you have
print("MOD Version = "); print $db_field['field_modversion_value'] . "<BR>";
and I assume you have the same for maps like this
print("MAP Version = "); print $db_field['field_mapversion_value'] . "<BR>";
make it universal so you can take the same database table layout for all content
print("MAP Version = "); print $db_field['field_contentversion_value'] . "<BR>";
print("MOD Version = "); print $db_field['field_contentversion_value'] . "<BR>";
If we build further on that database it would be extra work to handle 2 database fields which are basically the same.
When external tools or a webservices accesses the database it doesn't matter if its a map or mod, a specific field in the database will tell what type of content it is.
I think you need to add an extra field for that like: ContentType
which contains then wether Map or Mod or w/e