+.ED is the 1.2 version

[ThaDoctor72]

Need an updated user editor that can access the new flags and stats portions of the 2.0 user files. We don't have access to change the user's terminal parameters, or maintenance flags. Another issue with this version is single digit entry for "Downloads per day" field.

If UU is the suggested editor, it's broken. See #29.

[x-tec2017]

+.UU is the replacement for +.ED and yes, it needs to be fixed. Want to work on that? Meantime, all we have for editing user files is +.ED page 1 and 2 and the flags. As for Downloads per day, see my suggested times 10 fix in the prior issue discussing downloads per day.

[Pinacolada64]

(As you've probably seen, you can [inadvertently, in some cases] reference issues by prefacing them with a # symbol. If you're on the GitHub issue page, it'll even pop up the title of the issue.) So we can reference #29 in our messages, for example. Just a FYI.

[ThaDoctor72]

I could work on that, but I would be re-inventing the wheel unless someone has some accurate notes on which lines/entries of u.config certain things are stored on.

[Pinacolada64]

I just uploaded some info: https://github.com/Pinacolada64/ImageBBS/blob/master/v2/docs/e_data-format

It's incomplete, if @x-tec2017 wants to add/correct any info, feel free. I'm working on rewriting +/lo.misc (better manual clock set routines, fixing Reservation PassWord routine and display in screen mask). That's when I discovered record 37, which used to be the RPW info, has been changed to the clock set device type. I was getting a ?file data error on boot because of that.. No big deal, just pick another free record. Question is, which one?

[x-tec2017]

Ryan, if the program you're using has the clock set type as record 37 in e.data then you might be using the wrong files. That was changed in revision 2. The clock set type is record 33, the remote cmd device for clock set is record 34 and the RPW record is 37 as it is supposed to be. Rev 2 moved the set clock type from 37 to 33 in order to overcome the conflict of record 37 being used by two different functions.

However, if what you did was replace your existing files with the ones from release 2 without doing an install, then you will need to use +.reader to edit e.data record 33 for the value of the set clock type or as you said, create a better +/IM module to be able to change the clock set type from within the configuration editor. I was planning to do that anyway but since you're working on it, I'll wait to see what you come up with.

[x-tec2017]

I made a proposed change to your e_data-format file in my fork of the file and submitted it.

[Pinacolada64]

I completely forgot to import your im r2. I'm working on merging your changes and mine. I'll take a look at the change. I updated e_data-format also.

[x-tec2017]

Yeah, it kind of appeared that you had not yet started working with the R2 files. One of the main reasons for creating the R2 files was to get everyone working on this on the same page and caught up with all the changes that have been made since you uploaded the first version of Image 2.0 to Facebook last November. I don't know exactly how many program files had changes in them in the R2 version, but it's a lot, maybe as many as 30 or more. In order for you to be in sync with what we're working with right now, I would suggest that you back up anything you've been working on and start off with a clean installation of the R2 files. Also, I had emailed you a .d64 file a couple weeks ago containing changes since R2 was published. Did you get that? Don't forget to merge those files into the R2 version as well.

As for what you're working on, they all sound like great ideas but unless they are incorporated into the same version of Image 2.0 that Mark, Jay, Al and I are working with, they might be very difficult to merge into our systems.

That brings up another question. When somebody comes up with files to merge into the working version, how do we get those files distributed to all the members of this group? I tried uploading a .d64 file here but github wouldn't allow it so I had to send the file to you all via email or messenger attachments. If that system works, fine, but we need an agreed on system of some type for distributing proposed changes and additions. If you know of a better way, please let me know. Since I am the one who published the R2 version, I have been very careful about adding any changes after R2 to a disk of revised files that I keep. Maybe the best way of distributing changes is for them to be sent to me to be added to the revisions disk and then whenever there are updates, I can send the .d64 version of that disk out to everyone. Comments?

[ThaDoctor72]

That brings up another question. When somebody comes up with files to merge into the working version, how do we get those files distributed to all the members of this group? I tried uploading a .d64 file here but github wouldn't allow it so I had to send the file to you all via email or messenger attachments. If that system works, fine, but we need an agreed on system of some type for distributing proposed changes and additions. If you know of a better way, please let me know. Since I am the one who published the R2 version, I have been very careful about adding any changes after R2 to a disk of revised files that I keep. Maybe the best way of distributing changes is for them to be sent to me to be added to the revisions disk and then whenever there are updates, I can send the .d64 version of that disk out to everyone. Comments?

I was wondering about this myself. I have yet to do anything with (imagebbs.net) because I'm neither a visionary or a web dev. I can install stuff all day long, but I don't have a very gifted eye for design. That said, most emails will kick back a file it doesn't recognize, D64 being one of them. I usually have to zip it before I send it. Even an FTP site would be a neat idea. I could certainly set that up on that domain at least just for now so we have an easy way to quickly get stuff put together and distributed amongst ourselves. After going public, hopefully the website will have at least sprouted into wiki/forum/repository, or something along those lines.

[x-tec2017]

An FTP site works for me. I imagine you could set it up with different folders or directories to keep completed work separate from proposed changes or work in progress. Something like that?

[Pinacolada64]

Guys, the whole point of using Git/GitHub is so that everyone has access to change stuff, can pull the latest versions of files, push their proposed changes, as well as tracking who does what. Now, I know I'm not the greatest at explaining how this all will work, but I've mentioned TortioseGit a few times before. It's a nice front end to the GitHub web site. Check it out.

Most of you guys are on Windows, and I've got some batch files which convert C64List files into .prg files (and vice versa), then build .d64 or .d81 disks out of those files. I guess they're really in my Totally Awesome Dungeon Adventure scripts repo, though. They can be brought up to date with C64List 3.5 (which includes d64 reading and writing, sadly not d81s, maybe that could be added!).

I always thought the BBS network could push out file updates. But if that update breaks/changes the same line the sysop has customized locally, that's kinda bad news. Hmm.

Have you guys read any GitHub help? I'm still getting into jams and learning myself, I don't mean to say I know all about GitHub. But so far it's been pretty dang useful. I know that @x-tec2017 was having trouble understanding repositories (we're in the Image BBS repository right now, think of it as where the code is kept) and branches and there is some help here: https://help.github.com/articles/git-and-github-learning-resources/

