Dynaverse.net

Taldrenites => Starfleet Command Mission Scripting => Topic started by: CFA_Admiral_Tige on May 14, 2003, 07:23:41 am

Title: Its not pretty, but...
Post by: CFA_Admiral_Tige on May 14, 2003, 07:23:41 am
I am in the process of creating missions (both single player and multi) for SFC I, and II using FMSE and C++ API(Visual C++ just arrived last night)..I have a few of them up on my site, with a short description of the mission.  Now, i realize the first moment you enter the site, it will look, well, amuteurish.  With a site budget of $0.00 and having it all in HTML, its hard to be fancy.

The site is www.angelfire.com/trek/cfafleetdock ,enter the site, and go to simulator.  

P.S. The counter on the left side is malfunctioning....I realize it says 34000+ people, but i can guarntee less then 500 have seen the site.

Happy Flying
Tiger  
Title: Re: Its not pretty, but...
Post by: Klingon Fanatic on May 15, 2003, 09:35:49 pm
Any chance you can try converting missions to SFC: OP?

I would love to see the SFC1 missions: The Repair Roundevous and the custom mission: The Quantum Factor (at Starfleet Universe.com under SFC1 missions at least playabe in SFC2.


KF
Title: Re: Its not pretty, but...
Post by: Toasty0 on May 16, 2003, 12:51:45 am
Tiger,

Check out thse folks. http://www.brinkster.com/

Also, you might want to drop the frames. They're notoriously hackable.

Best,
Jerry  
Title: Re: Its not pretty, but...
Post by: CFA_Admiral_Tige on May 16, 2003, 06:45:31 am
interesting...define hackable  



p.s. did the links for the missions posted work???
Title: Re: Its not pretty, but...
Post by: Toasty0 on May 16, 2003, 11:01:21 am
Quote:

It seems that all of Microsoft's and Netscape's web browsers have security holes (though, of course, the latest ones never have any that we know about -- yet). This includes URL, HTTP, HTML, JavaScript, Frames, Java, and ActiveX attacks.
URL fields can cause a buffer overflow condition, either as it is parsed in the HTTP header, as it is displayed on the screen, or processed in some form (such as saved in the cache history). Also, an old bug with Internet Explorer allowed interaction with a bug whereby the browser would execute .LNK or .URL commands.
HTTP headers can be used to exploit bugs because some fields are passed to functions that expect only certain information.
HTML can be often exploited, such as the MIME-type overflow in Netscape Communicator's <EMBED> command.
JavaScript is a perennial favorite, and usually tries to exploit the "file upload" function by generating a filename and automatically hidden the "SUBMIT" button. There have been many variations of this bug fixed, then new ways found to circumvent the fixes.
Frames are often used as part of a JavaScript or Java hack (for example, hiding web-pages in 1px by 1px sized screens), but they present special problems. For example, a savy attacker can include a link to a trustworthy site that uses frames, then replace some of those frames with web pages from my own site, and they will appear to you to be part of that remote site.
Java has a robust security model, but that model has proven to have the occasional bug (though compared to everything else, it has proven to be one of the most secure elements of the whole system). Moreover, its robust security may be its undoing: Normal Java applets have no access to the local system, but sometimes they would be more useful if they did have local access. Thus, the implementation of "trust" models that can more easily be hacked.
ActiveX is even more dangerous than Java as it works purely from a trust model and runs native code. You can even inadvertently catch a virus that was accidentally imbedded in some vendor's code.
SMTP (SendMail) attacks




Best,
Jerry  
Title: Re: Its not pretty, but...
Post by: CFA_Admiral_Tige on May 16, 2003, 02:02:30 pm
Ty a lot Jerry...also for that link there...it appears i can write out the site in C++...something i am learning more and more everyday!


Ty Again,
Tiger