Solunars by Aldebaran Sidereal Academy

At the moment, I have Eureka curve selected and the box checked not to show background. In the main table this is all correct. My chart:
Background is discernible by the low Ang value. For example, notice that Pluto and Venus are 1% and 0% respectively.

However, in the Cosmic State report, these background planets appear as foreground (as do the foreground planets)!
This persists with any of the three angularity curves and independent of whether the "Don't Mark" box is checked.

Ah, I bet I know why this is. This is something I fixed in the rewrite of this logic but not in the original. I’ll take a look when I next get some time and put out a patch for this.

I finally got the chance to fix this. Super simple fix. You can find 0.5.6 here.

https://mega.nz/file/1TF0SKZI#T2gLqoi2n ... DlXO419ydU

Fix confirmed. Thanks!

What's wrong with my copy?

Each time I try to open anything, I get this error.

Here's what I think is causing that. (Mike can perhaps confirm from the diagnostic.)

On recent versions, if you try to open a chart calculated on a PRIOR VERSION, you get an error. The solution is to hit Calculate to recalculate the chart. (This updates it.)

This is a known behavior. Future versions will catch this "old chart problem" and recalculate it immediately to avoid the error.

If this is what's going on, the problem will go away if you click Calculate.

Now I'm getting unable to pen "default_natal.opt".

We may have to wait for Mike to decode the error message; but since it works on two of my computers, it's not likely a problem with the program itself. I'm about ready to suggest you reinstall. Maybe start with downloading the installer again and installing atop your current version.

I can read the error and visualize what it's trying to execute, but I don't know where it's doing that, or why, in your case. I second Jim's recommendation to install it fresh, it should copy over needed files (like option files) and will leave your charts intact.

Regarding "NotImplementedType" - there are a couple of functions that have buttons but no code associated with them, like transits, for example. There's a generic "to do" code block for those, which is literally just "NotImplemented". I don't understand why it would be firing those off when you open your copy, Venus.

Venus_Daily wrote: Thu Jul 11, 2024 4:42 pm Now I'm getting unable to pen "default_natal.opt".

For me the same. It doesn't open anymore in default natal. Also for returns.
I have done everything you mentioned here like recalculating but to no availability.

Thanks, Flo. Can you stick in for a little more testing? To be really specific:

1. If you calculate a NEW chart, does it come up without error?

2. If it does, and you then ask for a return on that chart, does it create the error?

3. When you say you've tried everything suggested, does that include reinstalling (on top of your existing install - no need to uninstall)? If not, then please do that.

4. If that doesn't fix it, we need to get you a new copy of the Default_Natal.opt file to copy to your computer. I could post a link to my version of the file for you to download or, if you are using OneDrive (and your Documents folder is on OneDrive), I can walk you through restoring this file from a day or two ago from the OneDrive recycle bin. (I didn't try this with Venus because her error message seemed to say OneDrive wasn't in the picture.)

In fact, that file is short. If it has become corrupted, you might be able to recreate it easily. Just a slight bit of geekiness here:

1. Find the file in Documents\tmsa\options (wherever the Documents folder is on your computer).

2. Make a copy of the existing Default_Natal.opt just in case. (Right-click on the file, drag off to the side, release the mouse button and select the option to copy the file.)

2. Open Default_Natal.opt in Notepad. Type Ctrl+A to select all text and press Delete. Copy everything below from the first { through the last } and paste it into that file. Save the file. (You can edit the settings later if you don't like my settings.)


{
"use_Eris": 1,
"use_Sedna": 0,
"use_Vertex": 0,
"Node": 0,
"show_aspects": 0,
"partile_nf": 0,
"angularity": {
"model": 2,
"no_bg": 1,
"major_angles": [
3.0,
7.0,
10.0
],
"minor_angles": [
1.25,
2.0,
3.0
]
},
"ecliptic_aspects": {
"0": [
4.0,
7.0,
10.0
],
"180": [
4.0,
7.0,
10.0
],
"90": [
3.0,
5.0,
7.5
],
"45": [
1.25,
2.0,
3.0
],
"120": [
3.0,
5.0,
7.5
],
"60": [
3.0,
5.0,
7.5
],
"30": [
0,
0,
0
]
},
"mundane_aspects": {
"0": [
4.0,
7.0,
10.0
],
"180": [
4.0,
7.0,
10.0
],
"90": [
3.0,
5.0,
7.5
],
"45": [
0,
0,
0
]
},
"midpoints": {
"0": 75,
"90": 75,
"45": 0,
"M": 75,
"is90": "d"
}
}

OK, I just got the problem, too. the current build had been working fine - lots of use today - then I went to run Veronica's lunars for her mega-wow night last night and got this (clicking the calculation button to recalc the chart didn't change anything):

