View Issue Details

Status closed 
Fixed in Version2.5 (リリース) 
Summary0000456: Separate the time cache from the update file
DescriptionI just don't quite understand why the two were put together, eh
Users shouldn't use information about "when changes were made" in an update, and ghost authors, even if they collaborate on development, they have different change times on different computers
It seems to me that putting the two things together just creates more hassle and wasted bandwidth

So could the two be stored separately, like naming the time cache file as "updates.cache"

If you're worried about read speed, I think because the update files now have a defined file order, so you could use a design where the first line of updates.cache corresponds to the first file in updates.txt, which would even prevent you from having to write the file path in updates.cache again

Oh and please let me know if you have reasons for putting them together
TagsNo tags attached.
Attach Tags



2022-03-13 07:27

administrator   ~0001172


- SSP will store last succeeded update time internally and use it as "last updated time". If it was not already stored, fallback to old method.
- if you want to get update time, execute \![get,property,OnGetPropUpdateTimeEvent,currentghost.update_time]


2022-03-13 10:30

reporter   ~0001173

Haha I think I didn't make myself clear, I meant that there is information in updates.txt or updates2.dau about the last updated time of each file that is not used by the user, and this is not necessary as far as I know
So I thought it might be possible to split that information from updates.txt or updates2.dau into other files


2022-03-13 11:57

administrator   ~0001175

Last edited: 2022-03-13 12:00

I think your suggestion is unneeded optimization, because datetime information is only 24bytes, and If there is 1000 files, the difference would only be 24KB. A difference of 24KB is within the margin of error in today's network environment.
Current specification is easy to read and write programmatically, so splitting files is not a good idea.

Only we need to improve is just ignoring datetime information during update process. I'll implement it in next version.


2022-03-13 12:36

administrator   ~0001177

2.5.82 : skipping datetime information during update process


2022-03-13 14:37

reporter   ~0001178

Thank you for the clarification! I understand.
Please close this issue
And, could you consider a slightly earlier implementation of these two issues if possible?
I have some functional ideas related to these two issues, so if you can implement these I can put that into practice.

Issue History

Date Modified Username Field Change
2022-03-12 02:54 guest New Issue
2022-03-13 07:27 ponapalt Assigned To => ponapalt
2022-03-13 07:27 ponapalt Status new => closed
2022-03-13 07:27 ponapalt Resolution open => fixed
2022-03-13 07:27 ponapalt Fixed in Version => 2.5 (リリース)
2022-03-13 07:27 ponapalt Note Added: 0001172
2022-03-13 10:30 guest Status closed => feedback
2022-03-13 10:30 guest Resolution fixed => reopened
2022-03-13 10:30 guest Note Added: 0001173
2022-03-13 11:57 ponapalt Note Added: 0001175
2022-03-13 11:59 ponapalt Note Edited: 0001175
2022-03-13 12:00 ponapalt Note Edited: 0001175
2022-03-13 12:36 ponapalt Note Added: 0001177
2022-03-13 14:37 guest Note Added: 0001178
2022-03-13 14:37 guest Status feedback => assigned
2022-03-13 14:55 ponapalt Status assigned => closed