Minecraft 1.7.10
Forge 10.13.4.1614
TIS-3D-MC1.7.10-1.4.0.78

I've encountered a Display Module misbehaving caused by a data queue violation during save/load. The issue is very similar to #149, but I didn't find any indication that the Execution Module was resetting its state.

I experimented with an Execution Module containing code that endlessly sends sequences from 0 to 9 to a Terminal Module:

MOV 48 RIGHT
MOV 49 RIGHT
MOV 50 RIGHT
MOV 51 RIGHT
MOV 52 RIGHT
MOV 53 RIGHT
MOV 54 RIGHT
MOV 55 RIGHT
MOV 56 RIGHT
MOV 57 RIGHT

After saving/loading, with some probability, some number can occur twice in a row. It looks something like this:

...3456778901...

The problem also occurs when passing data from a Execution Module to a Queue Module. I have not been able to reproduce the issue when transferring data between two Queue Modules.

this may be a weird question
but why 1.7
why not go up to atleast 1.12 (i live on 1.18 though, and 1.18 has the most TIS addons at a grand total of 3)
Edit: I am now being forced to host a 1.7 modpack

this may be a weird question
but why 1.7

Because GregTech 6

It looks like the problem persists in the latest version of TIS-3D Forge for Mc 1.20.1. The following are issues that occur in single player when exiting the world to the main menu while transferring data from the Execution Module to other modules and reloading the world. During save/load, I was usually in the same chunk as the Execution Module. Tests were made in a flat world near the spawn point.

1. The computer with the Execution Module and Terminal Module is located approximately in the center of the chunk. Duplicate characters may occur after saving/loading. Characters can be duplicated many times, it looks something like this: 7890101234. It seems that the probability and number of duplications increases with the speed of the computer. If after that you pause the computer and save/load or go a long distance and return, all traces of errors disappear and the Terminal Module looks as if no errors occurred during operation.
2. The computer is located in such a way that the Execution Module and Terminal Module are in different chunks. After saving/loading, characters may be lost, sometimes several in a row. Unlike the previous case, traces of errors do not disappear even after pausing and re-saving/loading. And it seems to me that during these tests, the Execution Module and Terminal Module sometimes reset their state during save / load, I'm not sure.
3. The computer with the Execution Module and Queue Module is located so that these modules are in different chunks. During saving/loading, the Queue Module resets its state, that is, it loses the data that it managed to receive before saving/loading.
4. The computer with the Execution Module and the Display Module is located so that these modules are in different chunks and the Execution Module endlessly sends sequences from 0 to 9. After saving/loading, the picture on the Display Module changes.
5. Two computers are in the same chunk and are connected using the Infrared Module. The sending computer has an Execution Module, the receiving computer has a Terminal Module or Queue Module. One signal is lost during save/load. Due to the large number of modules, it is difficult to say at what stage the signal is lost, but based on the results of previous tests, I think that the loss occurs when transmitting between two Infrared Modules.
6. This problem occurs without saving/loading and was found on the computer from the first case. Sometimes, after a complete restart of the computer, the first character on the Terminal Module is incorrect. Apparently, after restarting the computer, the Terminal Module first of all displays the character that it did not have time to display before shutting down. To reproduce the bug, you need to put the Lever on one side of the Controller and Redstone Dust next to the other side of this Controller.

I don't know how to reopen this issue. Or should I create a new issue?

I'm afraid I don't have the time to support older versions, if you can still repro this on the latest one, feel free to reopen. That said, I couldn't repro this, so I'm hoping it would be fixed by either the one you linked or some other change since then.

New World 2.zip
Mods I used with this save:
architecture-9.1.12-forge
markdown_manual-MC1.20.1-forge-1.2.4+c803392
tis3d-MC1.20.1-forge-1.7.4+41b76d3

There are broken redstone wires near some setups that I used to pause the computers. You can restore them, but remember that this may cause problem number 6.

At least some problems are not always reproduced the first time. Sometimes it takes several attempts, usually no more than ten.

The first setup reproduces problem number 4.
The second setup reproduces problem number 6.
The third setup reproduces problem number 1.
The fourth setup reproduces problems number 1 and 2.
The fifth setup reproduces problem number 3.
The sixth setup (which consists of two computers with Infrared Modules) reproduces problems number 1 and 5.

Problem number 3 (total or partial loss of data in the module) seems to also happen with the Terminal Module and with the Display Module (setups 1 and 4), but I'm not sure. I don't know if something like this is happening with the Execution Module.

I'm afraid I still cannot reproduce this issue. Could you share a minimal world file of MC 1.20.1 with the latest version of the mod (and no other mods) that reproduces this for you? Might be something particular about your setup I'm misunderstanding or doing differently. Thanks.

Thanks a lot, that helped tremendously. I must've misinterpreted some of what you wrote or had an oversight in my test setups. With that world I could reproduce the issues after trying enough. A few of these turned out to be race conditions, so I might also just have gotten "lucky" when trying to repro it before.

I think with the recent batch of fixes, all of these should be tackled.

Again, thanks so much for the in-detail report and providing the world save, very much appreciated!

I ran tests on the latest version of TIS-3D and apparently problem number 5 is still not resolved. The sixth setup with some probability loses one signal if both computers are running during saving/loading. Merging two computers into one does not prevent signal loss.

Other problems seem to have been resolved (or I didn't try enough during testing).