I have mentioned both of these problems on this list previously and did receive some answers. The 2 issues continue and I struggle to find a solution.
The two issues are:
#1. The parameter in the region ini file of defaultlanding apparently does nothing at all. The setting of a landing point in aboutland only works if you have the option of “landingpoint” selected but if you have “anywhere” selected, when using the map, you go to where the “location” coordinates send you. They always default to 128,128,x in the MAP window. The x does vary from region to region.
To me it would make sense for the setting of a landing point in about land or using the defaultlanding parameter would allow the MAP search function to reflect that setting. It does not.
The same is true for doing a login to a location using the location name in the viewer for that login option. It always sends you to location 128,128,x unless you have the region set to “landingpoint” and not “anywhere”. Again the use of setting a landing point in about land or using the parameter in the region INI does nothing.
I believe it all points to where the landing point is actually saved by these two functions. Where ever it is it does not affect what a login or the map uses as the predetermined landing point. opensim always loads the value of 128,128,x in both cases.
I understand the map function is part of opensim since it works on the standalone mode right out of the box. On my standalone the exact same problem is duplicated. In the MAP search function the location is always set to be 128, 128, x. (This is the location you see in the bottom right hand corner of the MAP window.)
A LM works correctly to these regions and if “anywhere” is set the LM will take you to where the LM points, but if “landingpoint” is the option of the region then an LM will drop you at the landing point and not where it point. This is exactly how one would expect it to work.
Using the MAP and login are messed up. Is it totally impossible for this to be fixed in opensim? If all it takes is a mantis to get it fixed I will be happy to document it as clearly as I possible can and submit one, but I believe the devs already know of the issue and so maybe it is just impossible to fix?
#2. I continue to have significant issues with doing a TP between my regions because of a timeout after doing the TP. The viewer closed and the opensim log window shows the region never received a response so closed the connection which explains the viewer closing. I do arrive and sometimes actually see the region starting to rez before the viewer closes.
Other people do not have this problem. It has to do with being on my local LAN. Someone TP’ing from outside works just fine most of the time. I can usually avoid the crash by first going to the OSgrid LBSA region and then back to my region I wish to go to. That works about 90% of the time for me.
I have tried and tried to discover why there is no response received to no success. I have discovered a hard reset to my router might clear this issue for a few days so something is getting messed up in the router. Yes, I have tried several different routers, all supporting loopback and yet this same problem occurs.
It has happened with Spectrum ISP which used a cable modem and my router. With Frontier ISP which uses their Actiontec modem/router combination which does not support loopback in their router but rather upstream at their headend. That is why it is reported that opensim works with the Verizon/Frontier Actiontec router. In fact that modem does NOT support loopback at all. A call to the Actiontec engineering group confirmed that point. If you take the Actiontec router off of the ONT, and do a simple test of loopback in the router trying to go to your own web site using the wan IP it fails 100% of the time as expected.
My TP problem isn’t an issue with loopback as a feature in the modem. I have tested using openwrt and dd-wrt. The same TP issue occurs for me.
Is it possible something is configured wrong in one or all of my servers? They all run Fedora 26 now, but have been running Fedora since release 9. They are all configured identically.
I use a dynamic DNS service since I do not have a static IP. I do experience a very long delay for OSgrid to pickup a change in my IP address but the east coast name servers all are updated immediately. I usually need to wait several hours before an OSgrid login will find my region, however if I log into OSgrid to LBSA and then TP back to my regions that works. The login server does not get my correct IP address but the server that does the TP apparently does. My region INI files use the FQD and not the actual IP address.
Tonight, I am going to configure one of my servers to use the IP address to see if it helps at all.
What I don’t understand is why a hard reset of the router, where the memory is cleared and all new configurations need to be loaded causes things to work again for awhile.
I really can’t believe the admins of OSgrid have to go through all this to make things work, so it has to be something I am doing wrong. Back in 2010 when I started here in OSgrid I do not remember having so many issues with these two things. To be honest it was not until after the year long outage of OSgrid I started noticing the TP issue. I never really noticed the landing point problem since I didn’t do much travel outside my set of regions. I first noticed that after switching to VAR’s and always ended up at the bottom of the ocean.