Slopey
Volunteer Moderator
2.2's Instant Ship and Module Transport - Yay or Nay?
- Thread starter Kintch
- Start date
- Status
I bet that between 6 months to a year we will have jump gates.
Be as well, save any faffin around magically calling your ships as it will take a few mins to transfer to your other ship, just do away with the few min time sink and add jump gates.
Mick.
And I would be OK with that , as long as its done right.
Ignorance must be bliss. Mission timers are simply date() calls from your computer to the server and a comparison to the timestamp for mission expiry server side. The ship location is held temporally on your save, along with your credit balance, and both of those are appended to your pilot entry which happens to be arbitraged by the Transaction server - in short, not exploitable, because THOSE things are server hosted. What they're doing here is simply a very clever dodge by grafting more functionality onto the game by using the Pilot location as a makeshift beacon to move the ships FROM one location to another.
Oh no you got me! How on earth will Frontier do math? How could they possibly look at the missions from distance systems like Sothis and run through some scenarios with ship builds to see how things work out? How will they ever adjust the payment of missions in those systems? This surely is an impossible task!
Last edited:
Question: Missions have a timer. That timer is server side (in your save game I assume). When missions expire they can no longer be fulfilled. So something is tracking that timer even if the mission is stateless.
Would it not be possible to treat transfer like a "mission" and use the same timing mechanic for Ship transfer. Having the transfer displayed in your transaction tab would be a bonus. I'm not assuming this is easy and mixing functionality like this would open up another Pandora's box of bugs and what have you. But possible?
![[VR] Mad Mike](https://forums-cdn.zaonce.net/data/avatars/m/27/27910.jpg?1553527108){kind=avatar}
it was on day4 (i think - possibly day 3), it was not aimed at this thread, but they were laughing about "magics" and what not..... i found it quite depressing tbh that they do not see it as a serious issue.
Well.. that is what you get for offering to implement magical teleportation to a game which is supposed to be based on reality and real science.
Forgive my ignorance. I'm not a game developer. Well, not a professional game developer anyway. I'm an enterprise developer.
I really can't see the complexity in this. All players have owned ships and relevant information (modules, etc) stored server-side. When querying for data for the shipyard screen, we're already passing ship information back to the client. Add to that information: destination station id and arrival time. Hey presto! The client can now see that it has ship X on the way to this particular station and that it has either arrived or not. It can then present such information along with everything else.
If you want in-game announcements for ship arrival, that does add a bit of complexity and overhead. But not a lot.
I'm feeling like this myself. IT's certainly NOT trivial to add timers to ship transfers (even though I also hope FD will).
As for Sandro on the livestream, they do say laughter is instinctively a 'fear' response and I tend to think FD knows, as anyone who really thinks about it will, that ship transfers could get REALLY complicated in code. I'm glad they're starting down the trail though, so I certainly wouldn't berate FD for even instant transfers .. because it does start to solve a problem that the VAST majority (1058 to 27 in this poll) want solved, in some form. FD deserves a ceegar for taking this on imo.
Sure. Fair enough. But is the reason we get this because they can't do it any other way, or because it just seemed the easiest way?
If ships are being delivered instantly, then how does the station know? Where is that state change kept? I'm all for simple mechanics and QOL improvements, but of all the ways this could be done, it's litterally click a button, state for stored ships updates and then when we swap ships the assets are loaded.
Nothing is "moved". It's just state changes. I know the universe servers have to do a lot and they have limits, but I don't think we can really look at "1 button uplift" as the only outcome because it's simplistic to enact. Arguably engineers with the layers of RNG can't have been the most optimal choice for either client or server load?
It was done that way because the developer decided to have muiple laters of RNG. How could that possibly be less computational effort than static tables in either client, server, or both? All that extra code to do magic spins. It's like they did it on purpose or something?
So they can build quite a complex model to generate random attributes, but the server somehow manages with any and all state changes this might add?
Sometimes the developer will make choices that has nothing to do with optimal server performance. That cat is well and truly out of the bag, we don't really get to use it to explain why some bizzare mechanics are fine despite having all sorts of crazy code supporting it, and others not because imagine the spaghetti code.
Frontier are doing it this way because it's instant and is what they want. Not necessarily because it's just efficient.
Last edited:
Now try being a somewhat retired (though I do still consult for old colleagues) Tier 3 Network Analyst and Security Expert. Trying to explain in simple terms things like how database and CPU overhead matters and why Frontier are trying not to turn instawarp into a massive CPU blattering (and consequently AWS shredding) problem is just a recipe for a migraine ><
I didn't see an implicit "new character being created" in the post I quoted, nor in my response.
My response was on a similar basis as to relogging your raid-ready (or at least somewhat raid-ready) alt and having it summoned to the raid. The capability (equipment etc etc) of the "character" wasn't relevant to the point I was making.
Yes. Not mid fight of course but someone popping outside of the instance, logging their alt character and being summoned was a very common occurance. That was only a small part of the context though as the ability to change characters so readily allowed alot of varied play, which I'm quite sure enhanced the games longevity and ability to entertain.
This post explains clearly some of the foreseeable cosequences of the abhorrent new mechanic. Surely many others remain unseen yet. Game breaking, no less
I think you need to add the transfer to (something like) the mission timers. Either that or you need as many mission timers as ships being transferred, applied into the shipyard. First and foremost though, yes, you're right .. you need to call the ship's ID and loadout from the server .. and that's basically what we have in 2.2.
I'm not quite sure why you're so hung up on not using the Transaction Server. No ignorance here, just an all too familiar eye-roll when developers claim that something is 'hard'.
Yep, I agree with this!
As other people are saying, presenting the info is the easy bit, it's the "Writing the scheduler" and "Ensuring that everything works ON TIME" that's the really horrible bit. Especially when you're talking about say, 300,000 non-concurrent users with possibly an average of 3-4 ships and let's say they want to warp 1 or 2 of those a week. That's the kind of CPU butchering nightmare that nobody wants to walk into. Realtime management and scheduling of an ongoing queue of approx 50,000 database queries constantly shifting around and being bounced and forth to the transaction database AND player saves? THAT SOUNDS LIKE FUN TO ME!
Good question. I'll give you what I think is happening. So, client side - Client performs a pretty simple script which is essentially date(), it's pulling down the timestamp of the mission which says when the mission is due to expire, it compares the two and that tells it how long it has remaining (simple subtraction gets you a difference between the two).
When you take a mission from a board in the station, all that's happening is that the mission is being appended to the pilot, effectively it's being split from the station lookup and added to the pilot lookup, couple of SQL scripts needed for this, nothing backbreaking either (but doing this for hundreds of thousands of missions a day? That's going to be brutal, and hence why all of these operations need to be simple, and bulletproof).
If the script comes back with a value of less than zero, client side it'll say that the missions dead, it'll send back a message to the server that the pilot failed, that'll tell the server to wipe that mission from the pilot's record. None of this, by the way requires you to touch the transaction server, this is all just a matter of manipulating joins and possibly deleting a lookup that got created for the station mission board.
The only time things really whir into life is when the mission is submitted for completion, because that's the point you're saying "I've done the mission, I want my money", at this point the server will check that you've done what you've said you were supposed to do, it'll check the objectives, confirm that you, the player did what you were supposed to do, and if it's satisfied you've done it, it will award you the credits, record the change of CR on the Transaction server as a mission reward, and then remove the lookup for the mission.
Now, the only point where things got really involved from a server point of view is when the player *hands in* their mission, anything before that, including chains, branches and what not, that's all "IF > THEN" stuff, you can program triggers that can be loaded in client side and look pretty convincing to the player, it's all great fun too. But what matters is that until money gets involved, it's not like the server HAS to do much aside from increment mission counters on the pilot record.
Now, when it comes to ship transfers, the reverse problem applies, you've "paid" for the service up front, so the Transaction server is involved at step one. That means that you've got a monetary deduction in your log for <WarpTheShipOuttaHere>, and at this point, you're also dealing with player assets that also have Cr Worth. Since all of this deals with money, you need to ensure that there's no way to fiddle the books, so all of this has to stay server side.
If you went with timestamps, you'd need a way to reference them, since missions only do this when they -need- to (and can do so with a date() function client side) that's all well and good, but with ship transfer, you'd have to schedule it server side, because you can't afford to have that information at risk of manipulation, so that means a scheduler to ensure that the server KNOWS when to release the assets, it can't trust that the client will come back with the right time or a true return from date() (my guess is when a mission is handed in it checks date() against it's own as a check to prevent any fiddling against time failures), and that's where things get... gloopy.
Last edited:
Actually, I do too... then again, I also advocated for perma-death when you forget to mount an escape pod way back when, so.
- Status