I deleted her chart with the deletion option - went back to delete the folder as well. Input the data as a new chart and ran the lunars. This time they ran with no problem.

Hi Jim,

thank you very much for your help.
It seems I do not have the default natal file at all anymore.
It is nowhere in my files to be seen.

Also when I calculate a new chart, it is not possible except when I click select where I do have the option of outstanding chart and outstanding chart1. This way I can run a natal and a return chart.
I have made these files last month as to have a more defined and narrow calculation option.
So I am not completely unable to create a chart and returns.
Perhaps this may have somehow overwritten the default natal file, not sure.
If I remember well you suggested making extra options to calculate natals and returns if there were a lot of wider aspects to narrow them down.
That's what I have now as the default charts.
I may install the latest version of tmsa on my work computer, that should for now fix the issue.

Jim Eshelman wrote: Sat Jul 13, 2024 11:16 am OK, I just got the problem, too. the current build had been working fine - lots of use today - then I went to run Veronica's lunars for her mega-wow night last night and got this (clicking the calculation button to recalc the chart didn't change anything)...

That line number referenced in the error message has to do with meridian longitude calculation and assignment - what that tells me is that something in the recalculate logic isn't enough to bring an old chart up to date.

I still don't know why the issues were happening with chart options. That's a mystery to me.

FlorencedeZ. wrote: Sun Jul 14, 2024 1:23 pm It seems I do not have the default natal file at all anymore.

I reinstall of the latest version should fix this. If for some reason it doesn't do that, let us know, then (presumably) fix as follows:

1. Go to Documents\tmsa\options.
2. See if you have a file Default_Natal.opt. If so, rename it by putting ! at the start of its name.
3. Right-click in that folder somewhere and pick New > Text Document. Name it Default_Natal.opt (overwrite the .txt at the end).
4. Open the file in Notepad. Copy and paste the contents of my file that I gave above.
5. Launch TM and test to confirm this works.
6. Edit the file (in Change Options) as you see fit.

Mike V wrote: Sun Jul 14, 2024 1:48 pm That line number referenced in the error message has to do with meridian longitude calculation and assignment - what that tells me is that something in the recalculate logic isn't enough to bring an old chart up to date.

I wonder how that button is coded. I would have guessed that it loads the associated .dat file to populate the calculation page, uses the same page as the New Chart page, and calculation goes forward from there. (This is the least amount of duplicate code.)

If that's how it works, then the only breakdown I imagine is that the .dat page is structured differently. That would be a problem.

I just took an old chart, opened its .dat file in Notepad, recalculated, opened the new .dat file in Notepad, and compare visually size by side. They appear to be identical in every respect except all the calculated planets now have nine lines of calculated values instead of eight. (ML is added as an extra line, right?) On the one hand, I don't see how this could matter since the most direct coding path would read the chart data at the top and ignore the rest, recalculating the .dat file; but if code were trying to read the planets and map to values, it would find eight when it expected nine.

I suppose this could happen if the recalc code read the entire .dat file (not enough lines in it) rather than only reading the top.

