General Question Career Mode

[Xyon]

It sounds like a good start point, though I'd like to see some form of progression as pilots complete missions, weighted according to the notional difficulty of the mission. I've seen straightforward "prestige" systems work okay for this, which controls pilot progression through various ranks; then, you start getting into having to have certain ranks to take on certain missions or fly certain vehicles - which should be under the control of the Admin user role you mentioned.

For the sake of clarity, are we shipping people .SCN files and requiring that they provide a return .SCN file to complete the mission? How will we determine if the mission objectives have been achieved?

Edit: Any open-source license works for me, and you both seem happy with the GPL, so let's stick with that. We're not actually (currently) talking about shipping an Orbiter component so I think that simplifies our licensing options a bit.

 

[Urwumpe]

For the sake of clarity, are we shipping people .SCN files and requiring that they provide a return .SCN file to complete the mission? How will we determine if the mission objectives have been achieved?

I would say the following is better: A Orbiter plugin that can be enabled or disabled. If you want to just practice a mission, you start Orbiter without the plugin. If you activate it, your progress will be increasingly live. We could start simple there and extend it.

So, you start by installing the plugin.
Then you download a scenario for that mission
You decide: Run with plugin or not.
When running with plugin, the plugin sends state data regarding spacecraft and mission to the server (JSON+REST)
When running without the plugin, there are no objectives, just the mission (Some sort of overly glorified mission editor)


For the start, it might make sense to limit missions to the following kinds of objectives:

Take off from base
Enter a specific orbit
Land at a specified base

Later we could include delivering payloads into a target orbit before time runs out.

Since the XR-Vessels come with a good additional API, we could also make the plugin use this API for special parameter checks/telemetry.

 

[jedidia]

Well, my idea would be using this there:

http://www.dropwizard.io/1.2.2/docs/

Sounds good, experimenting with another REST-framework fits nicely into my education schedule.

Does dropwizzard come with a DB attached right away? If not, what are we going to use? I'd lean towards some document-DB for this, much more flexible iteration cycles than with sql.

 

[Urwumpe]

Sounds good, experimenting with another REST-framework fits nicely into my education schedule.

Does dropwizzard come with a DB attached right away? If not, what are we going to use? I'd lean towards some document-DB for this, much more flexible iteration cycles than with sql.

I would say, for the beginning, a local H2 could be all we need. We'll use Liquibase and Hibernate there anyway, so the database behind doesn't matter, we are flexible.

 

[Face]

Any open-source license works for me, and you both seem happy with the GPL, so let's stick with that. We're not actually (currently) talking about shipping an Orbiter component so I think that simplifies our licensing options a bit.

I would say the following is better: A Orbiter plugin that can be enabled or disabled.

Danger, Will Robinson! :rofl:

I think nothing stops you from using MIT for the plugin and GPL for the rest of the system, though.

 

[Xyon]

I really don't want to get tangled up in the debate about the license, rather than talking about the project itself. If GPL is a non-starter because we haven't settled those issues with it, then the other two mentioned were MIT / Apache, let's just pick one and stick with it

 

[jedidia]

We'll use Liquibase and Hibernate there anyway, so the database behind doesn't matter, we are flexible.

With JPA on top of hibernate, or just hibernate? Never used hibernate directly... :shifty:

I'd suggest Kotlin as implementation language, in any case (seems to work without issue with dropwizard from what I can gather). It saves about 20 to 30% boiler plate when compared to native java...

 

[Xyon]

With JPA on top of hibernate, or just hibernate? Never used hibernate directly... :shifty:

I've never used any of this, and I'm starting to wonder what I can contribute to this beyond a server container and some words. I can do the C++ bit for Orbiter, but I've never really written Java beyond a "hello world".

 

[jedidia]

I can do the C++ bit for Orbiter, but I've never really written Java beyond a "hello world".

Basically Java is safe but annoying C++. The syntax is extremely similar.
The real problem in the Java ecosystem are the frameworks and libraries...

Also, "the C++ bit for orbiter" won't be trivial. As far as I can see, it's basically a REST client inside an orbiter module. I will gladly leave the task of writing any kind of client in C++ to whoever is not me :shifty:

 

[Face]

As far as I can see, it's basically a REST client inside an orbiter module.

Well, the typical ReST client is basically a TCP connection that sends/receives HTTP payload, often encoded in JSON. Ok, it is pretty picky on the HTTP result codes, too. :lol:

However, this particular ReST client would have to actually do something as well, as it has to check:

Take off from base
Enter a specific orbit
Land at a specified base

Later we could include delivering payloads into a target orbit before time runs out.

Since the XR-Vessels come with a good additional API, we could also make the plugin use this API for special parameter checks/telemetry.

One thing, though: how would you want to prevent cheating? I know, it is not a problem if the system is just for fun at first. But if people start to get invested - and if it is only emotional - it will become one for sure.

 

[jedidia]

However, this particular ReST client would have to actually do something as well, as it has to check:

Oh sure, but the logic seems like the easy part to somebody that has never written any kind of network code in C++, and native C++ at that. :lol:

One thing, though: how would you want to prevent cheating?

My approach would be to worry about that when/if the thing actually starts seeing widespread use...

 

[Xyon]

Oh sure, but the logic seems like the easy part to somebody that has never written any kind of network code in C++, and native C++ at that. :lol:



My approach would be to worry about that when/if the thing actually starts seeing widespread use...

REST clients I've done, but like you never in C++. I like a challenge, though.

However, this particular ReST client would have to actually do something as well, as it has to check:

Yeah, this task is easier for more complicated vessels, but it should really be something doable with the basic vehicles where possible, for as wide a compatibility range as possible.

 

[Face]

My approach would be to worry about that when/if the thing actually starts seeing widespread use...

In my experience it is hard to add that kind of security late in a system's life-time. That's one of the reasons for my arguments in the blog entry.

The idea of a progress checking plugin was already implemented by Tofitouf back then, but it never started to see widespread use. It would be interesting to hear what he thinks was the reason for it dying out. Over-engineering (too much for one person to deliver)? Too small community? Too little content?

 

[Urwumpe]

One thing, though: how would you want to prevent cheating? I know, it is not a problem if the system is just for fun at first. But if people start to get invested - and if it is only emotional - it will become one for sure.

Well, its a later problem. What ever we will create, it won't be final and we will likely learn about problems we won't have thought about this week.

About Kotlin: Wanted to learn it one day, but I think this project isn't a good time to do it.

---------- Post added at 15:24 ---------- Previous post was at 15:20 ----------

With JPA on top of hibernate, or just hibernate? Never used hibernate directly... :shifty:

Well, Hibernate is a JPA implementation. So "on top of hibernate" or "just hibernate" go into the wrong direction... its "JPA by hibernate"

We could also use JPA to create the DB scheme, but I made the experience that Liquibase is the more stressfree way to handle schema changes.

---------- Post added at 15:28 ---------- Previous post was at 15:24 ----------

In my experience it is hard to add that kind of security late in a system's life-time. That's one of the reasons for my arguments in the blog entry.

If somebody manages to create a fake client to send REST messages to the server, whatever we do for preventing the fakes will be an eternal circle of learning of new cheats and preventing them.

I am strongly opposed to security by obscurity there.

 

[jedidia]

About Kotlin: Wanted to learn it one day, but I think this project isn't a good time to do it.

The learning curve is surprisingly flat, actually. You can basically start by writing Java with a better syntax. A much better syntax.

Well, Hibernate is a JPA implementation.

Oh? I had assumed JPA was a wraper around hibernate. Goes to show how confused I still am about things I work with every day.

I made the experience that Liquibase is the more stressfree way to handle schema changes.

Yeah, if we're going for a DB that requires a fixed schema, I'm all for liquibase.

In my experience it is hard to add that kind of security late in a system's life-time.

It is, but I think it's too big a feature to implement without being sure it will be needed.

 

[Face]

I am strongly opposed to security by obscurity there.

I agree. That wasn't my argument, anyway.

---------- Post added at 15:43 ---------- Previous post was at 15:40 ----------

It is, but I think it's too big a feature to implement without being sure it will be needed.

Fair enough.

 

[Urwumpe]

I agree. That wasn't my argument, anyway.

Yeah, but since we are open-source, everybody can read how our anti-cheat solutions work. All that we can keep secret are the private keys or similar security mechanisms for securing the communication.

But that does not prevent a skilled hacker from creating his own implementation of our client.

I would rather pay attention first to basic stuff - session management, denial of service, input parameter validation.

 

[Xyon]

I suspect that, considering what we're creating here is player-managed and player-driven, we can to some extent leave them to police themselves; a co-operative multi-person VSA can choose to kick people out if they have evidence of foul play (we should provide an option for this, naturally).

People cheating in a single-player mode should be free to do so, they're only cheating themselves; IMHO there's no real drama there.

 

[Urwumpe]

I suspect that, considering what we're creating here is player-managed and player-driven, we can to some extent leave them to police themselves; a co-operative multi-person VSA can choose to kick people out if they have evidence of foul play (we should provide an option for this, naturally).

People cheating in a single-player mode should be free to do so, they're only cheating themselves; IMHO there's no real drama there.

Yeah. Also people trying to give themselves more rights might be an issue for us.

That is also why I designed the three scopes (Server, Universe, VSA) there, because that allows limiting damage by cheating as well. A server admin user should better to prohibited from also being a regular player - alone for the fairplay. :lol:

Also, how the rights are handled could also be implemented different later.

For example, we could also add something like parliament groups for VSAs or Universes later which vote on specific changes to their entity. But we don't need it now - we just should not block the path for such ideas by "optimizing" too soon.

 

[Face]

Yeah, but since we are open-source, everybody can read how our anti-cheat solutions work. All that we can keep secret are the private keys or similar security mechanisms for securing the communication.

But that does not prevent a skilled hacker from creating his own implementation of our client.

I would rather pay attention first to basic stuff - session management, denial of service, input parameter validation.

My argument back then was that there is no automatic evaluation plugin at all, precisely because of what you wrote. In a way, it is using Xyon's argument of the self-policing community.

It would be another human that is validating and scoring the performance of a pilot. Doing all the server-side stuff of session management, authentication, authorization, validation and the usual cloud things is hard enough to get right first.

Perhaps it is better to start with the mission list, some user database and the possibility to hand in mission flight recordings for peer review. Those reviewers would then rate the recording and hand out appropriate "points" and/or career advancing.

IMHO, an automated open-source evaluation plugin for such a system without some anti-cheat feature right from start is a social train-wreck waiting to happen.