Phoenix SS Game Client Alpha .25d

[Vidiot_X]

It's Finally Here!

 

This is really a client/server but I have disabled all the net code for now. I am reworking this. The game client uses all of the systems engines with the exception of collision, which is disabled while I work on the level editor. Each of the bullets are independently controlled by the physics engine. This means when collision is enabled each bullet will bounce off objects with full physics control (friction, speed, etc ).

 

Some other features not seen but in place are camera shake; the screen shakes when you ship hits an object. Simple listener server and client networking code. Effects like repel and bombs. And more...

 

You should be able to use the Phoenix SS level editor to create new maps and run them in this client. See the readme html about this.

 

Be sure to report issues to the forum link listed above and not my email.

 

I expect to have a networking version out within 90 days of this release.

 

Check out my web site for pics: http://redeyeware.zxq.net/

 

Richard Betson

SubSpace Nick: Vidiot_XPhoenix_ss_client_alpha_25d.zip

Edited November 26, 2010 by Richard Betson

[»jabjabjab]

Cool. 2 things to spot: when ur ship moves at an offset, not good for the nostalgic players (assuming offsets throw off balance)... and insert could be funny too, but thats for replicating perspectives... other than that, with some fancy gfx tunning this could be the shit.

 

overall, astounding progress. thumbs up!

[Vidiot_X]

I'm assuming your talking about the player/ship slightly moving off center. You can adjust the offset in this file (for the ship/player): swift.dyn

 

Change the field "elas_bounce#=8.8" to 1.1 . Don't go below 1.0 or your screen will wildly move back and forth. This should keep the player/ship pretty much dead center. Within this file and "bullet.dyn" you can make other changes to speed, gravity and more.

 

So go ahead a play with these settings and see what you can do. You should probably make a copy of the original files before attempting.

 

As to graphics, there a little rough but I'm hoping that as development continues myself and others will come up with some "Bitch'n" graphics.

 

"overall, astounding progress. thumbs up! " Thanks!

 

Richard Betson

aka. Vidiot_X

[»jabjabjab]

My continuum library of graphics

 

 

ready whenever you are

[Vidiot_X]

Cool,

 

For now you can add parts to the level editor by editing (use notepad or such) this file:

parts1.lst

 

It's a little tricky but all you really need to do is copy the last 5 lines in the file and add them to the end. The last 5 lines will look like this:

 

floor5.png

Pipe Floor 2

0.8

3

0

 

and what they mean:

------------------

File name of image: floor5.png

Field name of image: Pipe Floor 2

Alpha or Transparency: 0.8

Blend Style Number: 3

Z-Order or Layer order: 0

 

Settings/ranges

---------------

Field name of image: Needs to be unique. Different from the other parts.

Alpha range: 0.0 - 1.0

Blend : 3= Masked Blend (keep this set to 3)

Z-Order: Use 0 (zero) for floor and 210 for walls

 

 

So just copy the last 5 lines and add the them to the end (no empty lines between). You do this for as many parts as you need. Try to keep the map parts at 128 x 128 pixels or smaller. This may mean breaking up larger images into smaller pieces.

 

If this is not clear just let me know. I'll see what I can do in the short term to make this easier, but it won't be long before I add collision and then the level editor will take care of this for you.

 

Richard Betson

aka. Vidiot_X

Edited November 30, 2010 by Richard Betson

[»jabjabjab]

hmm... Have you ever seen lvz structure notepad work? There any way that this simularity can be followed? (just wondering)

 

Here's a example INI from from the oldschool toolkit:

; OutFile specifies lvz file data is written into and it is overwritten if already present
OutFile=example.lvz

; With File= you can specify files that are placed into Continuum's zones\<zone name>
; directory or zones\<zone name>\arenaname directory if lvz file is used in subarena.
; As Continuum looks for graphics and sound files from zones\<zone name>\arenaname, 
; zones\<zone name> you can customize all graphics and sounds

File=ships.bm2
File=bomb3.wa2
File=Subspace.hlp

