+.ED is the 1.2 version #30
Comments
|
+.UU is the replacement for +.ED and yes, it needs to be fixed. |
|
(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. |
|
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. |
|
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 |
|
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. |
|
I made a proposed change to your e_data-format file in my fork of the file and submitted it. |
|
I completely forgot to import your |
|
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? |
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. |
|
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? |
|
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: Is anyone familiar with 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. |
|
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 ***@***.***> 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
<#30 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Ao7ISxA_OMQoXwwvAmIEmbhJ_CDj-3FQks5uefMIgaJpZM4WgRyK>
.
|
|
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. |
|
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. |
|
Actually there is some new stuff in 1.3's
Per-user access flags (
Miscellaneous:
User flags (
Anything you guys know about that I'm missing? |
|
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 ***@***.***> 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
<#30?email_source=notifications&email_token=AKHMQSYSORBDQGXIPSLLIITPV5OO5A5CNFSM4FUBDSFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWFPNQ#issuecomment-493639606>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKHMQS3336U2MVJZGMPX2H3PV5OO5ANCNFSM4FUBDSFA>
.
|
|
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
|
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.
The text was updated successfully, but these errors were encountered: