add sar_trace_offset* commands by rudkoLA · Pull Request #368 · p2sr/SourceAutoRecord

rudkoLA · 2026-06-17T13:57:54Z

this is for comparing two traces of tases so you look at a place where they intersect and using the command make the ticks of both tases at the point the same by subtracting some amount of ticks from the slower tas making the bbox be forwarder and aligned with the faster tas
didn't test linux

ThisAMJ · 2026-06-17T14:05:33Z

+ trace_ticks[h.trace_name] = tick;
+	}
+
+	auto fastest_trace = playerTrace->GetTrace(fastest_trace_name);


Unused variables fastest_trace_name, fastest_trace

Krzyhau

Separately handled state for offset sounds weird to me. It should be a part of trace data that gets reset/removed along with the trace itself. In most cases, when you're doing comparisons, the original trace is recorded once.

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

Krzyhau · 2026-06-18T06:29:09Z

+	// Universal map for trace tick offsets to be able to preserve them between trace recordings
+	std::unordered_map<std::string, int> tickOffsets;


You've created extra trace information which is implicitly not cleared when removing traces. I'm not a fan of that and I'd like to know what justifies this choice.

I wanted to make trace offset not get reset if you rerecorded a trace so I needed to store the offsets somewhere that isn't inside the trace itself

Krzyhau · 2026-06-18T06:33:10Z

 	}
 }

+CON_COMMAND(sar_trace_sync, "sar_trace_sync - syncs all the hovered traces to the fastest trace.\n") {


What if we don't want to compare to the trace that's fastest? What if our other traces we're comparing to are faster instead?
I think this feature would be more versatile if you could specify which trace to sync to (that is, sar_trace_sync_all_to [trace_name])

I already implemented this but I guess I forgot to push it

rudkoLA · 2026-06-18T12:36:29Z

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

this was the first thing I implemented but changed it to sync cause i felt I wouldn't need to manually set offset and would just always use sync. also I couldn't find a way to be able to both set offsets and see them I was happy with, the thing I had just used auto complete to show the trace name and offset

rudkoLA · 2026-06-17T13:57:54Z

this is for comparing two traces of tases so you look at a place where they intersect and using the command make the ticks of both tases at the point the same by subtracting some amount of ticks from the slower tas making the bbox be forwarder and aligned with the faster tas
didn't test linux

ThisAMJ · 2026-06-17T14:05:33Z

+ trace_ticks[h.trace_name] = tick;
+	}
+
+	auto fastest_trace = playerTrace->GetTrace(fastest_trace_name);


Unused variables fastest_trace_name, fastest_trace

Krzyhau

Separately handled state for offset sounds weird to me. It should be a part of trace data that gets reset/removed along with the trace itself. In most cases, when you're doing comparisons, the original trace is recorded once.

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

Krzyhau · 2026-06-18T06:29:09Z

+	// Universal map for trace tick offsets to be able to preserve them between trace recordings
+	std::unordered_map<std::string, int> tickOffsets;


You've created extra trace information which is implicitly not cleared when removing traces. I'm not a fan of that and I'd like to know what justifies this choice.

I wanted to make trace offset not get reset if you rerecorded a trace so I needed to store the offsets somewhere that isn't inside the trace itself

Krzyhau · 2026-06-18T06:33:10Z

 	}
 }

+CON_COMMAND(sar_trace_sync, "sar_trace_sync - syncs all the hovered traces to the fastest trace.\n") {


What if we don't want to compare to the trace that's fastest? What if our other traces we're comparing to are faster instead?
I think this feature would be more versatile if you could specify which trace to sync to (that is, sar_trace_sync_all_to [trace_name])

I already implemented this but I guess I forgot to push it

rudkoLA · 2026-06-18T12:36:29Z

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

this was the first thing I implemented but changed it to sync cause i felt I wouldn't need to manually set offset and would just always use sync. also I couldn't find a way to be able to both set offsets and see them I was happy with, the thing I had just used auto complete to show the trace name and offset

rudkoLA · 2026-06-17T13:57:54Z

this is for comparing two traces of tases so you look at a place where they intersect and using the command make the ticks of both tases at the point the same by subtracting some amount of ticks from the slower tas making the bbox be forwarder and aligned with the faster tas
didn't test linux

ThisAMJ · 2026-06-17T14:05:33Z

+ trace_ticks[h.trace_name] = tick;
+	}
+
+	auto fastest_trace = playerTrace->GetTrace(fastest_trace_name);


Unused variables fastest_trace_name, fastest_trace

Krzyhau

Separately handled state for offset sounds weird to me. It should be a part of trace data that gets reset/removed along with the trace itself. In most cases, when you're doing comparisons, the original trace is recorded once.

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

Krzyhau · 2026-06-18T06:29:09Z

+	// Universal map for trace tick offsets to be able to preserve them between trace recordings
+	std::unordered_map<std::string, int> tickOffsets;


You've created extra trace information which is implicitly not cleared when removing traces. I'm not a fan of that and I'd like to know what justifies this choice.

I wanted to make trace offset not get reset if you rerecorded a trace so I needed to store the offsets somewhere that isn't inside the trace itself

Krzyhau · 2026-06-18T06:33:10Z

 	}
 }

+CON_COMMAND(sar_trace_sync, "sar_trace_sync - syncs all the hovered traces to the fastest trace.\n") {


What if we don't want to compare to the trace that's fastest? What if our other traces we're comparing to are faster instead?
I think this feature would be more versatile if you could specify which trace to sync to (that is, sar_trace_sync_all_to [trace_name])

I already implemented this but I guess I forgot to push it

rudkoLA · 2026-06-18T12:36:29Z

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

this was the first thing I implemented but changed it to sync cause i felt I wouldn't need to manually set offset and would just always use sync. also I couldn't find a way to be able to both set offsets and see them I was happy with, the thing I had just used auto complete to show the trace name and offset

rudkoLA · 2026-06-17T13:57:54Z

this is for comparing two traces of tases so you look at a place where they intersect and using the command make the ticks of both tases at the point the same by subtracting some amount of ticks from the slower tas making the bbox be forwarder and aligned with the faster tas
didn't test linux

ThisAMJ · 2026-06-17T14:05:33Z

+ trace_ticks[h.trace_name] = tick;
+	}
+
+	auto fastest_trace = playerTrace->GetTrace(fastest_trace_name);


Unused variables fastest_trace_name, fastest_trace

Krzyhau

Separately handled state for offset sounds weird to me. It should be a part of trace data that gets reset/removed along with the trace itself. In most cases, when you're doing comparisons, the original trace is recorded once.

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

Krzyhau · 2026-06-18T06:29:09Z

+	// Universal map for trace tick offsets to be able to preserve them between trace recordings
+	std::unordered_map<std::string, int> tickOffsets;


You've created extra trace information which is implicitly not cleared when removing traces. I'm not a fan of that and I'd like to know what justifies this choice.

I wanted to make trace offset not get reset if you rerecorded a trace so I needed to store the offsets somewhere that isn't inside the trace itself

Krzyhau · 2026-06-18T06:33:10Z

 	}
 }

+CON_COMMAND(sar_trace_sync, "sar_trace_sync - syncs all the hovered traces to the fastest trace.\n") {


What if we don't want to compare to the trace that's fastest? What if our other traces we're comparing to are faster instead?
I think this feature would be more versatile if you could specify which trace to sync to (that is, sar_trace_sync_all_to [trace_name])

I already implemented this but I guess I forgot to push it

rudkoLA · 2026-06-18T12:36:29Z

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

this was the first thing I implemented but changed it to sync cause i felt I wouldn't need to manually set offset and would just always use sync. also I couldn't find a way to be able to both set offsets and see them I was happy with, the thing I had just used auto complete to show the trace name and offset

rudkoLA · 2026-06-17T13:57:54Z

this is for comparing two traces of tases so you look at a place where they intersect and using the command make the ticks of both tases at the point the same by subtracting some amount of ticks from the slower tas making the bbox be forwarder and aligned with the faster tas
didn't test linux

ThisAMJ · 2026-06-17T14:05:33Z

+ trace_ticks[h.trace_name] = tick;
+	}
+
+	auto fastest_trace = playerTrace->GetTrace(fastest_trace_name);


Unused variables fastest_trace_name, fastest_trace

Krzyhau

Separately handled state for offset sounds weird to me. It should be a part of trace data that gets reset/removed along with the trace itself. In most cases, when you're doing comparisons, the original trace is recorded once.

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

Krzyhau · 2026-06-18T06:29:09Z

+	// Universal map for trace tick offsets to be able to preserve them between trace recordings
+	std::unordered_map<std::string, int> tickOffsets;


You've created extra trace information which is implicitly not cleared when removing traces. I'm not a fan of that and I'd like to know what justifies this choice.

I wanted to make trace offset not get reset if you rerecorded a trace so I needed to store the offsets somewhere that isn't inside the trace itself

Krzyhau · 2026-06-18T06:33:10Z

 	}
 }

+CON_COMMAND(sar_trace_sync, "sar_trace_sync - syncs all the hovered traces to the fastest trace.\n") {


What if we don't want to compare to the trace that's fastest? What if our other traces we're comparing to are faster instead?
I think this feature would be more versatile if you could specify which trace to sync to (that is, sar_trace_sync_all_to [trace_name])

I already implemented this but I guess I forgot to push it

rudkoLA · 2026-06-18T12:36:29Z

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

this was the first thing I implemented but changed it to sync cause i felt I wouldn't need to manually set offset and would just always use sync. also I couldn't find a way to be able to both set offsets and see them I was happy with, the thing I had just used auto complete to show the trace name and offset

rudkoLA · 2026-06-17T13:57:54Z

this is for comparing two traces of tases so you look at a place where they intersect and using the command make the ticks of both tases at the point the same by subtracting some amount of ticks from the slower tas making the bbox be forwarder and aligned with the faster tas
didn't test linux

ThisAMJ · 2026-06-17T14:05:33Z

+ trace_ticks[h.trace_name] = tick;
+	}
+
+	auto fastest_trace = playerTrace->GetTrace(fastest_trace_name);


Unused variables fastest_trace_name, fastest_trace

Krzyhau

Separately handled state for offset sounds weird to me. It should be a part of trace data that gets reset/removed along with the trace itself. In most cases, when you're doing comparisons, the original trace is recorded once.

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

Krzyhau · 2026-06-18T06:29:09Z

+	// Universal map for trace tick offsets to be able to preserve them between trace recordings
+	std::unordered_map<std::string, int> tickOffsets;


You've created extra trace information which is implicitly not cleared when removing traces. I'm not a fan of that and I'd like to know what justifies this choice.

I wanted to make trace offset not get reset if you rerecorded a trace so I needed to store the offsets somewhere that isn't inside the trace itself

Krzyhau · 2026-06-18T06:33:10Z

 	}
 }

+CON_COMMAND(sar_trace_sync, "sar_trace_sync - syncs all the hovered traces to the fastest trace.\n") {


What if we don't want to compare to the trace that's fastest? What if our other traces we're comparing to are faster instead?
I think this feature would be more versatile if you could specify which trace to sync to (that is, sar_trace_sync_all_to [trace_name])

I already implemented this but I guess I forgot to push it

rudkoLA · 2026-06-18T12:36:29Z

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

this was the first thing I implemented but changed it to sync cause i felt I wouldn't need to manually set offset and would just always use sync. also I couldn't find a way to be able to both set offsets and see them I was happy with, the thing I had just used auto complete to show the trace name and offset

rudkoLA · 2026-06-17T13:57:54Z

this is for comparing two traces of tases so you look at a place where they intersect and using the command make the ticks of both tases at the point the same by subtracting some amount of ticks from the slower tas making the bbox be forwarder and aligned with the faster tas
didn't test linux

ThisAMJ · 2026-06-17T14:05:33Z

+ trace_ticks[h.trace_name] = tick;
+	}
+
+	auto fastest_trace = playerTrace->GetTrace(fastest_trace_name);


Unused variables fastest_trace_name, fastest_trace

Krzyhau

Separately handled state for offset sounds weird to me. It should be a part of trace data that gets reset/removed along with the trace itself. In most cases, when you're doing comparisons, the original trace is recorded once.

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

Krzyhau · 2026-06-18T06:29:09Z

+	// Universal map for trace tick offsets to be able to preserve them between trace recordings
+	std::unordered_map<std::string, int> tickOffsets;


You've created extra trace information which is implicitly not cleared when removing traces. I'm not a fan of that and I'd like to know what justifies this choice.

I wanted to make trace offset not get reset if you rerecorded a trace so I needed to store the offsets somewhere that isn't inside the trace itself

Krzyhau · 2026-06-18T06:33:10Z

 	}
 }

+CON_COMMAND(sar_trace_sync, "sar_trace_sync - syncs all the hovered traces to the fastest trace.\n") {


What if we don't want to compare to the trace that's fastest? What if our other traces we're comparing to are faster instead?
I think this feature would be more versatile if you could specify which trace to sync to (that is, sar_trace_sync_all_to [trace_name])

I already implemented this but I guess I forgot to push it

rudkoLA · 2026-06-18T12:36:29Z

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

this was the first thing I implemented but changed it to sync cause i felt I wouldn't need to manually set offset and would just always use sync. also I couldn't find a way to be able to both set offsets and see them I was happy with, the thing I had just used auto complete to show the trace name and offset

rudkoLA · 2026-06-17T13:57:54Z

this is for comparing two traces of tases so you look at a place where they intersect and using the command make the ticks of both tases at the point the same by subtracting some amount of ticks from the slower tas making the bbox be forwarder and aligned with the faster tas
didn't test linux

ThisAMJ · 2026-06-17T14:05:33Z

+ trace_ticks[h.trace_name] = tick;
+	}
+
+	auto fastest_trace = playerTrace->GetTrace(fastest_trace_name);


Unused variables fastest_trace_name, fastest_trace

Krzyhau

Separately handled state for offset sounds weird to me. It should be a part of trace data that gets reset/removed along with the trace itself. In most cases, when you're doing comparisons, the original trace is recorded once.

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

Krzyhau · 2026-06-18T06:29:09Z

+	// Universal map for trace tick offsets to be able to preserve them between trace recordings
+	std::unordered_map<std::string, int> tickOffsets;


You've created extra trace information which is implicitly not cleared when removing traces. I'm not a fan of that and I'd like to know what justifies this choice.

I wanted to make trace offset not get reset if you rerecorded a trace so I needed to store the offsets somewhere that isn't inside the trace itself

Krzyhau · 2026-06-18T06:33:10Z

 	}
 }

