Thread: LUNA: A new step into the unknown of scripts

It is not possible to know how the scripts of the luna are compiled, they can as well generated from a converter like JigoLUA or directly converted by the application which compiles the apk, I know one thing is that jigolua decompiles the lua in a way that recompiling may deviate slightly from the original file. the decryption obtained by a third party software may seem correct but the interpretation by iGO may not work, the binary interpreter and the text interpreter integrated in iGO may not be 100% compatible with each other.

as one can imagine attributing a string to a boolean can become functional with an implicit transcryption at the binary level but which must be specified when using a clear text

The main goal is to get as close as possible to a functional clear code while taking into account what iGO wants to digest, it always starts by adding control points slipped into the scripts to understand its reactions to certain syntaxes, which is not always obvious because sometimes we go to a haircut of the solution.

Edit:
After a return in different versions, it turns out that the function described as falling under a widestring is in fact a boolean, we find the same line in the address.lua of Primo where it is less complicated to display a simple dialogue
sc_InfoMessageBox(type(MODEL.address.search.support_streetsearch_in_state(AddressSearchResult.selectedCountry)),1)
returns a boolean type as expected, so no modification needs to be made at this level

from primo and nextgen on a better idea of the good formulation,

Code:

Please Login or Register to see the links

by taking and adapting various elements leading to AddressSearchResult.selectedCountry it should end up running correctly in iqs.lua

maybe in this form ?

Code:

Please Login or Register to see the links

for the moment the decryption of the diferent versions still seems to hold water because I have no feedback concerning badly decrypted code, it seems that it is only for the moment bad programming at the base

Originally Posted by lunapark

for the moment the decryption of the diferent versions still seems to hold water because I have no feedback concerning badly decrypted code, it seems that it is only for the moment bad programming at the base

Indeed, no problems (anymore) with the decrypted code! The problems are in the compiled LUA and/or the libigo_ini.so for Igo Luna. Neither of classic_search or VR work in Luna and are actually not used (VR uses "onebox-vr"). Everything moved to OneBox search (hg_search, onebox_vr). Classic search (MODEL.address.search.<function>) crashes (country search works, but city or street crashes). Luna content files/structure is quite different and thus required changes in the back-end. Some things have been modified (e.g. support_streetsearch_in_state) but since the front-end is no longer used it was not adapted. I even used LUA techniques to overload "support_streetsearch_in_state" with my own code to take a country as argument while using the original, compiled "address.lua". As a result this function now works but it still crashes when searching for a city when using "classic_search". Will take one more look at IQS, there are some changes in the LUA there...

EDIT: As expected IQS does not work with iGO Luna. It uses yet another search engine (MODEL.address.multi) but again the city search is crashing.

Adding as attachment the new decoded lua files from the last version İgo Basarsoft Nextgen 9.35.2.262743 (2021.08.31)

regarding lua files: really nothing new
no changes compared to version 9.35.2.252374 (this Topic #3), only some ux were simply removed


while waiting for a debridged apk version, the original files can be downloaded at this [Only registered and activated users can see links. ] ozut