Topic: Breaking new ground with Mission Scripting and SQL (Read 20304 times)

UDF_Intruder · « **Reply #40 on:** January 22, 2003, 08:27:10 pm »

Just out of curiosity, has anyone checked the transaction log to see what and/or how ServerPlatform manages the database?

Excuse me if that was a dumb question, but if you could document what does and does not get altered, that would help figure out what needs to be done.

I haven't gotten around to setting up a SFC Server using SQL, but would love to see the structure.

DONOTDELETE · « **Reply #41 on:** January 23, 2003, 01:03:46 am »

Quote:

Just out of curiosity, has anyone checked the transaction log to see what and/or how ServerPlatform manages the database?

Excuse me if that was a dumb question, but if you could document what does and does not get altered, that would help figure out what needs to be done.

I haven't gotten around to setting up a SFC Server using SQL, but would love to see the structure.

Duh, I've been trying to figure out the db structure, and I forgot all about tracing the ODBC driver calls.

Just enabled tracing on my test server now.

That may help with the details of the db that I havent figured out yet... as well as how to implement
db security. I'll check it out once the log collects enough info...

Thanks for the input!

P.S. My tentative structure of the database can be found here:
tentative db structure
If there are any glaring errors or omissions please let me know.
(aside: so far I have been unable to capture any data from the 'battlesrunning' table but have caught data
in the 'preparedmissions' table...)

Tao · « **Reply #42 on:** January 23, 2003, 01:25:05 am »

Didn't realize that was your test server. Tried just about every mission, they all seemed to work well. No PvP, but maybe later when more people are on. Friendly space (0809); monster, quite a few patrol, convoy escort. Didn't get a scan mission. Enemy space(0909); patrols, convoy raid, no scan missions, base assault (BATS). Neutral space; not sure which hex it was, but just south of the above hexes, patrol, convoy raid.
All missions were in a D7 variant or D5K.

DONOTDELETE · « **Reply #43 on:** January 23, 2003, 02:09:52 am »

Had a quick look at the ODBC trace - looks quite arcane to me - not sure it will be much help.
(EDIT: I think I was using the wrong dll to trace with, will try again...)

I went looking for MySQL's transaction log but wasn't sure where to find it...
I checked the manual (not lost!

) and found that:

"MySQL supports two different kinds of tables: transaction-safe tables (InnoDB
and BDB) and not transaction-safe tables (HEAP, ISAM, MERGE, and MyISAM)."

Since all the tables are of the MyISAM type, I don't think a transaction log is produced.
If present, they should be in "/mysql/data" but I only find the error log there.

Please correct me if I have misinterpreted this or missed the obvious.

P.S. Thanks for the report Tao!

FPF_TraceyG · « **Reply #44 on:** January 23, 2003, 03:30:27 am »

Hmmm, thats interesting... would you be interested in doing some mission testing, rajnsaj?

DONOTDELETE · « **Reply #45 on:** January 23, 2003, 07:41:37 am »

Sure, I think I could manage testing a few mission scripts.

I did promise some users I would restore the flatfile database
they were working with. I think I can put that on hold for this.
Hmmm, maybe I could just transfer everybody's account to
the SQL db? (could be tricky...)

In either case, send them along when ready and I can give them
a whirl.

FPF_TraceyG · « **Reply #46 on:** January 23, 2003, 02:45:26 pm »

Do you have MSN or ICQ? What I really need to do is to be able to test out a mission (which currently I havent been able to do on the D2), see if it actually works first, fix any major problems with it, recompile it, and get it to a point where it can be left on a server for exhaustive testing. So coordinating with you intitially would be helpful. Any chance we can arrange something like that?

DONOTDELETE · « **Reply #47 on:** January 23, 2003, 08:48:03 pm »

Just added ICQ # to my profile...

Sure, I figured as much would be necessary to
test a few missions.

I'm kind of busy this weekend, I am expecting
visitors tomorrow and the first Ottawa / Montreal SFC
meeting is on Saturday!

We could get started next week (Monday?).
Just check for me on ICQ to work out the details...

Goose · « **Reply #48 on:** January 23, 2003, 09:26:11 pm »

Ummm, Tracey...

I sent you an E-mail a little while ago about mission scripting, have you had chance to read it yet?

If so I now have a few more questions about the database in general.

Please answer...

UDF_Intruder · « **Reply #49 on:** January 24, 2003, 05:20:20 am »

Hmmm...MyISAM tables are the default type and they don't support transaction tables. Too bad.

FPF_TraceyG · « **Reply #51 on:** January 24, 2003, 11:53:18 pm »

Rajnsaj, I've added you to my ICQ contact list, thanks.
M'Ress, I've replied to your email as well...

FireSoul · « **Reply #52 on:** January 25, 2003, 11:36:56 am »