+CON_COMMAND(sar_trace_sync, "sar_trace_sync - syncs all the hovered traces to the fastest trace.\n") {


What if we don't want to compare to the trace that's fastest? What if our other traces we're comparing to are faster instead?
I think this feature would be more versatile if you could specify which trace to sync to (that is, sar_trace_sync_all_to [trace_name])

I already implemented this but I guess I forgot to push it

rudkoLA · 2026-06-18T12:36:29Z

Additionally, since you're adding offset anyway, it might be useful to leave a command for explicitly defining it for various purposes. sar_trace_offset [trace_name] [offset]. This would also allow you to keep offset of the trace after re-recording if you wish to constantly re-record comparison traces with offsets for whatever reason.

this was the first thing I implemented but changed it to sync cause i felt I wouldn't need to manually set offset and would just always use sync. also I couldn't find a way to be able to both set offsets and see them I was happy with, the thing I had just used auto complete to show the trace name and offset

add sar_trace_sync
aa5c599

ThisAMJ reviewed Jun 17, 2026
View reviewed changes

clean up code
8d6a362

rudkoLA marked this pull request as draft June 17, 2026 19:49

make offset preserve through trace recording via trace name
299a7f2

rudkoLA marked this pull request as ready for review June 17, 2026 21:11

add trace sync reset commands
50983b7

Krzyhau reviewed Jun 18, 2026
View reviewed changes

add option for specifying main trace
c184e7b

add offset command and clean up
60718d9

rudkoLA changed the title ~~add sar_trace_sync~~add sar_trace_offset* commandsJun 19, 2026

add sar_trace_sync
aa5c599

ThisAMJ reviewed Jun 17, 2026
View reviewed changes

clean up code
8d6a362

rudkoLA marked this pull request as draft June 17, 2026 19:49

make offset preserve through trace recording via trace name
299a7f2

rudkoLA marked this pull request as ready for review June 17, 2026 21:11

add trace sync reset commands
50983b7

Krzyhau reviewed Jun 18, 2026
View reviewed changes

add option for specifying main trace
c184e7b

add offset command and clean up
60718d9

rudkoLA changed the title ~~add sar_trace_sync~~add sar_trace_offset* commandsJun 19, 2026

add sar_trace_sync
aa5c599

ThisAMJ reviewed Jun 17, 2026
View reviewed changes

clean up code
8d6a362

rudkoLA marked this pull request as draft June 17, 2026 19:49

make offset preserve through trace recording via trace name
299a7f2

rudkoLA marked this pull request as ready for review June 17, 2026 21:11

add trace sync reset commands
50983b7

Krzyhau reviewed Jun 18, 2026
View reviewed changes

add option for specifying main trace
c184e7b

add offset command and clean up
60718d9

rudkoLA changed the title ~~add sar_trace_sync~~add sar_trace_offset* commandsJun 19, 2026

add sar_trace_sync
aa5c599

ThisAMJ reviewed Jun 17, 2026
View reviewed changes

clean up code
8d6a362

rudkoLA marked this pull request as draft June 17, 2026 19:49

make offset preserve through trace recording via trace name
299a7f2

rudkoLA marked this pull request as ready for review June 17, 2026 21:11

add trace sync reset commands
50983b7

Krzyhau reviewed Jun 18, 2026
View reviewed changes

add option for specifying main trace
c184e7b

add offset command and clean up
60718d9

rudkoLA changed the title ~~add sar_trace_sync~~add sar_trace_offset* commandsJun 19, 2026

add sar_trace_sync
aa5c599

ThisAMJ reviewed Jun 17, 2026
View reviewed changes

clean up code
8d6a362

rudkoLA marked this pull request as draft June 17, 2026 19:49

make offset preserve through trace recording via trace name
299a7f2

rudkoLA marked this pull request as ready for review June 17, 2026 21:11

add trace sync reset commands
50983b7

Krzyhau reviewed Jun 18, 2026
View reviewed changes

add option for specifying main trace
c184e7b

add offset command and clean up
60718d9

rudkoLA changed the title ~~add sar_trace_sync~~add sar_trace_offset* commandsJun 19, 2026

add sar_trace_sync
aa5c599

ThisAMJ reviewed Jun 17, 2026
View reviewed changes

clean up code
8d6a362

rudkoLA marked this pull request as draft June 17, 2026 19:49

make offset preserve through trace recording via trace name
299a7f2

rudkoLA marked this pull request as ready for review June 17, 2026 21:11

add trace sync reset commands
50983b7

Krzyhau reviewed Jun 18, 2026
View reviewed changes

add option for specifying main trace
c184e7b

add offset command and clean up
60718d9

rudkoLA changed the title ~~add sar_trace_sync~~add sar_trace_offset* commandsJun 19, 2026

add sar_trace_sync
aa5c599

ThisAMJ reviewed Jun 17, 2026
View reviewed changes

clean up code
8d6a362

rudkoLA marked this pull request as draft June 17, 2026 19:49

make offset preserve through trace recording via trace name
299a7f2

rudkoLA marked this pull request as ready for review June 17, 2026 21:11

add trace sync reset commands
50983b7

Krzyhau reviewed Jun 18, 2026
View reviewed changes

add option for specifying main trace
c184e7b

add offset command and clean up
60718d9

rudkoLA changed the title ~~add sar_trace_sync~~add sar_trace_offset* commandsJun 19, 2026

add sar_trace_sync
aa5c599

ThisAMJ reviewed Jun 17, 2026
View reviewed changes

clean up code
8d6a362

rudkoLA marked this pull request as draft June 17, 2026 19:49

make offset preserve through trace recording via trace name
299a7f2

rudkoLA marked this pull request as ready for review June 17, 2026 21:11

add trace sync reset commands
50983b7

Krzyhau reviewed Jun 18, 2026
View reviewed changes

add option for specifying main trace
c184e7b

add offset command and clean up
60718d9

rudkoLA changed the title ~~add sar_trace_sync~~add sar_trace_offset* commandsJun 19, 2026

		// Universal map for trace tick offsets to be able to preserve them between trace recordings
		std::unordered_map<std::string, int> tickOffsets;

Uh oh!

Uh oh!

Conversation

rudkoLA commented Jun 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Krzyhau left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rudkoLA commented Jun 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

rudkoLA commented Jun 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Krzyhau left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rudkoLA commented Jun 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

rudkoLA commented Jun 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Krzyhau left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rudkoLA commented Jun 18, 2026

Uh oh!

Reviewers

rudkoLA commented Jun 17, 2026•
edited
Loading

rudkoLA commented Jun 17, 2026•
edited
Loading

rudkoLA commented Jun 17, 2026•
edited
Loading

rudkoLA commented Jun 17, 2026•
edited
Loading