{
"name": "Haarmann, Fritz",
"type": "Natal",
"class": "N",
"year": 1879,
"month": 10,
"day": 25,
"style": 1,
"time": 18.0,
"location": "Hannover, Deutschland",
"latitude": 52.37444444444444,
"longitude": 9.73861111111111,
"zone": "LMT",
"correction": -0.6491666666666667,
"notes": "AA",
"options": "Default Natal",

Jim Eshelman wrote: Sun Jul 14, 2024 3:13 pm

Mike V wrote: Sun Jul 14, 2024 1:48 pm That line number referenced in the error message has to do with meridian longitude calculation and assignment - what that tells me is that something in the recalculate logic isn't enough to bring an old chart up to date.

I wonder how that button is coded. I would have guessed that it loads the associated .dat file to populate the calculation page, uses the same page as the New Chart page, and calculation goes forward from there. (This is the least amount of duplicate code.)

This is indeed exactly how it works.

I ran a quick test with 0.5.6, manually removing ML from my natal .dat file, recalculating it, and running a lunar return; it works just fine. If I don't recalculate it and try to run a lunar return, I get the same exact error message. I took a long look through the code too, and I don't see a crack that this is slipping through.

Something must not be getting saved when you recalculate the base chart. Unless...

Jim (and others), when you say you recalculated the base chart, did you go to Select Chart -> Recalculate Chart -> Calculate, and then go back and click Solunars?

If you just go to Solunars -> Calculate, that does NOT recalculate the base chart - it only attempts to precess it, which it can't do successfully if the base chart has a different structure than the return chart.

Mike V wrote: Sun Jul 14, 2024 6:22 pm Jim (and others), when you say you recalculated the base chart, did you go to Select Chart -> Recalculate Chart -> Calculate, and then go back and click Solunars?

Yes, I did. (If there was an occasion where I did something different, I likely said so.)

SOP would be: While already in the Select Chart section with the chart already "found" (and failed), I clicked the Calculate Chart button (and Calculate).

Darn. I would love to have an example of a .dat file after attempted and failed recalculation, where the solunar return chart won't load. If you find any others, please share them with me so I can test them.

I see that there's been a lot of ghosts in the system over the past few days, and I haven't identified a concrete bug with any of them that I can actually patch. Here's where I think we've landed with our discussions and what I hope everyone can help me with.

FlorencedeZ. wrote: Sat Jul 13, 2024 1:47 am For me the same. It doesn't open anymore in default natal. Also for returns.
I have done everything you mentioned here like recalculating but to no availability.

[...]

thank you very much for your help.
It seems I do not have the default natal file at all anymore.
It is nowhere in my files to be seen.

It seems to me that you might've overwritten or otherwise deleted the default natal file. I'm not sure what else could cause behavior like that. Flo, have you been able to either copy the Default_Natal.opt file to your system, or do a fresh install and confirm that it works?

Venus_Daily wrote: Thu Jul 11, 2024 3:24 pm Each time I try to open anything, I get this error.

(NotImplementedType object is not callable)

Now I'm getting unable to [o]pen "default_natal.opt".

Venus, can you tell me if you're still getting errors, and if so, which of these 2?

Also, the casing is important here - does it say it can't open "Default_Natal.opt" or "default_natal.opt" ?

As far as I can tell, the only time anyone should ever see the Not Implemented error is when clicking Predictive Options. I'm wondering, maybe, if you are accidentally clicking that instead of Select Chart - not through your own fault, but maybe there's something weird going on with the program and your monitor, and your mouse isn't where it looks like it is? This might sound like a nonsense explanation but I've seen things like this happen where zoom and monitor resolution and stuff don't play well with certain programs, and the displayed mouse pointer is offset from the actual pointer. It's happened to me a lot with full-screen games that load weirdly, for example.
To test that, if you get the "NotImplementedType object is not callable" when clicking on Select Chart... can you try clicking directly above Select Chart and see what happens? Then right at the tippy top of Select Chart? etc.

I do have a patch version where I plan to make any fixes we can settle on here, and I do have a nicer error message for this (like we used to have; I'm not sure why exactly it broke) - but it doesn't change the functionality, it just displays a nice window that says "This functionality is not yet implemented." I don't think that's worth making everyone download another version, so I'll hold that back until we get something concrete (or I can get 0.6.0 out... the last week was a lot for me, but I'm getting back into working on Time Matters regularly again).

Or maybe it IS worth another download... A crazy idea: A couple of times, MikeN released a version that had some bizarre bug and it turned out to be a bad compile / packaging (whatever the term). He repackaged the exact same code and the bug went away.

Maybe...?

That's actually a good point. I'll package 0.5.7 later today and put a download link for it, and see if that exorcises some of these ghosts.

Mike, this might be one of the weird midpoint things you were anticipating. It's the first I've seen. Calculate the August 10, 2024 Liblunar for Washington, DC. Here are some relevant numbers:
I looked at this and thought, "What? How can the Venus/Saturn midpoint be on an angle?" Saturn is 2°20' before Descendant. Venus is 8°30' after Ascendant. You don't average those numbers and get 0°17'.

And then I saw it - at least, I think I do (the math is still imperfect) Venus is on EP-a. That's the angle distance that was being used. RAMC is 71°27' so Venus at RA 158°57' is 2°30' before EP-a. Saturn is 2°20' later than Asc in PVL. Average -2°30' and +2°20' and you get 0°05'. This still doesn't match the 0°17' but at least strangely produces a midpoint. (Maybe I didn't find the right one.)

In any case, midpoints in horizon and meridian in mundo should simply be in PVL, which doesn't work here.


LATER - I rechecked the other ingresses for the month, two of which showed nearly precise Saturn/Neptune midpoints on angles (mundo, the only way that matters in ingresses). There are other problems with this: See the August 3 Canlunar. It shows Sa/Ne 5' from an angle. Saturn is 1°59' below Asc, Neptune is 6°29' below Asc. Their midpoint isn't anywhere close to the angle. (Not sure if this snuck in, but their MLs are -14' and +24' from the horizon which - uh oh - averages to +5', the orb listed.)

Going back to the Liblunar to see if this suddenly started getting calculated in ML: Venus -59' from horizon, Saturn +25', which averages to - yup! - +17', the orb given for the Ve/Sa midpoint on angles.

Third, the July 21 Caplunar says Sa/Ne is 47' from an angle mundo. This isn't true in PVL at all. But in ML their orbs are +0°07' and +1°28', their midpoint being +0°47' from the horizon.


So that's what's happening here. Mundane midpoints to angles in ingresses is being calculated in ML instead of PVL.

Jim Eshelman wrote: Mon Jul 15, 2024 4:59 pm Mike, this might be one of the weird midpoint things you were anticipating. It's the first I've seen. Calculate the August 10, 2024 Liblunar for Washington, DC.

[...]

So that's what's happening here. Mundane midpoints to angles in ingresses is being calculated in ML instead of PVL.

Ugh. It's different from what I expected, but I know exactly why that's happening. When I added ML to the data points, I added it into the list in the order that you see displayed in the info table: into the 8th index, which used to be PVL, and then PVL became the 9th index. I never touched any of the midpoint code... which means it must still be looking at the 8th index for mundane calculations.

Thanks for bringing this to my attention. I'll try to have something up soon for this.

I actually thought that was what was happening - since it suddenly began using the value in the same place the right value used to be Easy thing to miss when you aren't actually looking at that part of the code.

The good news is, contrary to my first impression, the three "live" lunar ingresses in the next month do not have Sa/Ne, Sa/Ne, and Ve/Sa midpoints within a few minutes of the angles! (What's coming is bad enough, we don't need that.)

Okay, here's my attempt at 0.5.7. This should fix this completely, but let me know if you see any other midpoint weirdness. I also included a better error message when you click stuff that isn't implemented.

https://mega.nz/file/QP9lVBjA#P11-FeUPS ... fg6JgXrCdQ


The stuff below is for Jim; I doubt anyone else will have any interest:

Here is what I can see definitely doesn't work as far as midpoints are concerned:
"mmp" isn't defined, and I looked all the way back in the 0.4.x source code as far as I could, and it was never defined. I think this chunk of the code, and probably those 2 functions for (something with) eastpoint and zenith, were started but not finished.

A unique thing about Python is that it is interpreted line by line, rather than checked for errors at compile time. That means you can have landmines waiting in the code, and if you manage to tiptoe around them, you won't know. I think that's what has been happening with this.

One of these days, we should talk about midpoints and their behavior at a granular level; I don't understand the intent in most of this code, and I don't have much experience using midpoints (beyond "2 planets are exactly equidistant from an angle; I guess they're extra strong?").

0.5.7 installed at work. The upcoming Caplunar, Canlunar, and Liblunar no longer show the incorrect mundane midpoint contacts to angles. - On the original issue noted, I pulled up a previously calculated Jack Parsons chart, ran a solar return and got the error message, recalculated the natal (selected the chart and hit the Calculate button), then ran the SSR again - successfully and without error message. As far as I can tell, the fix is stable (but it mostly was for me anyway - would love to hear from Venus and Flo).

I'll come back to the rest in another post.

Regarding midpoints and angles: There was a behavior in MikeN's code I never liked but didn't push him on when he was trying to do so much at once. The midpoint code is complicated. The logic has lots of sub-rules. I think I know what he did (more or less) and I don't think it was the right approach. The upcoming (August 2) Canlunar for Washington is a good example of getting a wrong result. I chose to just live with it until things got much further down the track and ignore inappropriate listed items.

To explain, here is the theory first:

For ingresses, I consider it well established that mundane midpoint contacts to angle are valid. There may be other PVL midpoints that are valid, but we're willing to ignore those for the moment (and I'd be surprised if they were all valid - I think they aren't). [See, already this is getting confusing.] From what I have seen, mundane (PVL) midpoints in natals are not valid: When you do a side-by-side comparison of a natal chart's midpoints to angles in longitude and in PVL, it is sometimes starkly obvious not only that the ecliptical ones are sharper and clearer, but that the mundane ones are often misfits or outright wrong. (This is casual observation, not organized empiricism.)

But ingresses - those mundane midpoint-angle contacts are usually as big a deal as the foreground aspects. - In doing this we are only using planets that are already foreground, not midpoints to angles using all planets whatsoever. - Another digression: I've entertained the possibility that these midpoints only seem important because they are merely restating what the foreground planets are; but a LOT of cases seem to say they are important by themselves because of the exact planet pairs involved.

So, we want to allow mundane midpoints on all categories of charts and let the user sort out whether to look at ecliptical, mundane, both, or neither.

Here's how it SHOULD work:

1. PVL midpoints to angles should be identifiable using all foreground planets. These are listed as "Angle" instead of a specific angle because the nature of the PV quadrants means that the same PVL midpoint is actually on all four angles at the same time - and this made an easy visual distinction. (If it name a specific major angle, it's an ecliptical contact.)

2. Mundane midpoints to EP-WP in RA should be taken in RA. The idea is that if two planets are on this axis and their midpoint (in RA) is on the EP-WP axis itself, this "snaps" the pair into place like a tight aspect (doing what midpoints do).

3. "Mundane" midpoints to Zenith-Nadir are actually ecliptical contacts because contact with Z or N is taken ecliptically. (A truly mundane occupancy of Zenith or Nadir is identical with being on the MC-IC great circle.) EP-WP in longitude is the same. Therefore, these work like EP-WP in RA except it's measured in longitude. (Depending on other midpoint selections, these may duplicate ecliptical midpoints to Asc and MC.)

Here's what I believe MikeN did, perhaps because of being unclear:
1. Take all planets marked Foreground for any reason (any set of angles).
2. Calculate their midpoints to angles in any combinations specified above.

An example of errors this allows:
By this logic, two planets could be foreground because they are, say, both within 10° of the horizon and their RAs just happen to also have their midpoint in RA on EP (even if they are, say, 6° either side of it, way out of EP orb).


So here's how it should work instead:

1. For mundane midpoints to horizon and meridian (listed as "Angle"): Using the pool of planets that are foreground in any fashion, are planet's midpoints in PVL within orb of 0°, 90°, 180°, or 270° PVL.

2. For mundane midpoints to EP-a or WP-a (listed as "EP-a"): Using the pool of planets that are conjunct EP-a or WP-a in RA, are their midpoints in RA conjunct EP-a / WP-a?

3. For "mundane" midpoints to Zenith, Nadir, or EP/WP in longitude, (listed as "Z" or "E{p?}): Using the pool of planets that are conjunct Z-N or EP-WP in longitude, are their midpoints in longitude conjunct the angle that the planets are also conjunct. (If ecliptical aspects are turned on include squares to midpoints, this will duplicate items on the Asc or MC lines.)

One further possible confusion: The above three rules can't strictly use whatever angles is MARKED for the planets. For example, two planets might be marked as being on Asc because the orb to Asc of one or both of them may have a higher % score than the orbs to EP-a. But if they are also, say, 2°55' either side of EP-, we definitely want to capture the 0°00' midpoint contact.


(I hope I got that all right.)

Mike V wrote: Mon Jul 15, 2024 11:33 pm Here is what I can see definitely doesn't work as far as midpoints are concerned:

Code: Select all

def find_midpoint(self, planet, plist, i, j, options):
    mpx = options.get('midpoints', {})
    if planet[0] == 'Ep':
        return self.mmp_eastpoint(planet, mmp, plist, i, j)
    if planet[0] == 'Ze':
        return self.mmp_zenith(planet, mmp, plist, i, j)

    # Otherwise, run code that I don't really understand

"mmp" isn't defined, and I looked all the way back in the 0.4.x source code as far as I could, and it was never defined. I think this chunk of the code, and probably those 2 functions for (something with) eastpoint and zenith, were started but not finished.

Got it. That could crreat problems, right?

I'm guessing mmp is "mundane midpoint," but of course it has to be defined. Perhaps my tedious notes above help do that?

A unique thing about Python is that it is interpreted line by line, rather than checked for errors at compile time. That means you can have landmines waiting in the code, and if you manage to tiptoe around them, you won't know. I think that's what has been happening with this.

You could always redo this in C++ this afternoon, right? Shouldn't take more than a couple of hours? <vbseg>

One of these days, we should talk about midpoints and their behavior at a granular level; I don't understand the intent in most of this code, and I don't have much experience using midpoints (beyond "2 planets are exactly equidistant from an angle; I guess they're extra strong?").

For this particular purpose, I think I got pretty grainy above. For a broader picture of function and interpretation (but not mentioning mundane ones at all), look in the CSA sub-forum for Chapter 16.

Thank you for enumerating the valid cases. I think I got all of it. Like other things, this will be easier to do when I'm done refactoring the core logic - things like "a planet is foreground and closest to one angle, but for other purposes we need to consider its other angularities" will be significantly easier to do.

Jim Eshelman wrote: Tue Jul 16, 2024 9:33 am I'm guessing mmp is "mundane midpoint," but of course it has to be defined. Perhaps my tedious notes above help do that?

Your notes above do define this, for me - but I still need to reverse-engineer the code to see what structure "mmp" actually needs to have. (For example, "planet" is actually a list with 2 elements: a name, and a longitude, or I guess PVL or RA coordinate.) This is much less important if I do a rewrite based on your expected functionality rather than reproducing the current functionality with all of its nuances, but it might raise some questions for me that are worth asking... so I'll do that when I get around to rewriting the midpoint code (and making it work for biwheels).

Jim Eshelman wrote:

A unique thing about Python is that it is interpreted line by line, rather than checked for errors at compile time. That means you can have landmines waiting in the code, and if you manage to tiptoe around them, you won't know. I think that's what has been happening with this.

You could always redo this in C++ this afternoon, right? Shouldn't take more than a couple of hours? <vbseg>

Oh, of course
In all seriousness, if you tasked me to write exactly this project (a desktop app, not a web app) from scratch, with no code to start from, I would very likely choose Python anyway. But I would take advantage of the newest developments in Python GUI libraries, which I'm vaguely aware of but don't have any experience with. (I actually do have some prior experience with Tkinter, which is what TM uses.) These likely didn't exist in their current forms when Mike N started development.

OK, I'm having the same kind of errors as Venus_Daily above. 3 messages about them, and then the system crashes. I've reinstalled the program twice using the repair and remove options and keep getting the same result. The program will show a previously created chart but will not calculate or recalculate any new natal charts or solunars. It's been like this since Friday. I've even done a reboot. I made sure all the folders were taken out of read-only mode (thought that might be it) and made sure the program could see through the firewalls etc. It also will not delete old solunars I don't need anymore - I have to do that by going into the folder. I have not tried adjusting any parameters in the .dat files. Help please.

fivesight wrote: Tue Jul 30, 2024 7:15 pm I've reinstalled the program twice using the repair and remove options and keep getting the same result.

Are you using the installer for 0.5.7?

Yes. But every time I reinstall (I think it's been 3 times) it's participating in the wrong behavior. I think it may have something to do with (what we used to call) "the registry" because when I delete the current installs TMSA still has the behavioral logs from the older ones. I could be wrong about that - I used to work in IT but I've been out of touch with the developments in windows for years. Luckily, my son who lives with me is very good at working in the backdoors of windows. On the other hand, it could be something simpler to deal with, so I thought I might check with you before I completely erase the history of TMSA on this computer and start from scratch with a fresh install, because frankly, I am so busy right now that I don't want to spend the time away from my writing unless it's a last resort.

It is very possibly a registry issue. I am a developer by trade, and OS matters are not my wheelhouse; I only have random knowledge I've picked up from writing code on various OSes and dealing with Windows stuff for gaming.

TMSA does go through the registry looking for "user shell folders," which is the default place that it stores things like options. If it can't find that, it tries to use Documents. Cleaning out the registry could very well fix the issue - the "not implemented" bug was from an older version and is fixed in 0.5.7, so I wonder if somehow old code is getting stuck somewhere. I feel like that shouldn't be happening, but I admittedly don't really understand what Windows does when it installs something aside from put my specific source files into a specific folder (which we can just delete/rename/whatever).

Something I would like to do in the future is move the base folders somewhere else on Windows, so we don't have to ever touch the registry - but I have to still be backwards-compatible with the current locations of everything, of course.

Windows itself is more my department. It does sound like something is junked up and needs a good cleaning. However, I'm inclined to trust the Windows uninstall process before doing something more manual or esoteric. Let's try a layered, redundant uninstall.

1. If you have content you want to save (to dig through later), rename the Documents\tmsa folder (just put a ! in front of the name, which handles both longname and shortname processes).

2. If TM is installed, uninstall it to get a level playing field. Do this specifically by finding Time Matters in the Start menu, right-click, pick Uninstall. This will take you to the Control Panel's Programs and Features window where I think the process is to right-click on the program and pick uninstall (I'm not going to uninstall mine to test it <g>).

3. Restart the computer and launch no programs. Everything until now gives us a clean starting point with no likely competing processes running.

4. After restarting the computer, install TM (latest version).

5. Without running anything else, immediately uninstall TM using the process above. These two steps put everything the way it ideally should be and then - presuming the Windows uninstall works properly - clears everything that TM should have ever put in place.

6. Restart the computer.

7. Reinstall TM (without moving over your saved files yet) and test.

Mike V wrote: Wed Jul 31, 2024 10:52 pm Something I would like to do in the future is move the base folders somewhere else on Windows, so we don't have to ever touch the registry - but I have to still be backwards-compatible with the current locations of everything, of course.

My thoughts... beginning with a bit of history.

I recommended putting the TMSA data files in the Documents folder. This was based on a successful strategy used by Solar Fire that I had discovered has a (probably inadvertent) advantage that it allows data files (chart files and configuration or display files like aspect definitions or planet lists) to replicate across other computers logged into the same Microsoft account.

Solar Fire is a commercial product. Its license says you, the licensee, are entitled to run it on multiple computers if it's just you using it and (the ambiguous but "we all know what it means" standard phrase) you are only using it on one computer at a time. I have it installed on four computers that I own and use.

Using Windows the way it is designed to be used, and the way I always recommend, users should be logged in with a Microsoft account - not a local machine account - and have OneDrive fully enabled. When this happens, making a change in a file on one computer (in a OneDrive folder) lets it be updated (almost instantly) on all other machines currently online and logged in to the same Microsoft account.

An option in OneDrive - which I think should be default, but actually requires user action - is that the Documents folder, Desktop, and other special folders can be made part of OneDrive and also synced across computers. (I suspect the real reason that it's turned off is that people's documents and picture folders often have far more content than the free storage that comes with all Microsoft accounts, although anyone with an Office 365 (aka Microsoft 365) account - which is most of the computer-using world - automatically gets a terabyte of cloud storage.)

With Solar Fire files in the Documents folder, which I have set to be a OneDrive folder, I can update an aspect definition file on one computer and its updated automatically on all my computers. I can run a chart at home and save it, then come to the office and the chart is waiting in the charts file where I left it.

I wanted the same flexibility for TMSA. However, there are limits. Not everyone logs into Windows with a Microsoft account. Some who do that have disabled some OneDrive features. Others don't take the step of making Documents a OneDrive folder. And, of course, most people probably still have only one computer so the whole device mobility (ability to seamlessly move from device to device without seeming to be on a different computer) is moot.

Therefore, the Documents folder appeared to be the best choice: Every Windows installation (every user profile) has a Documents folder. It may be redirected to a location in OneDrive or remain in the local-only profile area. That is, it might stay in C:\Windows\Users\userprofile\Documents or be redirected to C:\Users\userprofile\OneDrive\Documents (or, in theory, redirected anywhere else, since folder redirection has long been a standard in business and sometimes done by a few individual Windows users). It could easily be in one of two places and theoretically could be anywhere at all. But it's always a Documents folder and Windows itself handles the redirection and tracking.

Documents doesn't have a standard system variable defining its location, so a programmer (I'm barely a programmer, more of a scripter) has to find this some other way. I guess that's what Mike meant about checking through shell folders. - Ah, yes, the place you can find this in the Registry is:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Except, there is a flag in that folder labelled !Do not use this registry key that has content, "Use the SHGetFolderPath or SHGetKnownFolderPath function instead". OK, now we're back to programmer's turf more than mine. But that's the idea.



'While I understand the desire to make storage locations simpler, I do think (unless I'm missing something obvious) the choice has to be some location that (1) exists [or can exist] in OneDrive when OneDrive is fully implemented, (2) also exists on every Windows system regardless of OneDrive implementation, and (3) can be easily located by a simple, consistent process as needed.

The program then needs to be separately installed on each computer. Data files are automatically shared across all computers for that user.

Thanks Mike & Jim. I took some time to work on it today, but didn't get results - in fact, the install failed when I clicked "Finish" - I don't know how to upload errors here, I did make an image of one of the errors I got trying to launch the program but I couldn't find a way to insert it into this message. This one was about Python, and I think my version might be old (haven't used it in years, it's v 3.8) so I imagine I need a newer install, but let me know your recommendation please!

Your version of Python doesn't matter. In fact... just in case... go ahead and uninstall it.

To attach an image, at the bottom of your message composition window click Attachments then the button to add an image. (I can come back and delete it when we're done with it.)

Here's an example. I stopped trying for a while, and cut out some time for installation and building a new set of client files today, but this is what I got. It wouldn't even install at first, because it said that I didn't have access to the directory (my temp/appdata etc.) so I tried to run the zip file again and it worked. I am the admin of this computer and never ran across anything like this before.

Mike is going to have more to say on this, but... the first file listed isn't anywhere on my computer - no similar path exists. I have no idea what it is (are you perhaps running your own Python emulator? - Nothing after C:\Users\username looks familiar (nor is it present on my computers). - I see that cx_freeze is a Python packager.

The most bizarre part of this is that it lists my computer's file paths in your error message. I'm guessing this is some wizardry that cx_freeze does to package all the runtime dependencies. I will have to investigate this more when I get time.

%USERPROFILE%\Documents\tmsa is the default path that it tries to make a "root directory" if it can't find the expected shell folders.

I wonder if different parts of the program initialization end up using that path before checking to see if the tmsa folder got created...? I'll check.

fivesight wrote: Mon Aug 19, 2024 12:32 pm It wouldn't even install at first, because it said that I didn't have access to the directory (my temp/appdata etc.) so I tried to run the zip file again and it worked. I am the admin of this computer and never ran across anything like this before.

I'm sorry it's been so frustrating.

One thought I have on this is that this is still a pretty DIY package, with no Windows-recognized security certificate or anything. (Making one is on my radar for an upcoming release. I'm not positive that this is the only thing I need to do.) Windows does not inherently trust it (yet) to be non-malicious code, and it tries to protect you.

Neither myself nor Mike N were desktop app developers by trade. For me, it's a bit like being a residential plumber who is trying to get the plumbing on a submarine to work... much of it is the same, but the context is very different, so I appreciate everyone's patience in debugging what are probably pretty basic issues (which I have never run into professionally due to the area I work in). We are probably going to run into a suite of similar issues for the Linux and MacOS ports, with bugs distinctive to those OSes.

This is one of many reasons why, in the long, long run, I am intending to release this functionality as a web-based application, with nothing installed locally.

The basic thread on installing TM gives security-related steps to work around these certificate issues - at least most of the time. If you didn't follow these steps, you may want to try them: https://www.solunars.com/viewtopic.php?f=75&t=6667

Just wanted to let someone know, I installed TMSA on a new machine and got the same error message.

Venus_Daily wrote: Mon Sep 23, 2024 7:57 am Just wanted to let someone know, I installed TMSA on a new machine and got the same error message.

Which error message?

And which version did you install?

Jim Eshelman wrote: Mon Sep 23, 2024 9:08 am

Venus_Daily wrote: Mon Sep 23, 2024 7:57 am Just wanted to let someone know, I installed TMSA on a new machine and got the same error message.

Which error message?

And which version did you install?

Hey, Jim. The newest version. And the last message I got last time.

Venus_Daily wrote: Tue Sep 24, 2024 7:20 am

Jim Eshelman wrote: Mon Sep 23, 2024 9:08 am

Venus_Daily wrote: Mon Sep 23, 2024 7:57 am Just wanted to let someone know, I installed TMSA on a new machine and got the same error message.

Which error message?

And which version did you install?

Hey, Jim. The newest version. And the last message I got last time.

Hey, Venus. Can you clarify if by “the newest version” you mean 0.5.7, or one of the 0.6.0 alphas?

0.6.0