Brainstorming for a MultiUser OXP

[phkb]

That's certainly strange. This command works fine from my debug console:

Code: Select all

player.ship.manifest.food += 10

Is %d a decimal? If so, it should really be an integer.

[hiran]

That's certainly strange. This command works fine from my debug console:

Code: Select all

player.ship.manifest.food += 10

Is %d a decimal? If so, it should really be an integer.

Yes, the number to be formatted has to be integer. Definitely not a float or other string.

Thank you for the heads up - at least I can trust in the command itself. Then I can search for the bug elsewhere.

[Milo]

Code: Select all

Try [“%s”] instead of .%s
Or make sure commodity name is correct

[hiran]

That's certainly strange. This command works fine from my debug console:

Code: Select all

player.ship.manifest.food += 10

Is %d a decimal? If so, it should really be an integer.

Code: Select all

Try [“%s”] instead of .%s
Or make sure commodity name is correct

Thank you both for suggestions. I tried to debug the code and while at that make logging and error handling better.
All of a sudden the situation no longer arises, which is actually a good sign. Unless it pops up again I will consider it closed.

So I am working a bit on the startup of the application and user friendlyness.

[Cholmondely]

Just came across these:

That's an interesting idea. Instead of Elite in its entirety, why not take one aspect of it and turn it into a networkable game?

For example:
Academy: players are flight school students learning the ropes around Lave.

Thargoid War: players are navy or thargoid pilots in the deadly Sector 32.

Pirates: in the lawless sytem of Zaonce, pirate clans take on the cops and the navy.

System Trader: A natural disaster has decimated the main world of the Ededleen System. The players are either escorts, pirates, traders or the law and must help to rebuild the world. The navy has set up a boundary where large tradeships must stop, and the player ships must load up from these big ships and take stock to the world's station.

All of these would run on a smaller timeline than the main game - maybe a set span of up to 10 years in game, maybe with a running plot and maybe just a free-for-all.

Mission ideas for single-system non-massive Oolite:

• Much as Pirk says, one side defending a transport or similar from the other. Two rounds, one attacking and one defending for each team.
• Team combat. Each team spawns around a station, then tries to rack up the kills. The station can be used to refuel, recharge shields and possibly buy missiles. Obviously no auto-docking.
• Team combat 2. Each team spawns some distance away from a single, shared station.
• Individual combat. Each player spawns some distance from the station, distributed roughly in a spherical shell around it.
• Team mothership. Each team spawns around a dockable mothership, which is destructible. The goal is to destroy the enemy mothership.
• Ring race. With and without weapons.
• More creative games I thought of once but can’t remember.

General setup:

• No energy bombs, escape pods, hyperdrives, energy bombs or docking computers.
• Everyone has an advanced targeting system and a space compass from the start. Stations/motherships show up on the compass and are colour-coded. Teams are also colour-coded on the scanner. You should probably start with a fuel injector too.
• Optionally, kills are worth money which can be used to buy stuff (excluding the banned items above) on stations and motherships. Otherwise, missiles and fuel are free and other stuff isn’t available.

