Tales from the spacelanes...

General discussion for players of Oolite.

Moderators: another_commander, winston

User avatar
RockDoctor
---- E L I T E ----
---- E L I T E ----
Posts: 570
Joined: Sat May 01, 2010 9:05 pm
Location: Scotland

Re: Tales from the spacelanes...

Post by RockDoctor »

Cholmondely wrote: Fri Oct 15, 2021 11:56 am Something like this?

Image

Reference: Flight Log OXP
That would be the sort of thing, but integrated with "state saved {filename})" information. And ... is that bounty data, or profit-by-trade?

Is there enough data in the system-name (and coordinates, by (1980_source * to make a key comprising previous path and (some data)?

What OZP / MFD/ System_Status) is that from?
--
Shooting aliens for fun and ... well, more fun.
"Speaking as an outsider, what do you think of the human race?"
User avatar
Cholmondely
Wiki Wizard
Wiki Wizard
Posts: 2020
Joined: Tue Jul 07, 2020 11:00 am
Location: The Delightful Domains of Her Most Britannic Majesty (currently plague-ridden)
Contact:

Re: Tales from the spacelanes...

Post by Cholmondely »

RockDoctor wrote: Fri Oct 15, 2021 8:10 pm That would be the sort of thing, but integrated with "state saved {filename})" information. And ... is that bounty data, or profit-by-trade?

Is there enough data in the system-name (and coordinates, by (1980_source * to make a key comprising previous path and (some data)?

What OZP / MFD/ System_Status) is that from?
I presume you've found the answers to your questions by now, but just in case,

Profit by trade I think. And yes, it is created from information which the oxp stores in the save file.

From Flight Log (the page shown is from the F4 page (ship and system interfaces) (see under Logs, if you have Flight Log loaded).

As to this: Is there enough data in the system-name (and coordinates, by (1980_source * to make a key comprising previous path and (some data)?, I don't even understand the question. Putting out 2 utterly simplistic oxp's merely means that I can cut and paste from Norby's work with minimal competence. Not that I understand what I'm doing! Sorry.
Denizen of the Dark and Dismal Deserts of Digebiti.

Milo wrote Dancing the Gavotte
User avatar
RockDoctor
---- E L I T E ----
---- E L I T E ----
Posts: 570
Joined: Sat May 01, 2010 9:05 pm
Location: Scotland

Re: Tales from the spacelanes...

Post by RockDoctor »

Cholmondely wrote: Sat Oct 16, 2021 6:24 pm I don't even understand the question. Putting out 2 utterly simplistic oxp's merely means that I can cut and paste from Norby's work with minimal competence. Not that I understand what I'm doing! Sorry.
"Checksumming (verbification of noun "a checksum") is a trick for validating a block of data, to find errors of entry, or deliberate falsification. I was thinking of something to make it harder for a Jameson to claim "I got a 300-system run with 7002 dead pirates before I had my tea-break. Seem my screenshot! Bow in awe!" But I'll come back to that in a bit.
The classic example of a checksup is in your wallet. The 16-digit number on your bank (or credit) card isn't a random number - it includes (and you can probably work this out from just inspecting your purse contents) information about the bank (or credit agency), your account number, possibly the sequence number of the card, and a check-sum. If I recall correctly, AmEx cards all start with a digit 2, for example (it's a long time since I had to deal with an AmEx card - it might have some other characteristic, but for the moment, let's say that). So, if a website is accepting a credit card number, and the "customer" (well, remote web-browser) claims an AmEx card but enters "3xyz pqrs abcd efgh" for the card number, the website's cord can reject that immediately, because either someone is deliberately lying, or has fat-fingered the wrong number in.
Rejecting such erroneous input at the shop's website reduces both the number of enquiries to the bank (AmEx, whoever) which are doomed to failure. More vaguely, this also reduces the "attack surface" of the payments system - there are fewer types of erroneous data that the site has to check for.
Going from the AmEx specific example to the 16-digit card number in general, all the banks have agreed to follow a common rule that there are 15 digits of data (bank sort code, account number, card number, something else) and one "check-sum" digit which is calculated from the rest to give the overall 16 digit number a particular characteristic, which the involved websites can check without raising a request against the actual payment service. Let's say the characteristic is that (for the number above) the sum 3+ x+ y+ z+ p+ q+ r+ s+ a+ b+ c+ d+ e+ f+ g+ h should produce a multiple of 7. Which ever of the numbers p, q, etc is the check digit can be within the range 0 to 9, and make the 16-digit ensemble fit that characteristic with a very low amount of effort. But if the customer invents a 16-digit number it is unlikely to have that characteristic, and if the customer fat-fingers a wrong number in, again the store's website can detect it and require it to be corrected before forwarding a request to the actual bank's website.
"divisible by 7" isn't the actual test used - I never bothered to memorise that datum. But it's a matter of public record. It's probably on Wikipedia somewhere. A few minute's thought will tell you that the "divisible by 7" characteristic couldn't detect someone typing "...pqsr ..." instead of "...pqrs...", which is a very common class of entry error. Passing that public test doesn't guarantee that the 16 digits received by the store's website is a genuine credit card number, but it does filter out common fat-finger errors, and incompetent attackers.
(I think - I've never felt the need to investigate - that the "security digits" (3 or 4) on the back of bank cards also incorporate further check sums, but that may be different between banks. I'm sure a professional card fraudster would know, but that's not a field I've ever needed. Check-sum technology was part of a Millennium Bug fuck up we had at work, and I spent several years afterwards explaining to customers why we'd suckered them into accepting a "free upgrade" to an absolute Edible Poet of a Windows version of our software. If' they'd kept the old DOS version (and it's "security device") and used it after the Millennium, they'd not have needed to pay another penny in licensing fees to us. Worlds-tiniest-violin.GIF )
Anyway, all of that background aside ...
I had been thinking if there was a way to incorporate some aspects of a series of flights into a hard-to-guess code - such as a checksum - so that a Jameson's claim of performing an extraordinary massacre could be validated. I'm sure there could be such, but since the code for the core game is open source (not so sure if that's always the case for OZPs though?), then any competent cheat would be able to read it, and make their cheat pass the test. So ... meh. It's probably not worth the effort.
Actually, one could possibly get a bit more data to hide in the checksum if you looked at the Oo-StarDate of jumps. Kind of like adding "salt" to your source text before encrypting it. But I doubt it's likely to be worth it. File under "minor issues associated with the multiplayer online version which nobody believes will ever happen" - over in the corner ; circular filing cabinet.
--
Shooting aliens for fun and ... well, more fun.
"Speaking as an outsider, what do you think of the human race?"
Post Reply