Branches are Git's version of different folders in the FTP site for proposed changes. Here is a "Hello World" example that demonstrates use of branches: https://guides.github.com/activities/hello-world/

There is a new version of C64List which improves string readability: print "Hi there!" instead of print "{$c8}i there!" It's going to take some time to take the R2 files, convert them to C64List with proper line numbers (initially the line numbers are labels like {:3000}, but those can be changed to something more descriptive later) and add the "fixes after r2" merges.

Is anyone familiar with c1541? It comes with VICE, and can be scripted to do all sorts of cIool stuff with disk images.

Yeah, this is a lot of stuff to digest. I know I need to document my processes better, but in the long run it will save a bunch of hassle. I promise (said the politician). It feels like people are confused and frustrated and I haven't explained enough or don't know where to begin explaining (or I'm explaining too little... assumptions) to make the frustration go away. Please, ask questions if you don't understand something. I'm learning too. We can start a wiki page on learning/using GitHub and the tools we use and why we like them (or don't), if anyone is interested.

[ThaDoctor72]

It's so easy to become scatter-brained. I fall victim to it constantly. That plus my "Oooh shiny!" ADHD doesn't help. Part of my frustration during my full time job is that we are forced to document every thought that leads to every change, so I spent 60% of my career documenting risk methodology of my proposed changes, and only 20% actually committing the change. (The other 20% is answering dumb questions from the "regular" users)

Don't feel bad about your mess. Some studies have shown that's a sign of greater intelligence. But what do I know, I'm not a people person.

On Tue, Sep 25, 2018 at 5:10 AM Ryan Sherwood notifications@github.com wrote:

Guys, the whole point of using Git/GitHub is so that everyone has access to change stuff, can pull the latest versions of files, push their proposed changes, as well as tracking who does what. Now, I know I'm not the greatest at explaining how this all will work, but I've mentioned TortioseGit https://tortoisegit.org/ a few times before. It's a nice front end to the GitHub web site. Check it out.

Most of you guys are on Windows, and I've got some batch files which convert C64List files into .prg files (and vice versa), then build .d64 or .d81 disks out of those files. I guess they're really in my Totally Awesome Dungeon Adventure scripts https://github.com/Pinacolada64/TADA-old/blob/master/scripts repo, though. They can be brought up to date with C64List 3.5 (which includes d64 reading and writing, sadly not d81s, maybe that could be added!).

I always thought the BBS network could push out file updates. But if that update breaks/changes the same line the sysop has customized locally, that's kinda bad news. Hmm.

Have you guys read any GitHub help? I'm still getting into jams and learning myself, I don't mean to say I know all about GitHub. But so far it's been pretty dang useful. I know that @x-tec2017 https://github.com/x-tec2017 was having trouble understanding repositories (we're in the Image BBS repository right now, think of it as where the code is kept) and branches and there is some help here: https://help.github.com/articles/git-and-github-learning-resources/

Branches are Git's version of different folders in the FTP site for proposed changes. Here is a "Hello World" example that demonstrates use of branches: https://guides.github.com/activities/hello-world/

