Server Help

[Doc Flabby]

I'm trying to design a new settings system (using ASSS).

My question is this. Anyone got an idea of how I could do this?

Its needs to work in a generic way.

definitions:
ship - player controlled object (central in screen)
npc - computer controlled object. (ie sonething players can interact with)

There is no limit (or at least the limit isvery high) to the number of ships/npc.

Each object/ship has abilities (e.g. this would be the weapons, repels, rockets, thrust). These abilities can be used on one or more object/ship.

The behaviour and abilities of the abilities and ships would be linked to a binary module run on the client. Thus they are dependant on the "mod" loaded on the client. However server abilities would be controlled on the server. So there are really two type of settings, those that affect the server and those that affect the client. I'm suggesting these would be separated.
_________________
Rediscover online gaming. Get Subspace | STF The future...prehaps

[Dr Brain]

I'm sorry.... what's the point of this?
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

[Doc Flabby]

[Dr Brain]

ASSS isn't (IMO) well suited to other non-continuum clients. Too many of continuum's quirks are tightly integrated into the core.

[tcsoccerman]

doc you are talking about in-game right?

i suppose we could have a treenode setup. a node foreach ship/weapon/ability which then expands to that items settings.

[Doc Flabby]

[Dr Brain]

Any recursive hierarchical structure can be represented as a tree.

[Goldeye]

Why doesn't "TCP" work off of discretion? It's probably the best on-track client.

[Doc Flabby]

[Cheese]

tree idea good
seconded
_________________
SSC Distension Owner
SSCU Trench Wars Developer

[Dr Brain]

My point is that a tree isn't an idea.

[Goldeye]

[Doc Flabby]

[Goldeye_not_logged_in]

[Doc Flabby]

[Cheese]

cpp is ez, flabby :(

go learn it, takes like an hour :/

[tcsoccerman]

it doesn't take an hour...

[BDwinsAlt]

[Goldeye]

If you can code OOC in C#, you can code OOC in C++ with only a bit of syntactical learning. You probably need to know C (I don't believe C# has you syntactically dealing with pointers ever?)

If you can code in C, C++, or C#, you can manage mostly anything in any of them but fancy dealings with classes

[Samapico]

Anyway, the C++ issue is irrelevant. He said that to justify that he can't really help Discretion.
_________________
(Insert a bunch of dead links here)

[Doc Flabby]

[Samapico]

pointers are cool to work with, though. Once you understand them, you know exactly what's going on in your program. Even in C#, sometimes you're not sure if a parameter is by value or by reference, and it can be confusing...

[Animate Dreams]

Lol, it took me a while before I realised TCP was The Continuum Project, and not a protocol.... but anyway. Doc, I'm sure that by the time you're through with all the AS3 modifications you'll have to make, you'll have a pretty good idea of how to use C and pointers. Most of what I understand about how to use pointers came from AS3.

As for the tree structure, would the "nodes" be based on things like, guns and bombs(possibly in one category, Weapons), ships, items, etc., or would it be separated based on the module they came from? The latter makes more sense to me. Since a module, I assume, would be flexible enough to do something like create a new weapon, you could very likely end up with cases where a single module would add a few settings under Weapons, a new setting under Ships, new settings under Items, etc....

It makes me think of when I try to use Linux. Let's say I install Linux and it comes with Apache, or I add it with the package manager. It puts the binaries somewhere under /bin, the documentation under /docs, the config files who knows where, etc. To someone experienced with Linux, I'm sure it makes sense to them and they have little problem finding the files they need. But I prefer installing it myself so if I want a config file, I just go to /apache/config, or bin files in /apache/bin, etc.. I don't know if anyone else is bothered by things like that, but I am. From a developing standpoint, if I install a new module, I'd like to be able to esc+c and go straight to the module's settings and set them all.

As that's likely a matter of personal preference, I have another idea. I don't even know if it's plausible, but I'd like to propose it anyway. Settings could have labels. If you create a module, um... I don't know, TimedBomb, you'd have settings like TimedBomb.TimeToExplosion, TimedBomb.BombSize, or something like that. The settings could have labels like Type:Weapon and Module:TimedBomb. That way, you could sort by Module and scroll to TimedBomb, or sort by Type and scroll to Weapon. Obviously, if there was some item that came along with the module, its Type label would be Type:Item instead, and would show up under Items instead of Weapons. I haven't spent much time actually thinking about this, so I have no idea what different types of labels settings would need, or anything, but I think you get my idea. This way, different developers could sort their settings in different ways on the fly.

[tcsoccerman]

the nodes will not be based on modules, but based on files in an indicated folder (/ships, /weapons).

the zone creater will make those files, defining characteristics about each weapon. there won't be modules for each weapon/ship because that would make you need to know how tocode to make 1 ship in you're zone. that would be a great option though to be able to code a ship/weapon/ability rather than be limited by the editor that is given.

as for the last paragraph, alli can say is that you won't make modules to make a ship/weapon/ability, you'll make a file(ship/weapon/ability) with a given application.


that's how i understand it, and invision it.

[Animate Dreams]