- Welcome to Locus Map - forum.
Locus Map - forum
Recent posts
#1
Troubles & Questions / Re: LoMaps mixing up
Last post by freischneider - Today at 11:58:15Are all the cards up to date? Please check their status in the store.
#2
Troubles & Questions / LoMaps mixing up
Last post by Andreatrst - Today at 11:15:15With Locus 4.33 (Silver), running on a Samsung device, different maps are overlapped/displayed simultaneously, depending on the zoom. I only use LoMaps offline maps.
#3
[CZ&SK] - diskuze o Locusu / Re: Plánování trasy.
Last post by Joska 000 - Today at 10:38:19Bohužel toto zatržítko tam nemám. verze 4.32.4+auto
#4
Locus Map / Re: Re: [APP] - version 4.33.+...
Last post by WildWortWechsel - Today at 10:31:42Hi menion,
thank you! I'll answer your questions between the lines.
Regards, Dieter.
Auto-hide is enabled.
You should have got the bug report yesterday.
Figured out these are the hill tops. See screenshot.
Edit: After a restart the original hill top icons are back.
Indeed, I have online map here. But I have all the maps downloaded also. Take a look at the photo: left side my old Nokia XR20 with 4.33.0.0. and at the right side the Pixel 10 pro XL with 4.33.0.10. Same settings. Maps does not fully load.
thank you! I'll answer your questions between the lines.
Regards, Dieter.
Quote from: Menion on Yesterday at 14:08:47@WildWortWechsel
missing buttons - it mean that the zoom & centre buttons are lost when you rotate the screen? Have you enabled the auto-hide option?
Auto-hide is enabled.
Quotestuck at start > hmm, unfortunate. Next time, open the list of recently started apps (third button in the bottom navigation panel) and swipe out the Locus Map completely. Anyway, how to solve it? Post a bug report after this happens next time (long click on the main app menu after start). Thanks.
You should have got the bug report yesterday.
Quotedefault point icons > hmm, any what icons are defined for a points, that now use this "default" icon? Do the have own valid icon?
Figured out these are the hill tops. See screenshot.
Edit: After a restart the original hill top icons are back.
Quotemap > you are zoomed quite a lot. Please check app settings > maps > Advanced > World map. Maybe you have defined online map here?
Indeed, I have online map here. But I have all the maps downloaded also. Take a look at the photo: left side my old Nokia XR20 with 4.33.0.0. and at the right side the Pixel 10 pro XL with 4.33.0.10. Same settings. Maps does not fully load.
#5
Locus Map / Re: Re: [APP] - version 4.33.+...
Last post by Gerhard57 - Today at 09:55:44Quote from: Tapio on April 20, 2026, 18:01:16I see, indeed, dotted style is a bit weird. Especially, the selected version uses the configured (but greyed out) pattern.dotted style is totally different to Line: transparten Pattern: dots
Additional weirdness, the pattern selector already has an entry "dotted", but they're squares. However I'd argue dotted style should just be done this old way: Line: transparent, Pattern: dots
dotted style shows a dot for every recorded trackpoint and NOT a dotted line betwwen trackpoints. See screenshots
#6
Developers / Re: Can a LM Add-on be used to...
Last post by hoschilo - Today at 09:28:22Hi Menion,
Thank you for your response! Let me explain what I've actually already built.
I own a Rotwild e-bike with a Brose motor. I reverse-engineered the proprietary BLE protocol (GIGATRONIK/TCU1) that the Qore/Brose app uses to communicate with the bike.
My Android app runs on my main/daily phone, reads the live telemetry from the Central Display (speed, cadence, battery, assist level, rider power, motor power), and then emulates a Specialized Levo GATT server toward Locus Map running on a second phone which is only used for navigation wiht locus maps.
Locus already has built-in support for "Specialized E-Bike" sensors — so my app essentially pretends to be the real bike hardware. It works surprisingly well: Locus connects, subscribes, and displays battery, assist mode, cadence and power in real time.
So I'm not looking so far to publish a Play Store add-on — I just want my own setup to work reliably. But this experience made me think about how a proper API could work for the broader community.
From my reverse-engineering I found that even a single motor brand (Brose) uses mixed data formats: simple fixed-size values (uint8 for battery %, cadence, assist level; uint16 LE for speed and power) but also Protocol Buffers (Protobuf) for more complex telemetry like estimated range, trip odometer, voltage and calculated motor power.
Other brands (Bosch, Shimano, Yamaha) will have completely different protocols and even different semantics — for example assist levels: Brose uses 0–4, Bosch uses named modes (Eco/Tour/Sport/Turbo), Shimano again differently. So a good API should treat all fields as optional/nullable and represent assist as a generic integer 0–N plus an optional label string.
A reasonable base set of fields would be: battery_percent (int), assist_level (int + optional string label), speed (float, km/h), cadence (int, RPM), rider_power (int, W), motor_power (int, W), estimated_range (float, km), trip_distance (float, km), battery_voltage (float, V).
The cleanest solution would be a plugin/adapter model: Locus provides the stable API with these fields, and the community writes small adapter apps that know the specific bike protocol and translate into the Locus format. Similar to how Garmin Connect IQ works, or OBD2 adapters. My "EBikeLocus" app could essentially be the first such community adapter and serve as a reference implementation.
One of the biggest challenges is that reverse-engineering a proprietary BLE protocol is very time-consuming. It would be extremely valuable to have a tool — perhaps even built into Locus or as a companion app — that captures raw BLE notifications and lets the user interactively assign data types to byte ranges (uint8, uint16 LE/BE, int16, float, with offset and scale factor) until the values make sense. Something like a visual BLE packet parser. This would dramatically lower the barrier for users to map their own bike's protocol without needing deep technical knowledge. The main limitation is Protobuf-based protocols, which are harder to decode without the schema — but for simpler fixed-byte protocols it would work very well.
If you're planning to extend the API in that direction, I'd be very happy to share my detailed findings about the Brose/Qore protocol and collaborate on defining the API fields.
Best regards
Thank you for your response! Let me explain what I've actually already built.
I own a Rotwild e-bike with a Brose motor. I reverse-engineered the proprietary BLE protocol (GIGATRONIK/TCU1) that the Qore/Brose app uses to communicate with the bike.
My Android app runs on my main/daily phone, reads the live telemetry from the Central Display (speed, cadence, battery, assist level, rider power, motor power), and then emulates a Specialized Levo GATT server toward Locus Map running on a second phone which is only used for navigation wiht locus maps.
Locus already has built-in support for "Specialized E-Bike" sensors — so my app essentially pretends to be the real bike hardware. It works surprisingly well: Locus connects, subscribes, and displays battery, assist mode, cadence and power in real time.
So I'm not looking so far to publish a Play Store add-on — I just want my own setup to work reliably. But this experience made me think about how a proper API could work for the broader community.
From my reverse-engineering I found that even a single motor brand (Brose) uses mixed data formats: simple fixed-size values (uint8 for battery %, cadence, assist level; uint16 LE for speed and power) but also Protocol Buffers (Protobuf) for more complex telemetry like estimated range, trip odometer, voltage and calculated motor power.
Other brands (Bosch, Shimano, Yamaha) will have completely different protocols and even different semantics — for example assist levels: Brose uses 0–4, Bosch uses named modes (Eco/Tour/Sport/Turbo), Shimano again differently. So a good API should treat all fields as optional/nullable and represent assist as a generic integer 0–N plus an optional label string.
A reasonable base set of fields would be: battery_percent (int), assist_level (int + optional string label), speed (float, km/h), cadence (int, RPM), rider_power (int, W), motor_power (int, W), estimated_range (float, km), trip_distance (float, km), battery_voltage (float, V).
The cleanest solution would be a plugin/adapter model: Locus provides the stable API with these fields, and the community writes small adapter apps that know the specific bike protocol and translate into the Locus format. Similar to how Garmin Connect IQ works, or OBD2 adapters. My "EBikeLocus" app could essentially be the first such community adapter and serve as a reference implementation.
One of the biggest challenges is that reverse-engineering a proprietary BLE protocol is very time-consuming. It would be extremely valuable to have a tool — perhaps even built into Locus or as a companion app — that captures raw BLE notifications and lets the user interactively assign data types to byte ranges (uint8, uint16 LE/BE, int16, float, with offset and scale factor) until the values make sense. Something like a visual BLE packet parser. This would dramatically lower the barrier for users to map their own bike's protocol without needing deep technical knowledge. The main limitation is Protobuf-based protocols, which are harder to decode without the schema — but for simpler fixed-byte protocols it would work very well.
If you're planning to extend the API in that direction, I'd be very happy to share my detailed findings about the Brose/Qore protocol and collaborate on defining the API fields.
Best regards
#7
[DE] - deutschsprachiger Forumsbereich / Re: Fehler, Fehler, Fehler, .....
Last post by WRPSoft - Today at 08:48:02Hallo Zusammen,
Ich möchte mich hier gar nicht größer einbringen, weil ich Locus Map zu selten nutze (eigentlich nur zum Wandern, primär nutze ich GPS-Sportuhren und -Bikecomputer) und daher sicherlich einen sehr subjektiven und eher unkritischen Blickwinkel habe. Das meiste was ich mit Locus Map mache, funktioniert - allen Unkenrufen zum Trotz- bei mir recht stabil (ich nutze Locus Map aber auch nur in seinen Grundfunktionen).
Aber als Softwareentwickler kann ich die Probleme vielleicht etwas einstufen. Menion hat es ja bereits sehr direkt angesprochen, dass das Locus Map Projekt sehr alt ist und daher sicherlich viel Code auch historisch gewachsen ist. Die Umschreibung historisch gewachsen kennt sicherlich jeder Softwareentwickler (und auch viele User).
Man will das zwar immer verhindern, aber irgendwann hat dann doch (fast) jedes Softwareprojekt jenen Status erreicht, in dem Altlasten den Takt vorgeben. Man fängt dann an, alten Code neu auszurichten (besser/schöner umzuprogrammieren) und irgendwann hat man dann viele neue Nebenbaustellen.
Bei Android kommt erschwerend hinzu, dass Locus mittlerweile sicherlich gegen die ein oder andere Deprecated-Falle anzukämpfen hat. Android ist ja nach wie vor ein relatives junges OS und Google hat leider überhaupt keine Hemmungen, Altlasten mit der Zeit als depcrated einzustufen.
Irgendwann kommt man dann nicht umhin, am Code größere Anpassungen vorzunehmen, weil Google die APIs grundlegend umbaut und die Entwickler zwingt, den Code anzupassen, wenn man die App weiterhin im Google Play Store anbieten will.
Nutzt man dann noch externe Libraries, wie das bei Locus - und fast allen komplexeren Apps - ja der Fall ist, dann muss man mitunter sehr tief ins System eingreifen und Code anpacken und umbauen, der jahrelang stabil funktioniert hat. Wenn es schlecht läuft, dann muss man einige der genutzten Libraries austauschen, weil sie nicht mehr aktualisiert wurden oder ebenfalls grundlegend neu programmiert wurden.
Menion hat zumindest einiges in dieser Richtung anklingen lassen.
Natürlich kann man sich unter dieser Prämisse, die ja mehr oder weniger von Außen vorgegeben wird, fragen, ob es dann Sinn macht, parallel zuviel neue Funktionalität aufzugreifen und nicht besser den alten Code erst mal gesund zu migrieren, um erst einmal eine stabile Adaption zu haben, die dann erst im nächsten Schritt ausgebaut wird. Da kämpft dann häufig die Theorie gegen die Praxis an und vice versa.
Fakt ist, wenn man sowieso am Unterbau dran ist, dann macht es hin- und wieder schon Sinn, gleich Neuerungen aufzugreifen, weil man neu Klassen baut oder Alte grundlegend umgestaltet und dann viele zukünftige Schnittstellen/Funktionen schon berücksichtigt werden sollten. Sonst hat man das Problem, dass man sehr schnell wieder an einem historisch gewachsenen Code laboriert, weil man zu wenig vorauschauend entwickelt hat und das neue Geschäftsmodell natürlich auch Anreize beim User generieren muss, das neue Geschäftsmodell überhaupt zu unterstützen.
Denn mal ehrlich, wenn Locus Map 4 nur eine fehlerbereinigende und an neue API Vorgaben angepasste Version wäre, dann würden viele Altkunden auf die Barrikaden gehen. Bereits bei der Umstellung des Geschäftsmodells gab es im Locus Map Blog zumindest einige sehr unfreundliche Kommentare.
Ich denke, das ist ein großer Spagat, den Menion und seine Truppe hinlegen müssen. Und ja, seine Firma ist nicht MS, nicht Apple, nicht Google, nicht Adobe und wie die Großen alle heißen. Manpower ist demnach begrenzt und die genannten Firmen sind ja auch ein gutes Beispiel dafür, dass selbst Manpower alleine nicht genügt (fast jedes größere OS Update der oben genannten mutiert ja mittlerweile zu einem Bingo Spiel).
Selbst gut gewartete Software lebt und genauso wie wir Menschen hin und wieder krank werden und einen Doktor benötigen, ist das bei Softwareprojekten nichts anders. Und nicht jeder ärztliche Eingriff ist immer erfolgreich, manchmal braucht es auch etwas Geduld, um wieder 100% gesund zu werden.
PS: Hier wurde das mangelende Qualitätsmanagement angeprangert. Ich bin seit > 25 Jahren in der prof. Softwareentwicklung tätig und es gibt wirklich wenige Bereiche, wo es mit dem Qualitätsmanagement immer gut funktioniert (medizinischer Bereich, Aeronautik, etc.). Das soll keine Entschuldigung sein, aber so ehrlich sollte man dann doch sein...
Quote from: Christian on Today at 00:20:05Danke @Menion für Deine Beteiligung und Deine Offenheit.
Ich möchte meine Emotionen hier im Thread ein wenig differenzieren.
Ich bin wegen der Ignoranz hier im Thread ziemlich verärgert. Das ist für mich nicht tolerierbar. Es hilft Dir nicht, der App nicht, uns allen nicht.
Ich bin von der App enttäuscht: die strategische Ausrichtung gefällt mir nicht (zu viele Baustellen (auch iOS, Webplanner, Android Auto...), zuviel Hickhack, nicht zu Ende programmiert, zu komplex*, zu viele Fehler). Ich glaube, Du planst die Arbeitslast für Asamm Global Enterprise, bist aber nur zu zweit.
Ich möchte mich hier gar nicht größer einbringen, weil ich Locus Map zu selten nutze (eigentlich nur zum Wandern, primär nutze ich GPS-Sportuhren und -Bikecomputer) und daher sicherlich einen sehr subjektiven und eher unkritischen Blickwinkel habe. Das meiste was ich mit Locus Map mache, funktioniert - allen Unkenrufen zum Trotz- bei mir recht stabil (ich nutze Locus Map aber auch nur in seinen Grundfunktionen).
Aber als Softwareentwickler kann ich die Probleme vielleicht etwas einstufen. Menion hat es ja bereits sehr direkt angesprochen, dass das Locus Map Projekt sehr alt ist und daher sicherlich viel Code auch historisch gewachsen ist. Die Umschreibung historisch gewachsen kennt sicherlich jeder Softwareentwickler (und auch viele User).
Man will das zwar immer verhindern, aber irgendwann hat dann doch (fast) jedes Softwareprojekt jenen Status erreicht, in dem Altlasten den Takt vorgeben. Man fängt dann an, alten Code neu auszurichten (besser/schöner umzuprogrammieren) und irgendwann hat man dann viele neue Nebenbaustellen.
Bei Android kommt erschwerend hinzu, dass Locus mittlerweile sicherlich gegen die ein oder andere Deprecated-Falle anzukämpfen hat. Android ist ja nach wie vor ein relatives junges OS und Google hat leider überhaupt keine Hemmungen, Altlasten mit der Zeit als depcrated einzustufen.
Irgendwann kommt man dann nicht umhin, am Code größere Anpassungen vorzunehmen, weil Google die APIs grundlegend umbaut und die Entwickler zwingt, den Code anzupassen, wenn man die App weiterhin im Google Play Store anbieten will.
Nutzt man dann noch externe Libraries, wie das bei Locus - und fast allen komplexeren Apps - ja der Fall ist, dann muss man mitunter sehr tief ins System eingreifen und Code anpacken und umbauen, der jahrelang stabil funktioniert hat. Wenn es schlecht läuft, dann muss man einige der genutzten Libraries austauschen, weil sie nicht mehr aktualisiert wurden oder ebenfalls grundlegend neu programmiert wurden.
Menion hat zumindest einiges in dieser Richtung anklingen lassen.
Natürlich kann man sich unter dieser Prämisse, die ja mehr oder weniger von Außen vorgegeben wird, fragen, ob es dann Sinn macht, parallel zuviel neue Funktionalität aufzugreifen und nicht besser den alten Code erst mal gesund zu migrieren, um erst einmal eine stabile Adaption zu haben, die dann erst im nächsten Schritt ausgebaut wird. Da kämpft dann häufig die Theorie gegen die Praxis an und vice versa.
Fakt ist, wenn man sowieso am Unterbau dran ist, dann macht es hin- und wieder schon Sinn, gleich Neuerungen aufzugreifen, weil man neu Klassen baut oder Alte grundlegend umgestaltet und dann viele zukünftige Schnittstellen/Funktionen schon berücksichtigt werden sollten. Sonst hat man das Problem, dass man sehr schnell wieder an einem historisch gewachsenen Code laboriert, weil man zu wenig vorauschauend entwickelt hat und das neue Geschäftsmodell natürlich auch Anreize beim User generieren muss, das neue Geschäftsmodell überhaupt zu unterstützen.
Denn mal ehrlich, wenn Locus Map 4 nur eine fehlerbereinigende und an neue API Vorgaben angepasste Version wäre, dann würden viele Altkunden auf die Barrikaden gehen. Bereits bei der Umstellung des Geschäftsmodells gab es im Locus Map Blog zumindest einige sehr unfreundliche Kommentare.
Ich denke, das ist ein großer Spagat, den Menion und seine Truppe hinlegen müssen. Und ja, seine Firma ist nicht MS, nicht Apple, nicht Google, nicht Adobe und wie die Großen alle heißen. Manpower ist demnach begrenzt und die genannten Firmen sind ja auch ein gutes Beispiel dafür, dass selbst Manpower alleine nicht genügt (fast jedes größere OS Update der oben genannten mutiert ja mittlerweile zu einem Bingo Spiel).
Selbst gut gewartete Software lebt und genauso wie wir Menschen hin und wieder krank werden und einen Doktor benötigen, ist das bei Softwareprojekten nichts anders. Und nicht jeder ärztliche Eingriff ist immer erfolgreich, manchmal braucht es auch etwas Geduld, um wieder 100% gesund zu werden.
PS: Hier wurde das mangelende Qualitätsmanagement angeprangert. Ich bin seit > 25 Jahren in der prof. Softwareentwicklung tätig und es gibt wirklich wenige Bereiche, wo es mit dem Qualitätsmanagement immer gut funktioniert (medizinischer Bereich, Aeronautik, etc.). Das soll keine Entschuldigung sein, aber so ehrlich sollte man dann doch sein...
#8
[DE] - deutschsprachiger Forumsbereich / Re: Fehler, Fehler, Fehler, .....
Last post by Tapio - Today at 08:24:13Danke Christian. Was heißt schon "Ignoranz" - für mich persönlich und bei meiner Nutzungsweise funktioniert die App gut. Will meinen, ich habe keinen Bedarf, einen hohen Aufregungspegel zu erreichen. Ist einfach nicht vorhanden. Dass Menion zu viel auf einmal anfasst und nicht alles zuende bringt, sehe ich. Ich schreibe dann (z. B. was die Fotos im Trackpanel angeht) was ich meine, das dringend ist und fehlt, dies aber nur einmal, denn ich sehe, dass die Arbeitslast sicher groß ist.
Ich kannte die IT eines großen DAX-Konzerns, Pharma, sehr gut. 10 Jahre her. 10% MACHEN und/oder können. Die, die nicht so gut können bzw. Karriere machen wollten, mit ITIL und anderem Gedöns, das waren vllt. 90% der Belegschaft. Kein Scheiß: ich bin ernsthaft mal gefragt worden, wie lang die Fertigstellung einer beauftragten Software im Durchschnitt dauern würde. Diejenige/ITIL brauchten einfach schwachsinnige Zahlen weil man daran SLAs ausrichtet. Großunternehmen insgesamt: wir würden eher Komoot bekommen - gut auditiert - aber definitiv kein Locus Maps. Wenn ich etwas hassen würde ist es diese corporate Idiotenwelt voller Schwachsinn, Zwänge, Luftpumpen. Ohhhh... ATMEN 😁 Ich bin da raus. Bin absolut unauffällig und unbedeutend heute. Verwaltungskraft in Personalangelegenheiten. Papier, Akten, wie ein Stromberg im Keller.
Leute, die meine Ideen Vorgesetzten als ihre präsentieren, Kollegen, die, da der Wind sich drehte, sich auf widerliche Art abwenden ("das habe ich auch nie verstanden, warum Herr Tapio das so machte") und Du plötzlich alleine dastehst - tja, das haben sicher einige erlebt. Sorry für mein OffT.
Du schriebst "Du bist ziemlich straight forward mit viel Willen, wenig Geduld, immer in Eile, manchmal auch mit der Brechstange. Das macht manchmal schlechte Umgangsformen" - habe ich ehrlich nie erlebt. Menion schreibt wohl mal "nein, wird es nicht geben, danke fürs Verständnis", aber da muss man durch.
Komoot-Nutzer, Apple-Nutzer... begrenztes Feature-Set, das ist eben der einfache Weg, den viele gerne gehen. Spezieller Bedarf entsteht erst gar nicht. Es wird genommen, was man bekommt, das ist Gesetz. Ich erschrecke mich nicht mehr darüber, dass es Leute gibt, die jahrelang irgendwelche Funktionen nicht nutzen, die sie theoretisch in Programmoptionen hätten einschalten können. Die Herangehensweise "einfach mal nachgucken" existiert gar nicht. Man nimmt, was man ganz vorne vorfindet. Also, es wundert mich da gar nichts.
Ich kannte die IT eines großen DAX-Konzerns, Pharma, sehr gut. 10 Jahre her. 10% MACHEN und/oder können. Die, die nicht so gut können bzw. Karriere machen wollten, mit ITIL und anderem Gedöns, das waren vllt. 90% der Belegschaft. Kein Scheiß: ich bin ernsthaft mal gefragt worden, wie lang die Fertigstellung einer beauftragten Software im Durchschnitt dauern würde. Diejenige/ITIL brauchten einfach schwachsinnige Zahlen weil man daran SLAs ausrichtet. Großunternehmen insgesamt: wir würden eher Komoot bekommen - gut auditiert - aber definitiv kein Locus Maps. Wenn ich etwas hassen würde ist es diese corporate Idiotenwelt voller Schwachsinn, Zwänge, Luftpumpen. Ohhhh... ATMEN 😁 Ich bin da raus. Bin absolut unauffällig und unbedeutend heute. Verwaltungskraft in Personalangelegenheiten. Papier, Akten, wie ein Stromberg im Keller.
Leute, die meine Ideen Vorgesetzten als ihre präsentieren, Kollegen, die, da der Wind sich drehte, sich auf widerliche Art abwenden ("das habe ich auch nie verstanden, warum Herr Tapio das so machte") und Du plötzlich alleine dastehst - tja, das haben sicher einige erlebt. Sorry für mein OffT.
Du schriebst "Du bist ziemlich straight forward mit viel Willen, wenig Geduld, immer in Eile, manchmal auch mit der Brechstange. Das macht manchmal schlechte Umgangsformen" - habe ich ehrlich nie erlebt. Menion schreibt wohl mal "nein, wird es nicht geben, danke fürs Verständnis", aber da muss man durch.
Komoot-Nutzer, Apple-Nutzer... begrenztes Feature-Set, das ist eben der einfache Weg, den viele gerne gehen. Spezieller Bedarf entsteht erst gar nicht. Es wird genommen, was man bekommt, das ist Gesetz. Ich erschrecke mich nicht mehr darüber, dass es Leute gibt, die jahrelang irgendwelche Funktionen nicht nutzen, die sie theoretisch in Programmoptionen hätten einschalten können. Die Herangehensweise "einfach mal nachgucken" existiert gar nicht. Man nimmt, was man ganz vorne vorfindet. Also, es wundert mich da gar nichts.
#9
Locus Map / Re: Re: [APP] - version 4.33.+...
Last post by Andrew Heard - Today at 07:33:57Quote from: Menion on Yesterday at 14:08:47crash after search > may you please record a short video for me? I can't simulate the problem and need to verify what do you see and what exactly you tap. Thanks!I installed a screen recorder, and after a few attempts for online search, it now isn't crashing, oh well
Quote from: Menion on Yesterday at 14:08:47slope coloring > hmmmit wouldn't have to have varying coloring; I think the Web Planner simply has more logical presentation of +/-% slope
#10
Locus Map / Re: Re: [APP] - version 4.33.+...
Last post by Andrew Heard - Today at 07:15:20Quote from: Graf Geo on Today at 00:23:17However, in edit mode, it only shows the section from A to B.confirmed