; [objectimages] section specifies images used by [mapobjects] and [screenobjects]
; section later. Syntax of image is following:
; IMAGE<number>=<filename>,<x tiles>,<y tiles>,<anim period>
; where <number> is 0-255, <x tiles>,<y tiles>,<anim period> are optional parameters
; that are used to specify animated images. if <x tiles> and <y tiles> present, 
; image file is treated as collection of x*y images. <anim period> is given in 1/100th
; seconds and determines speed of animation

[objectimages]
IMAGE0=ssshield.bm2,10,1,100
IMAGE1=b_ad0.bmp
IMAGE2=medal.bm2

; [mapobjects] section specifies object locations on map. Syntax of mapobject 
; specification is following
; <x coord>,<y coord>,<image>,<layer>,<mode>,<display time>,<object id> where
; <x coord> and <y coord> are where upper left pixel of the image is placed on map. 
; center is 8192,8192, top left 0,0, bottom right 16384,16384. <image> specifies what
; images is displayed from [objectimages] section and has format IMAGE<number>.
; <layer> is one of following: BelowAll,AfterBackground,AfterTiles,AfterWeapons,
; AfterShips,AfterGauges,AfterChat,TopMost and specifies when the image is displayed
; ie if ships go behind or above it on user screen 
; <mode> is one of following: ShowAlways,EnterZone,EnterArena,Kill,Death,ServerControlled
; and specifies when the object is displayed. 
; ShowAlways: is default and means that this object is visible. 
; EnterZone: object is displayed to players who enter zone for <display time>
; EnterArena: object is displayed to players who enter arena for <display time>
; Kill: object is displayed to players who kill somebody else for <display time>
; Death: object is displayed to players who die else for <display time>
; ServerControlled: object is displayed when moderator issues *objon for <display time>
; <display time> is given in 1/100th seconds
; <object id> is optional number that specifies object id, so that object can be 
; turned on and off with *objon and *objoff server command or moved around by bots

[mapobjects]
8192,8192,IMAGE0,AfterTiles,ServerControlled,500,1
0,0,IMAGE2,AfterTiles

; [screenobjects] section specifies object locations on user's screen. Syntax is following:
; <x coord>,<y coord>,<image>,<layer>,<mode>,<display time>,<object id> where
; <image>,<layer>,<mode>,<display time>,<object id> are same as in mapobjects
; <x coord> and <y coord> are coordinates on screen with following additions:
; numbers prefixed with C are relative to screen center (as opposed to upper left corner
; as normal screen coordinates) and negative numbers (without C prefix) are relative to
; bottom right screen corner

[screenobjects]
C-146,29,IMAGE1,AfterChat,EnterZone,3000
12,12,IMAGE0,AfterTiles,ServerControlled,100000,1000

 

 

I think that using the same structure, but rebuilding the mapobject/Screenobject segments to fix updated potential properties such as local offsets or alpha would be wonderful and more easier for the current lvz people to work off of.

[Vidiot_X]

Interesting,

 

