SubSpace Java Client

[Hakaku]

It wasn't so much for security, but rather because I find that people who open source and use repositories tend to discourage themselves and give up developping a lot quicker.

[★ jabjabjab]

Yeah I noticed that.

 

 

Also: added a teamspeak server.

 

Server: theAphelion.com

 

I feel like allowing people to come on and discuss things would make a lot more highlight for problems that i havent seen yet, or just ideas to work with.

[★ Ceiu]

It wasn't so much for security, but rather because I find that people who open source and use repositories tend to discourage themselves and give up developping a lot quicker.

 

That's an interesting point of view on the matter. What makes you say that? Personally, I'm inclined to believe the opposite (or perhaps that there are more variables that aren't being taken into account).

[★ jabjabjab]

http://i559.photobucket.com/albums/ss31/XDreamersMS/Continuum/Aphelion/welcome1.png?t=1334773639

 

Added a fancy "In development" page to the theAphelion.com domain.

[★ Dav]

Looks nice

 

On my system clicking the image just zooms it rather then links here though.

[★ jabjabjab]

0_o mmk.

[★ ZiGNoTZaG]

Maybe this has already been mentioned or discussed but I think it would be a nice feature if "every" graphical item was configurable like LVZ. You can define the frame count and display speed, ships excluded. Also each item should have the option for variants. Like one could have X different prize graphics and the client would pick one at random for each green it displays.

 

With ships you could have a few variables like preferred and exclude. Preferred would be a list of ship graphics you prefer the client to choose from as yours. Exclude would be ship graphics you want the client not to give to other players. So if you had 8 different Warbird graphics installed with your client you could prefer 3 Warbirds from those 8 sets, and exclude those Warbirds from appearing as other players.

 

Sounds as well.

 

Suppose there would have to be some modest limits to prevent issues.

[spidernl]

I suggest going with a subspace clone with a client-side module system which is synchronized with the server like maps are. You'd get a download when entering the zone where modules are downloaded and loaded into the client.

 

Then you don't have to "hardcode" this kind of stuff. Someone wants to make a zone with 16 ships and each ship has 18 different skins buyable with points? Let them code it themselves.

[JoWie]

Current idea is to allow the server to send ecmascript/javascript files which are run in the JVM (Java 6 has Mozilla Rhino), these would be sandboxed by using a SecurityManager. Edited April 19, 2012 by JoWie

[kylratix]

Current idea is to allow the server to send ecmascript/javascript files which are run in the JVM (Java 6 has Mozilla Rhino), these would be sandboxed by using a SecurityManager.

 

+1

[★ jabjabjab]

Added draggable, clickable, closable, and optional transparent window objects.

[kylratix]

Hot. How about dialog windows that can be fed an HTML view? You could define an out-of-the-box CSS that works with your GUI. Server plugins could simply call your API and point at static html/css/js files.

[L.C.]

Hot. How about dialog windows that can be fed an HTML view? You could define an out-of-the-box CSS that works with your GUI. Server plugins could simply call your API and point at static html/css/js files.

I can see some people having a second monitor just for stuff like radar, player list, and chat. Chat could occupy bottom half, and both the player list and radar taking up the upper half 50% of the page width each.

[spidernl]

That would be one huge player list. And chat window.

[kylratix]

That brings up another point though, you could make all of the interface components as windows that can be moved, pinned, and/or pinned seamlessly. This would make it easy for mods to swap out interface components. For example, if Cheese wanted to run a server that represents energy/health by unicorns rather than a bar, he could.

[★ jabjabjab]

So I just had a really cool idea. What if we could manage to have a option to convert chat to a language specified using google translate? (wonders if they have a simple call and answer system for google translate)

[Cheese]

they do

 

http://translationparty.com/#10210225

[Cheese]

http://googlesystem.blogspot.com/2009/08/google-translate-equilibrium.html

 

its very easy to use

[kylratix]

i thought they disabled the api?

 

[edit]

ah, correction. it's just not free anymore.

Edited May 3, 2012 by kylratix

[kylratix]

btw, why have the server handle chat? it's extra load without much benefit. the client could just use irc. the nice part with that is that the server's social pull would span beyond in-game stuff. regulars could chat throughout the day without having the game open. (at work using pidgin, adium, etc.)

[JoWie]

yea one of the ideas was to have separate chat servers. But probably not IRC because it has a lot of limitations, especially with nicknames. I had to use a lot of workarounds in that asss irc server script.

 

XMPP (jabber) looks nice. It is a decentralized protocol and extensible.

Every in game player could have a nickname@subspace.net handle. And someone with google talk, pidgin, etc could communicate with you.

Edited May 3, 2012 by JoWie

[Dr Brain]

Doesn't seem much point in having the server not handle chat. It's probably 1% of the packets that it handles, and the clients still need to send ?commands to the server. So a lot of extra complexity with very little gain.

 

Still, that doesn't mean you can't integrate some external chat with the game. I think that makes a lot of sense if you do it on the server and not the client.

[★ ZiGNoTZaG]

I would think it might be a good thing to do away with the chat commands that are not related to chat and put those in the GUI. Perhaps in one of those fancy clickable dragable windows. A auto collapsing command bar? Chat would be just that, communication with other players. Commands related to gameplay and stats would be menu/hotkey based.

[Dr Brain]

Sounds like a huge step backwards. Put the frequently used commands in a GUI, of course, but don't make them impossible to use through typing. Commands are the easiest way to do complex server interaction.

[JoWie]

Yes, that was not intended for chat local to the server (pub chat, etc). Not involving the game server with remote chat is also easier to secure (against evil game servers).

 

As for commands, it is very likely everything is going to become a command (like firing your weapon).

You would then be able to map any command to a keyboard button.

Edited May 3, 2012 by JoWie