SEC file format

[AKAramis]

See, for me, I've given it a lot of thought, as an amateur programmer, for how to implement it. I can't quite get to coding this system (I know that it is codeable, but I'm not the man to do it).

Were I going to impliment, I'd probably use a more detailed location instead of just hex number:
hhhh.s.o.l
hhhh hex
s star (0= hexwide, 1= 1st star, 2=2nd star, etc)
o orbit, about star.
l orbit around body in solar orbit

or xx.yy.zz.s.o.l for 3d.

 

[CaptnBrazil]

See, for me, I've given it a lot of thought, as an amateur programmer, for how to implement it. I can't quite get to coding this system (I know that it is codeable, but I'm not the man to do it).

Were I going to impliment, I'd probably use a more detailed location instead of just hex number:
hhhh.s.o.l
hhhh hex
s star (0= hexwide, 1= 1st star, 2=2nd star, etc)
o orbit, about star.
l orbit around body in solar orbit

or xx.yy.zz.s.o.l for 3d.

I could always add that format to the class. However, currently I am (1) primarily a Windows programmer (although I do Linux & web for work, for personal stuff I run on my computer which is Windows) and (2) I started that project a year ago when I got the BITS 101 Cargoes and decided I really wanted to see about making a cargo manifest with that incomprehensible cargo code (something about Traveller just makes people want to make up & use profile strings ) And that LBB2 cargo program is moving towards T5 cargo (already got the new trade codes in a CSV table and got that part working - see, I DO like CSV as well!) It would just be another section in the class that parses the system files that generates a world object (so I can access things like world.size, world.atmo, stuff like that, making the front end independent on the data formatting).

And if you do get around to coding that, that is part of it (breaking the program into 3 distinct layers - do a search on three tiered programming. A bit more work up-front, but a LOT less work long term). My cargo program is really 2 layers (UI & data access/parsing) but close enough - there is no real business logic involved.

And amateur programmers are often better than so-called professional ones, depending on how they learned.

 

[AKAramis]

And if you do get around to coding that, that is part of it (breaking the program into 3 distinct layers - do a search on three tiered programming. A bit more work up-front, but a LOT less work long term). My cargo program is really 2 layers (UI & data access/parsing) but close enough - there is no real business logic involved.

And amateur programmers are often better than so-called professional ones, depending on how they learned.

I'm an old spaghetti coder... but I've been doing OOP since about 1995.

Keeping the FI/O R/W code in discrete function calls is a good thing.

 

[CaptnBrazil]

I'm an old spaghetti coder... but I've been doing OOP since about 1995.

Keeping the FI/O R/W code in discrete function calls is a good thing.

Spaghetti coder - sounds like the <insert expletives here> asp pages I'm having to convert. Everything is all mixed up: formatting, logic, I/O, VB, javascript. And no formatting so it is really difficult to figure out.

I only started OOP a couple of years ago - the software I generally maintain/write is based on 80's tech. Functions, yes; OOP, no. But when I had to write a new inventory system I decided that was the time to start figuring that out.

Functions are just the 1st part. OOP actually breaks all object handling into the object, not really part of the program directly. So, in my case, for instance, I do something like:

WorldSystem myworld = new WorldSystem(system name, file that contains that system)

The WorldSystem class figures out the file format from the file extension, finds the world details in the file according to the format, and calculates a few things (such as trade codes - for human readability I can see having trade codes in there, but from a data perspective, since you can derive the codes from the data it seems silly, which is why my odd XML format does not contain that data) and then you have access to things like:

myWorld.WTN = the Gurps world trade number
myWorld.size = size
myWorld.T5Codes = an array list of T5 trade codes (based off that CSV table, so it is user-modifiable & not hard-coded into the software; in fact, almost all of the pgm uses external text tables)
myWorld.agri = a boolean (on/off) for LBB2 trade code agricultural status

and yes - the program does span a few versions....I do have the Mongoose Marches book, and I'm this close to getting the Mongoose core book (holds fingers really close together) so it may eventually have Mongoose stuff in as well!

The functions are part of the class. In theory I can take that class, which is a self-contained file, and use it in another project, such as one for my phone (which also runs .Net). Heck - I could even make a DLL for it and people could use in in VB or other COM-compliant programs. But that is unlikely because the people who want programs usually end up writing them themselves.

sorry for the length of this post - I get excited when other people program interesting things and come up with neat ideas (and I do really like your expanded system records).

 

[AKAramis]

I'm an old spaghetti coder... but I've been doing OOP since about 1995.

Spaghetti coder - sounds like the <insert expletives here> asp pages I'm having to convert. Everything is all mixed up: formatting, logic, I/O, VB, javascript. And no formatting so it is really difficult to figure out.

I only started OOP a couple of years ago - the software I generally maintain/write is based on 80's tech. Functions, yes; OOP, no. But when I had to write a new inventory system I decided that was the time to start figuring that out.

Functions are just the 1st part. OOP actually breaks all object handling into the object, not really part of the program directly. So, in my case, for instance, I do something like:

Not all OOP does; I've texts on OOP from the 1990's that don't show such concepts at all...

But the moving of code off the main event loop to "object handlers" is the key concept, and that's morphed to the style of OOP you're using (and that's key in Java, JS, and ObjC...).

HUman readability of flatfiles is the best reason for use of them as an input/output method; they are not terribly good for work-files.

 

[simonh]

HUman readability of flatfiles is the best reason for use of them as an input/output method; they are not terribly good for work-files.

True, for any given application you're probably better off with something like SQLite for native data storage but it's useful to have an easily readable data interchange format.

Simon Hibbs

 

[GypsyComet]

Not all OOP does; I've texts on OOP from the 1990's that don't show such concepts at all...

But the moving of code off the main event loop to "object handlers" is the key concept, and that's morphed to the style of OOP you're using (and that's key in Java, JS, and ObjC...).

Yeah, my Pascal and C instructors in the early 90's went to some pains to make it clear that the phrase "Object-Oriented Programming" had several meanings, and that the one they were going to teach was the general philosophy, not the company-specific buzzword.

Even back in my 80's Basic and Fortran classes, though, the concept that "GOTO was evil" was already taking hold amongst the instructors, even though everything else they were teaching was spaghetti coding.

Then I got to Assembly, and GOTO ("jump") was all you got.

 

[AndrewW]

Then I got to Assembly, and GOTO ("jump") was all you got.

Well, 6502 assembly has JMP (jump, goto) and JSR (jump saving return address, gosub).

 

[CaptnBrazil]

Then I got to Assembly, and GOTO ("jump") was all you got.

Well, 6502 assembly has JMP (jump, goto) and JSR (jump saving return address, gosub).

and actually, at the machine level, OOP is all JMP or GOTO as well (pretty much everything compiles down to that). OOP, however it is currently defined (and it does change according to the vendor!) is essentially just an attempt to abstract layers to make life easier. And it is not always a useful idea - just like Agile programming or other programming theories of the day, it has its uses and abuses. For some applications, it makes no sense - the overhead is higher than the gained benefits.

But back to the SEC file question: it could be expanded in numerous ways; the AKAAramis extension (if I used that I'd make the extension .AKA!) gives room for all sorts of chrome - just have to teach your SEC parser to only read the standard SEC formatted lines, dropping the 1st character. Would be a simple update. Changing column width (i.e., for additional bases or codes) would be problematic in that existing software would not work, depending on how it was actually parsing the data.

But getting most of the 90's software to get updated for a new format: not likely. And with the ease of most programming environments now, it is not particularly difficult to write your own, given time, inclination and understanding of what you are doing (says the guy who has half a dozen unfinished Traveller programs he's been working on off & on for, say, a couple of decades with a few really long hiatuses! From Commodore 64 to XP)

 

[AndrewW]

But getting most of the 90's software to get updated for a new format: not likely. And with the ease of most programming environments now, it is not particularly difficult to write your own, given time, inclination and understanding of what you are doing (says the guy who has half a dozen unfinished Traveller programs he's been working on off & on for, say, a couple of decades with a few really long hiatuses! From Commodore 64 to XP)

That's ok, I never finished my Applesoft BASIC one either...

 

[GypsyComet]

But getting most of the 90's software to get updated for a new format: not likely.

The subsector map maker that DGP had done for the Mac back in the late 80's was still working up to the changeover to OS X, and may still work in Classic mode under 10.4 and earlier (10.5 no longer includes Classic mode). Simple it may be, but that's a heck of a run for one piece of software. Graphics output has never been my strong point or I'd update it myself...

 

[CaptnBrazil]

But getting most of the 90's software to get updated for a new format: not likely.

The subsector map maker that DGP had done for the Mac back in the late 80's was still working up to the changeover to OS X, and may still work in Classic mode under 10.4 and earlier (10.5 no longer includes Classic mode). Simple it may be, but that's a heck of a run for one piece of software. Graphics output has never been my strong point or I'd update it myself...

you would only have to update the part that parses the input file. and that would assume you have access to the source code, in whatever language it was. Early Apple had their own version of basic if I recall (I wrote some 3D vector space game on an Apple ][ and I'm pretty sure it was a basic variant)

And I'm still maintaining code I wrote in 1986 - it has been across a few hardware platforms, but oddly the same language (except that I had to convert the COBOL from the original system to the same language when when went from the Datapoint OS to a Unix server: in the original OS, their version of COBOL used the same indexed files as Databus [now PL/B] and that was not the case on non-Datapoint OS). 22+ years of maintaining the same software is a pretty good run too - and big chunks of that were written a few years before that even. The oldest comment being 1982. This is, of course, enterprise level software, and has been through a lot of changes, but the original authors would recognize 90% of it at least still.

 

[AKAramis]

you would only have to update the part that parses the input file. and that would assume you have access to the source code, in whatever language it was. Early Apple had their own version of basic if I recall (I wrote some 3D vector space game on an Apple ][ and I'm pretty sure it was a basic variant)

And I'm still maintaining code I wrote in 1986 - it has been across a few hardware platforms, but oddly the same language (except that I had to convert the COBOL from the original system to the same language when when went from the Datapoint OS to a Unix server: in the original OS, their version of COBOL used the same indexed files as Databus [now PL/B] and that was not the case on non-Datapoint OS). 22+ years of maintaining the same software is a pretty good run too - and big chunks of that were written a few years before that even. The oldest comment being 1982. This is, of course, enterprise level software, and has been through a lot of changes, but the original authors would recognize 90% of it at least still.

Chipmunk Basic will run the vast majority of Applesoft programs unmodified.

 

[AndrewW]

you would only have to update the part that parses the input file. and that would assume you have access to the source code, in whatever language it was. Early Apple had their own version of basic if I recall (I wrote some 3D vector space game on an Apple ][ and I'm pretty sure it was a basic variant)

Earlier Apple II's had Integer BASIC this was replaced with Applesoft BASIC built into the ROM later but still available for use.