It would, I think, be relatively easy to have each world gradually replenish its export goods and have the level drop semi randomly when a ship launches, perhaps even assigning the npc the cargo it just bought.
Maybe even tie this in with shuttles bringing the goods up from the surface.
I dont see how this relates to multi player though.
Thanks to Phkb's suggested tweaks to that oxp, Phasted's Real Life Economics finally kicked in while I was trying out his Ship Configuration.oxp. RLE seems to do all of that. I arrived at Isinor - vast quantities of food and furs, with prices continually changing (food bounced around between 0.1 - 0.8₢/TC over a five minute period as I was buying and then had to sell some back as I forgot to buy fuel).
That should be the first thing you do after docking. You never know when you might get blasted back out into space!
Fuel is cheap or free - but out there in the Big Black, it's priceless!
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
That should be the first thing you do after docking. You never know when you might get blasted back out into space!
Fuel is cheap or free - but out there in the Big Black, it's priceless!
Habit. I rely on the AutoRefuel OXP by BryonArn. New ship, no money - so no automatic refuel as no dosh to stump up for it. So I sold back some of the food - and noticed that all of a sudden I was making a loss! Not used to this OXP yet but it seems worth while... what a nice surprise - one tends to take so much for granted...
It would, I think, be relatively easy to have each world gradually replenish its export goods and have the level drop semi randomly when a ship launches, perhaps even assigning the npc the cargo it just bought.
Maybe even tie this in with shuttles bringing the goods up from the surface.
I dont see how this relates to multi player though.
Thanks to Phkb's suggested tweaks to that oxp, Phasted's Real Life Economics finally kicked in while I was trying out his Ship Configuration.oxp. RLE seems to do all of that. I arrived at Isinor - vast quantities of food and furs, with prices continually changing (food bounced around between 0.1 - 0.8₢/TC over a five minute period as I was buying and then had to sell some back as I forgot to buy fuel).
I do not mind making the economy more dynamic - in a global way.
Now that there is a way to send events into the various Ooniverses, we can introduce message types that do not have to be understood by Oolite Communicator - rather it should directly forward such messages into the Ooniverse it is connected to. This way we can achieve to have OXPs reacting to such events and a central component deciding when to send which event. The central component can this way bias ooniverses to a certain degree and/or trigger missions that actually are implemented inside normal OXPs. we'd have a great amount of flexibility here.
The only question would be how it could be possible to send events to OXPs via the debug console.
The only question would be how it could be possible to send events to OXPs via the debug console.
Create a base OXP that each player needs to have installed, which for the sake of example we'll call "CrossPlay". Inside this, you can set up a variety of variables and functions to perform all your cross-system gameplay. Then, if player A triggers something (an event that would initiate a multi-player mission, lets say), that would be triggered in their local "CrossPlay" OXP and settings would then be changed. Then, your multiplayer secondary app would poll the settings of the CrossPlay OXP and find a changed setting, which would then be sent to all other connected players. Now, everyone would have the mission/setting/etc.
That's how I imagine it would work in broad terms. As always, the devil's in the detail. For a test run on some sort of community/multi-player mission, I'd probably try for a "Collect 1000t of Computers and deliver them to X", where each player's contribution to the goal can be tracked.
Create a base OXP that each player needs to have installed, which for the sake of example we'll call "CrossPlay". Inside this, you can set up a variety of variables and functions to perform all your cross-system gameplay. Then, if player A triggers something (an event that would initiate a multi-player mission, lets say), that would be triggered in their local "CrossPlay" OXP and settings would then be changed. Then, your multiplayer secondary app would poll the settings of the CrossPlay OXP and find a changed setting, which would then be sent to all other connected players. Now, everyone would have the mission/setting/etc.
That's how I imagine it would work in broad terms. As always, the devil's in the detail. For a test run on some sort of community/multi-player mission, I'd probably try for a "Collect 1000t of Computers and deliver them to X", where each player's contribution to the goal can be tracked.
Just for curiosity I checked whether/how some other implementation is handling multiplayer.
And as it seems some earlier version actually was able to run LAN games where pilots could deathmatch each other. https://wiki.vega-strike.org/Development:Network
The latest version however does not come with multiplayer - it seems there were still many issues. https://www.vega-strike.org/blog/2021/0 ... 0-release/ We have also disabled the networking code for the time being while we focus on the core engine.
If we were to implement a complete multiplayer solution (just hypothetically), in the beginning of the thread there are voices warning about network lag and bandwidth problems.
I'd like to point out that BZFlag, a multiplayer game playable over TCP/IP since - ever? - can handle this reasonable well. And I found some description what they are perceiving and doing: https://wiki.bzflag.org/Network It does not resolve the problems, but it handles them with an acceptable realism. Something that could have been created for Oolite as well. Just hypothetically.