There is a new version of C64List which improves string readability: print "Hi there!" instead of print "{$c8}i there!" It's going to take some time to take the R2 files, convert them to C64List with proper line numbers (initially the line numbers are labels like {:3000}, but those can be changed to something more descriptive later) and add the "fixes after r2" merges.

Is anyone familiar with c1541? It comes with VICE, and can be scripted to do all sorts of cIool stuff with disk images.

Yeah, this is a lot of stuff to digest. I know I need to document my processes better, but in the long run it will save a bunch of hassle. I promise (said the politician). It feels like people are confused and frustrated and I haven't explained enough or don't know where to begin explaining (or I'm explaining too little... assumptions) to make the frustration go away. Please, ask questions if you don't understand something. I'm learning too. We can start a wiki page on learning/using GitHub and the tools we use and why we like them (or don't), if anyone is interested.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Pinacolada64/ImageBBS/issues/30#issuecomment-424265116, or mute the thread https://github.com/notifications/unsubscribe-auth/Ao7ISxA_OMQoXwwvAmIEmbhJ_CDj-3FQks5uefMIgaJpZM4WgRyK .

[x-tec2017]

Although the +.ED program is a conversion of the 1.2 version, it does allow you to edit any and all the data in records of the u.config file. I think this issue should be closed because there is nothing to change in the +.ED file. We already have an issue about +.UU being unfinished, but from what I can tell, +.UU is just a graphics driven program intended to emulate all the functions of +.ED. It's not required but might be a nice addition sometime in the future.

[ThaDoctor72]

I understand. I also agree that it would be decidedly quicker to roll out a modified +.ED (2.0) that incorporates the changes to records 11 and 13 for parameters & time zone than to fill in the missing LMP pieces in +.UU, since it appears to making calls to ++ read for whatever reason.
It's at least an immediate band-aid for the issue of not being able to change a user's params on the fly without using +.reader or a generic rel editor. Either way, I'd be happy to take on this project. (ED v2)

[Pinacolada64]

Actually there is some new stuff in 1.3's u.config file if you look. I've started working on an editor to address some of it, using my enhanced 1.2 ED editor as a basis.

• [ ] Carrier drop before logoff (saved as char 12 of last call date)

Per-user access flags (fl$):

• [ ] Max idle time
• [ ] Calls per day
• [ ] Time per call (two bytes)
• [ ] Downloads per call (I remember you guys making a mod to this)

Miscellaneous:

• [ ] Screen width and height being combined into one value (why?! sigh)
• [ ] More prompt modes
• [ ] Logon time and last date being stored separately

User flags (uf$)

• [ ] Linefeeds in a different set of flags
• [ ] Graphic Menu mode 4-5 are undefined
• [ ] Time zone, hour, minute offsets

Anything you guys know about that I'm missing?

[ThaDoctor72]

The 1.3 tail code I had was writing 6 digit date of birth into record 25 after the join flags. YYMMDD but i noticed in the 2.0 release it was gone. The string that was dim'd was db$. No idea why it wasnt an integer, i guess since it is similar to d1$.

On Fri, May 17, 2019, 9:52 PM Ryan Sherwood notifications@github.com wrote:

Actually there is some new stuff in 1.3's u.config file if you look. I've started working on an editor to address some of it, using my enhanced 1.2 ED editor.

• Carrier drop before logoff (saved as char 12 of last call date)

Per-user access flags (fl$):

• Max idle time
• Calls per day
• Time per call (two bytes)
• Downloads per call (I remember you guys making a mod to this)

Miscellaneous:

• Screen width and height being combined into one value (why?! sigh)
• More prompt modes
• Logon time and last date being stored separately

User flags (uf$)

• Linefeeds in a different set of flags
• Graphic Menu mode 4-5 are undefined
• Time zone, hour, minute offsets

Anything you guys know about that I'm missing?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Pinacolada64/ImageBBS/issues/30?email_source=notifications&email_token=AKHMQSYSORBDQGXIPSLLIITPV5OO5A5CNFSM4FUBDSFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWFPNQ#issuecomment-493639606, or mute the thread https://github.com/notifications/unsubscribe-auth/AKHMQS3336U2MVJZGMPX2H3PV5OO5ANCNFSM4FUBDSFA .

[Pinacolada64]

I've made a note of that in +.ED, but I haven't seen that code yet, somehow. I'm going to upload a very, very alpha (as in, doesn't even edit everything, and has bugs, so use at your own risk) version to TST.

Comparisons can be done on strings pretty easily: PETSCII values of each character are compared, and -1 is assigned if the comparison is true, 0 if false. Quicker in some ways than doing val(a$)...

print "1991">"1992" -1

print "1991"<"1992" 0