Mutual GNU / Linux


uiWebPrevious1234uiWebNext

#42 [en] 

There is a lot of stuff in between the parts I already posted. Most of it seems to match logging generated by a working executable, specifically the one found here.

The only other lines that appear to have potential relevance are:
2015/08/02 21:49:56 <Unknown> INF e689a740 common.cpp 615 : Exception will be launched: interaction.lua:134: attempt to call field 'mod' (a nil value)
2015/08/02 21:49:56 <Unknown> WRN e689a740 interface_parser.cpp 2863 : ELuaExecuteError: interaction.lua:134: attempt to call field 'mod' (a nil value)
2015/08/02 21:49:56 <Unknown> ERR e689a740 interface_parser.cpp 587 : could not parse 'lua'

#43 [en] 

Abekomdf (atys)
The only other lines that appear to have potential relevance are:
Exception will be launched: interaction.lua:134: attempt to call field 'mod' (a nil value)
have you updated ryzom files using ryzom_update.sh script? it also overwrites ryzom_client binary, so you need to restore it if your own compiled version is named the same

---

Hello!

#44 [en] 

I placed Icus's executable and mine in the same location where the original 32bit client had been extracted. I ran each and compared the logs. There were no updates in between that comparison.

#45 [en] 

Abekomdf (atys)
I placed Icus's executable and mine in the same location where the original 32bit client had been extracted. I ran each and compared the logs. There were no updates in between that comparison.

There should be ryzom_update.sh script.

If it's missing, then this is what it contains
rsync -rtzv --progress --stats www.ryzom.com::ryzom ./

---

Hello!

#46 [en] 

I think we are failing to communicate here.

My system is a nice new Debian 8.1 (Jessie) amd64. It can not run the 32 bit ryzom binary that the ryzom_update.sh pulls.

I built close to 30 different binary configurations involving controlling specific library versions, combinations of static/dynamic linking, and 4 different branches of ryzomcore. They ALL crashed at the same place with the same message.

I tried the binary posted by Icus that I referenced earlier and it ran fine.

The problem is something difference in how I am building the binaries or specific libraries and that is what I am looking for help on.

#47 [en] 

Abekomdf (atys)
The problem is something difference in how I am building the binaries or specific libraries and that is what I am looking for help on.
run the updater.

---

Hello!

#48 [en] 

Did it, got more files patched when I ran a ryzom binary. My build still crashes at the same loading step. This time it didn't output the fancy nel_log with all the extra data. I compared log.log for runs by my current build and Icus's and found they were the same up to the crash. The last messages in the crashing log are different than before the update:
2015/08/03 07:18:30 WRN 2029074240 <Unknown> path.cpp 579 lookup : PATH: File (r2_entry_points.txt) not found (r2_entry_points.txt)
2015/08/03 07:18:30 INF 2029074240 <Unknown> common.cpp 615 Exception : Exception will be launched: Path not found for r2_entry_points.txt

#49 [en] 

Abekomdf (atys)
2029074240 <Unknown> path.cpp 579 lookup : PATH: File (r2_entry_points.txt) not found (r2_entry_points.txt)

You running binary from 'default' branch it seems.

I believe creating empty file with that name under 'user' directory should get thru that error. 'compatibility' branch (and ryzom files) has that file named as 'ring_map_entry_ponts.txt'

---

Hello!

#50 [en] 

That binary was built from the "develop" branch. Specifically by downloading the source at https://bitbucket.org/ryzom/ryzomcore/get/5c9146c667c1.zip

The problem is most likely a memory corruption caused by different library builds having a sizing difference.

I have since managed to stick another monkey wrench into this system. It always happens when I am working with a new system. So I can't build anything else for testing until I go through reinstalling all of it. See you in a few days.

#51 [fr] 

If you create an empty file called r2_entry_points.txt in the ryzom/user directory, that problem will go away.

#52 [en] 

Karu was right about the problem being the branch I had selected. I was able to get the "compatibilty" branch to build in my new setup and it ran correctly. I then spent some time researching the differences and was able to build from nimetu's fork with the compatibilty changes manually merged.

That combination gives me a nice snappy client without the libwww crap. I reduced the dynamic libraries down to just a few that would seem to be present on any linux system. The size is a bit smaller than Icus's build which seemed to be from the same fork and merge method. I would attribute that to building all the libraries for it from scratch with options that remove extra sections. There are even a few more protocols I could eliminate from libcurl.

After I spend a fair bit of time testing it in game I will post a full shell script to get and build everything.

#53 [en] 

Abekomdf (atys)
That combination gives me a nice snappy client without the libwww crap

There is compatibility-develop branch that tracks develop more closely and has libwww removed.

---

Hello!

#54 [en] 

I didn't see anyone mention the following, and I might have missed it, but did you install the 32-bit architecture?

dpkg --add-architecture i386

Just asking

---

I need me a new tag line on my messages!

#55 [en] 

Had some issues with rystart on manjaro, for some reason (I suspect that I don't have the specific python 3.8 parts installed) the installer script could not populate the game directory with the client & updater (" could not find ... ryzom_client_patcher" )

Downloading https://download.ryzom.com/client_linux64.zip  and extracting it in the right location (/home/{username}/.local/share/Ryzom/ryzom_live/) solved this for me. Hope it helps :)

Edited 2 times | Last edited by Aina (2 years ago)

uiWebPrevious1234uiWebNext
 
Last visit Wednesday, 27 November 21:11:05 UTC
P_:G_:PLAYER

powered by ryzom-api