That thread also contains some links to others as well as two analyses of issues with multi-player, one of which looks at the economics (more expensive back in 2005/6, I'm sure...)

[hiran]

Just came across these:
[...]

That thread also contains some links to others as well as two analyses of issues with multi-player, one of which looks at the economics (more expensive back in 2005/6, I'm sure...)

I totally agree this is somehow within reach.
After all I realize that I stabilized my code somewhat so it can run as proof of concept and we could start discussing how to actually implement the above visions.

But on the other hand I notice there is not much feedback or resonance about the stuff we achieved so far. So who else would dive in to play together? Who would help create combined missions?

[Cholmondely]

Just came across these:
[...]

That thread also contains some links to others as well as two analyses of issues with multi-player, one of which looks at the economics (more expensive back in 2005/6, I'm sure...)

I totally agree this is somehow within reach.
After all I realize that I stabilized my code somewhat so it can run as proof of concept and we could start discussing how to actually implement the above visions.

But on the other hand I notice there is not much feedback or resonance about the stuff we achieved so far. So who else would dive in to play together? Who would help create combined missions?

I'm happy to do whatever I can.

[hiran]

I totally agree this is somehow within reach.
After all I realize that I stabilized my code somewhat so it can run as proof of concept and we could start discussing how to actually implement the above visions.

But on the other hand I notice there is not much feedback or resonance about the stuff we achieved so far. So who else would dive in to play together? Who would help create combined missions?

I'm happy to do whatever I can.

Then we probably need to create awareness for all those that seemed interested in the past. Enough they would go and try out a collaborated version of Oolite. And discuss the ideas that were voiced already. But this time it should not remain a vision, we should start thinking in implementation. So it would be a discussion that may start with the vision but should end with a technical concept.

We might also want to discuss performance - but not necessarily the lag on the network but the performance impact of running the debug version of Oolite.

[Cholmondely]

Here's another oldie:

Top 10 OXPs

I came into this thread expecting a lame-yet-slightly-funny David Letterman style Top 10, so disappointed

How's this?

10. Bunny Rabbit OXP: Lets your ship witchjump directly from inside one station to inside another, so you never have to worry about getting your ass shot off. Especially popular among traders.

9. Magic Laser OXP: With the Scanner Targeting Enhancement installed, allows you to instantly destroy any object you have locked your scanner on. For those who find the current game too challenging.

8. Arrrgh My Eyes OXP: Paints all stations neon pink, and decals a flashing photo of a trumble onto all ships. Requires full shaders.

7. CTD OXP: Waits until you've had a particularly successful run, then crashes oolite just as you're docking. Compatible with all releases 1.65 and newer.

6. Random Hits Back OXP: Whenever your ship is hit by a laser or missile, there is a 1 in 3 chance that this OXP will route your system's power supply to your keyboard, mouse, or joystick, delivering a nasty shock. For those who find the current game too enjoyable.

5. Super Duper Cobra OXP: Adds the deadly Cobra Mk. VIII, with 850 TC, speed .999LM, roll 6, pitch 3, 12 energy banks, a recharge rate of 24, 4 plasma cannons mounted for and aft, and 16 missile slots. Comes standard with a Naval Energy Unit and a forward-mounted pulse laser. For those to whom "uber" means nothing.

4. Stalker OXP: Adds a new ship that launches right after you from the station, follows you into witchspace, and makes sure you are always mass-locked. Some say the ship cannot be killed, but the author says they merely haven't tried hard enough.

3. Mission: Impossible OXP: Sends you to the farthest point in the galaxy from where you are, at which point you must fight 12 GalCops flying iron-assed NeoCaduceus interceptors, pick up a special cargo that constantly drains your energy, then jump through every Anarchy system on the map before flying to the previous galaxy and doing it all again. Twice. Deemed "too easy" by some players.

2. Multiplayer OXP: With a properly configured network connection, allows two or more people to play oolite at the same time. Not in the same universe, of course ... what are you, nuts?

1. MNSR OXP: Causes the oolite version to increment to 2.0, and allows the developers to take a year's vacation.

[hiran]

Here's another oldie:

Top 10 OXPs

2. Multiplayer OXP: With a properly configured network connection, allows two or more people to play oolite at the same time. Not in the same universe, of course ... what are you, nuts?

Most of caracal's ideas sound surreal or meant to be a joke. And then the one you colored is closer to the truth than caracal might have considered at that time...

Let's continue the discussion at https://bb.oolite.space/viewtopic.php?f=4&t=21033

[hiran]

I created the Oolite Communicator such that players can see who is online and send messages or goods. And I still call it a proof of concept because not enough people have tried playing.
Now I would like to model something we used to say 'it won't work': Make one player's ship fly around in another player's ooniverse. I will probably have good advice how that could be implemented.

Disclaimer: I do neither believe we can 100% synchonize two Ooniverses over the network. Nor do I believe this would be necessary. Think of the whole system as 'eventually consistent'.

So my idea is that if two players A and B happen to be in the same star system, player's A ship is spawned in player B's Ooniverse at the given position, direction and speed. Both Oolite installations will simulate and render the ship independently and thus fast. In second intervals (or so) updated position, direction and speed will be communicated. And here is where some algorithm is necessary:
There may be a discrepancy between player A's position in B's Ooniverse, as the communcated data and the self calculated data should differ. After all there is no user actually controlling the ship. Let's look at options:

1) if we just set the new coordinates/direction/speed then player A would be perceived as not having a consistent trajectory in B's Ooniverse. That would not look good at all.
2) if we did not synchonize at all the ships may end up at completely different positions
3) if we allow for the values to be corrected within one second, player B's Ooniverse could actually smoothly move towards the consistent state of A, with a time lag but that way minimizing the difference in position. Would player B notice this 'trick' at all? Probably at most when the ships are firing or being fired at. I have no solution for that therefore I will not go there now.

So the questions would be what data to query from Oolite, and once it is transferred to another player's computer how to inject that into Oolite so it gets properly rendered.

[Cholmondely]

Just to say.

I managed to register for an XMPP account with 404.city

[hiran]

Just to say.

I managed to register for an XMPP account with 404.city

Sounds great! With that we are ready for a next test.

[Cholmondely]

Will try it out tonight!

[hiran]

The current version of the OoliteCommunicator allows a new way of cheating. Quite interesting...