Good thing we're not using MS SQL:

http://securityresponse.symantec.com/avcenter/venc/data/w32.sqlexp.worm.html

-- Luc
FireSoul

Cleaven · « **Reply #53 on:** January 25, 2003, 05:00:04 pm »

The bad thing is we are locked to GSA which did go down.

clintk · « **Reply #55 on:** January 25, 2003, 07:03:24 pm »

The MS SQL Server worm highlighted here simply causes performance to degrade as the SQL Resolution Service sends thousands of packets to other services that run on the same port. Microsoft have published a patch to address this issue.

MySQL has several vulnerabilities, one of which allows a malicious user to obtain unauthorized database access by exploiting a vulnerability in the password authentication mechanism. A truly fundamental flaw ! Three tools have also been created that take advantage of a vulnerability in the check_scramble() function. No patch has yet been published to address this issue

I hope you now understand why I made such a fuss about us exposing the MySQL port on the firewall, or any database server port for that matter.

DONOTDELETE · « **Reply #56 on:** January 27, 2003, 07:57:57 pm »

Would it be somehow possible to post mission results to
a php script?

I already posted in the meeting thread on Off Topic forum:

"A few things congealed for me after discussions on
Saturday and I was motivated to find the limits of what
I could do with php to display and manipulate the EAW
D2 SQL database.

I managed to create an image based php-SQL webmap,
a battles summary and the beginnings of a real shipyard...?!?!?!!!!
There's still some work to go and there's a few rough edges
but I'm pretty happy with what I've gotten so far.

Php avoids many of the security issues with SQL server
features. (But work on a java solution has begun too...)

See the link below my signature pic..."

FPF_TraceyG · « **Reply #57 on:** January 27, 2003, 08:18:20 pm »

Well done on the website, rajnsaj. I can see quite a lot of work has gone into things there, and very interesting too.

How much control do you have over which ships appear in the shipyards?

DONOTDELETE · « **Reply #58 on:** January 28, 2003, 08:28:35 am »

Thanks!

Currently the php-shipyard is read-only.
Just a dump of the 'ship' table referenced to the
'servcharacter' table... (like the battles list is
a dump of the battles table referenced to the
'servcharacter' table)

I intend to produce adminstrative shipyards
where the whole shipyard can be edited (or by empire),
and a player shipyard where ships can be purchased,
repaired, supplied, traded-in... I am just starting to test
this capability myself with phpMyAdmin.

Currently mullling over how to handle shipyard login.
I might be able to use the phpbb forum login to handle it
or a combination of charactername WONlogon and a
new 'shipyards password'?

Then there is the matter of automating the population of the
shipyards, this will take a little more time. I am thinking it is possible
by leaving a local browser window open running an administrative
php script set to refresh in sync with the turn frequency.
This script could contain other database admin functions too.
(Or maybe a set of "cron" scripts for MySQL?)

I'm working out just what I can do with the database
now. It seems php has access to the full functionality of MySQL.
MySQL will not accept stored procedures though, i think.
There might be some packet size issues with editing blob fields
from php, but there is a setting to modify if so.
(I have yet to figure out the blob structures of
the Officers, Damage and Stores fields to edit them anyway)

(note: I read recently that there are no explicit 'foreign keys' in
MyISAM type tables. - was late, lost link to info, looking again...)

So, to make a long story short, I think I can have fully
automated control of the shipyards through php.

TOCXOBearslayer · « **Reply #59 on:** January 28, 2003, 05:41:42 pm »

Wow... I registared at your site and logged on to the D2 you have running... While the D2 it self was normal... the information available on the site was both amazing and somewhat distrubing....

You can see exactly who attacked what hex.(this is the disturbing part, I don't know if that much info should be availble).. how many folks were involoved, though it seems to always be 1+ how ever many people are actually in the mission. (no one was on and all my missions showed as having two players.) and lots of other stuff.. maps... shipyards.... sheesh....

All in all.... wow....

News:

Topic: Breaking new ground with Mission Scripting and SQL (Read 20304 times) var addthis_config = {"data_track_clickback":true};

UDF_Intruder

**DONOTDELETE**

Tao

**DONOTDELETE**

FPF_TraceyG

**DONOTDELETE**

FPF_TraceyG

**DONOTDELETE**

Goose

UDF_Intruder

FPF_TraceyG

FPF_TraceyG

FireSoul

Cleaven

FPF_TraceyG

clintk

**DONOTDELETE**

FPF_TraceyG

**DONOTDELETE**

TOCXOBearslayer

Topic: Breaking new ground with Mission Scripting and SQL (Read 20304 times)

DONOTDELETE

DONOTDELETE

DONOTDELETE

DONOTDELETE

DONOTDELETE

DONOTDELETE