I have not decided yet on which approach to take on map scripting. Many professional games use LUA (http://www.lua.org/about.html) which basically allows me to "hook into" the functions within my own code. It also allows data to be passed to and from the script. This would enable a very robust scripting language allowing the user a great deal of control and flexibility.

 

But, on the other hand I have to consider security. We would not want others to change the map, in an effort to cheat on the client side. So maybe I'll have the option to save from the level editor a script version and then also a publish version that will be encrypted. In today's world of protected memory this might be overkill, But in my mind security is important.

 

It's cool though to see some script that everyone might be used to already as a base for the future.

 

I tend to take on these issues as I need to deal with them. So it will be a little while before I actually deal with standardizing a scripting language. But It's good to have a discussion about it now, as well as security issues.

 

Richard Betson

aka.Vidiot_X

Edited November 30, 2010 by Richard Betson

[»jabjabjab]

In today's world of protected memory this might be overkill, But in my mind security is important.

 

Security made Continuum the used client of today really, If you do know the history of subspace. Short and quick, subspace almost lost it's community base entirely due to a hack called "Twister" which was coded to fuck up subspace, give thors, and all that silly jazz.

 

Priit put an end to this with his client we use today. Security means everything when it comes to this community. It's amazing after all that time, I still see people held into their conditioned cautions for hackers and cheaters, and high-risk trusting positions in staff holdings.

 

Secure the variables, and do up-to-date-par-w.e. checks that does what needs to be done to keep the variables that are vital safe.

 

I mean think about it right now dude, twister was coded, which means shit like that was hard to get back then, but now, when we have speed hackers and memory hackers, and even disassemblers,

It means everything to constrict the vital things.

 

Back then, it was impossible to get into continuum and fuck it up (well almost, with the handful of smarties) But nevertheless, people still always want to cheat, and this must be secured. The more flexible the client, the more measures to be taken to fix this. Hell, I mean I know nothing rly about unpacking and encryptions, but today, *a year ago* I spent 4 hours digging into the Pex encryption Priit did for the client, and found a way to reverse it. It was just that easy nowadays, *even though i could not take out the security checks placed on the client before opening up. Make sure to have all checks up to date.

 

 

I know nothing about coding honestly, but the best way i see it is, If we can allow custom code to be written, and compiled (like lvz) to take over some methods and variables you give to allow modifications (within arena boundries, dis-including the server-side global boundries) then we can have a playground with more slides and sandboxes and all the fat kids to stroll by and beat up with.

 

 

All in all, just ask yourself how protected this client would be ten years down the road, because I know Priit did; he even came back and placed new extended fixes to prevent cheat engine's newest bunk.

Edited December 1, 2010 by jabjabjab

[Vidiot_X]

I am totally with you on this...

 

Hacking is one of those things you will have to deal with on an on-going-basis. Take satellite TV. First for C-Band they came out with videocipher 1 (encryption) which no one could break. They hacked it. Then Videocipher 2. They hacked it. The same for Dish and DirectTV, and these guys are huge. Lots of R&D cash. Even Sony after spending millions on coming up with a way to prevent copying audio CD's found it self hacked. The hack was carefully taking an ink pen and blacking out the most outer track. Millions of dollars in R&D thwarted by an ink pen. It will make you laugh.

 

My point is I intend to make the system as secure as possible; but it will be hacked. Once I have good security scheme in place I will put it out there and see what happens. This why it's good to have as long a beta testing period as you can. By simply having it out there hackers can't resist (well most). I am not up to specs on the best approach to provide security within this game. The good news is that I have access to those who know all about this kind of thing.

 

I have done a little research into SupSpace's history and I am aware of the security issues of the past. But as I recall the system was not very secure to begin with. There is nothing more annoying then someone blasting with unlimited thor's. Be assured that I am prepared for the security issues that will arise, squash them and move on. In fact I am looking at this now in the way the client and server will work together. Determining how much control the client will have. For example even though the client is assigned a ship with a particular weapon, they are not active until the sever sends a release code (encrypted) each time the ship is spawned. Meaning every time your ship is destroyed, your weapons are dead until verified and then sent a release code. If your client is somehow hacked and is trying to use a weapon outside your class or exceeds your class limits your banned. In the case of specials like thor's similar constraints are put into place. This is just one example, but I hope you can see that already thing about it.

 

Richard Betson

aka. Vidiot_X

Edited December 1, 2010 by Richard Betson

[»jabjabjab]

Make sure to do what Priit did when it came down to packets, which was illegal weapons, mismatches, etc. Do this. Problems will come up, but problems are better to know about, then to go unnoticed.

[Vidiot_X]

Right on,

 

Follow this thread:

http://www.blitzmax.com/Community/posts.php?topic=92828

 

Most of the networking packages I'm looking at take care of this sorta thing (malformed packets if I get you right) including security/flood and alike. I am looking hard a Raknet which is widely used and solid, but hard to code with. The cool part is as long as the game is "free use" ( FMOD License ) it supports voice over IP which would totally rock in a SubSpace style game. I want this!

 

Richard Betson

aka. Vidiot_X

[Cheese]

translation:

use security checksums on all packets recieved, as well on every file loaded by the program

[Dr Brain]

translation:

use security checksums on all packets recieved, as well on every file loaded by the program

Checksums are great for finding errors caused by corruption, but virtually worthless against attacks.

[Cheese]

unless you count packet manupulation or maphacks like adding extra tiles

[Dr Brain]

A checksum won't help against those, as I already said.

[Drake7707]

While it's good to keep security in mind, don't try to do too much at once. Finishing features to make the client/server fully functional should take priority over the security measures to prevent hacking, otherwise the code will get messy quickly and it will be a pain to continue developing (I've been there too many times). Besides if you have a clean object oriented model it shouldn't be that hard to create an extra tier of security.

 

Not to criticize you or anything, you're doing great

[Vidiot_X]

"While it's good to keep security in mind, don't try to do too much at once."

 

Right on. Laying out your server/client scheme is the first step. This alone when done correctly can reduce hacking and cheating. Structure, Low data rate and and over all networking quality are my current quest. I am doing quite a bit of research on these, which is another first step.

 

Yes; I have an object oriented model. Everything is pretty much an object from the map to the player. Even the "Bullets/Ordinance" all are separate objects. It does make it very easy to network and deal with security issues.

 

Richard Betson

aka. Vidiot_X

[aquarius]

Into fullscreen and immediately out with caption: "EXCEPTION_ACCESS_VIOLATION"

 

Windows 7 64bit, let me know if you want a full error report. mail@jesse.pro

[Vidiot_X]

That's usually the result of a file (image or other type) missing. I have not hooked in try/catch error trapping yet so Phoenix SS will throw this kind of error. You could try re-expanding (unzipping) the file again and see if it runs.

 

Which resolution and graphic driver did you use? An unsupported graphic driver could throw the same kind of error. I'll be adding some error trapping in the next update to try catch some of the common errors.

 

Thanks for reporting your error.

 

Richard Betson

aka. Vidiot_X

 

-EDIT-

 

OK, I've added error checking to most of the areas that might cause a problem. If you can not get it working please wait for the next version. It should help isolate your error.

Edited December 26, 2010 by Richard Betson

[BDwinsAlt]

Works flawlessly with WINE on Ubuntu 11.04 64 Bit with OpenGL (Yeah I know 11.04 is in beta until April)

 

I got 62 FPS constantly. I really like this client. Keep up the good work!

[Vidiot_X]

Right on. That's cool to know.

 

I'll have a new version out soon. Right now I'm a little busy writing demo's for a new programming language, but that should only be a couple more weeks.

 

Richard Betson

aka. Vidiot_X

[XO-MANOWAR]

Use the Open Gl tab and the lowest res..should work just fine.Im usin Win 7 Quad Core Phenom 2 w/ATI 5770.

 

Yeah Good stuff man....

[aquarius]

DX7 and DX9 Throw this error upon launch: EXCEPTION ACCESS VIOLATION

 

OpenGL Causes crash and windows says this:

 

Problem signature:

Problem Event Name: APPCRASH

Application Name: phornix_ss_client_alpha_25d.exe

Application Version: 0.0.0.0

Application Timestamp: 4ceeee49

Fault Module Name: StackHash_e98d

Fault Module Version: 0.0.0.0

Fault Module Timestamp: 00000000

Exception Code: c0000005

Exception Offset: fffffd34

OS Version: 6.1.7600.2.0.0.256.1

Locale ID: 1033

Additional Information 1: e98d

Additional Information 2: e98dfca8bcf81bc1740adb135579ad53

Additional Information 3: 6eab

Additional Information 4: 6eabdd9e0dc94904be3b39a1c0583635

I guess it doesn't help I have DirectX 11? Is DX supposed to be backwards compatible, or is this client just not able to utilize DX11? Or maybe these things have nothing to do with the problem? If you need an error report from console let me know how to get that to you.

Edited March 17, 2011 by Aquarius

[Vidiot_X]

@ Aquarius

 

Try using this current version here:

 

http://forums.ssgn.net/topic/25355-phoenix-ss-client-alpha-29int/

 

 

That kind of DX error usually is a missing file needed (included in zip file) by Pheonix SS, which may be causing the OpenGL error as well.

 

I use Win 7 and DX 11 and all is well. What Graphic card do you use? Some video cards have poor OpenGL support.

 

Thanks,

Richard Betson