0006024: llRequestSimulatorData doesn't return the proper cordinates

(0021468)
TechplexEngineer (reporter)
2012-05-20 01:47

I just found a random number generator. In the file HypergridLiner.cs:180
public GridRegion LinkRegion(...)

Well this explains why the value returned is garbage.

Is there a way to get the regions coordinates?

(0021469)
melanie (administrator)
2012-05-20 03:08

The coordinate would be meaningless. A query for that would cause needless intergrid traffic and opens avenues for exploits. Not a good idea. What would be a valid use case?

(0021470)
TechplexEngineer (reporter)
2012-05-20 03:54

The use case is that we want to write intelligent HyperGrid teleport scripts that will redirect users to an intermediary redirect station if the destination is more than 4096 away.

(0021471)
BlueWall (administrator)
2012-05-20 15:44

Maybe it could detect the HG format of the region name and direct it to the gatekeeper? If not, then maybe an OS version would work?

(0021473)
TechplexEngineer (reporter)
2012-05-20 18:49

Not Sure I understand what you mean?

(0021474)
BlueWall (administrator)
2012-05-20 18:57

@TechplexEngineer: We would need to change the lsl function to switch to getting the remote grid info based on the region name, ie. if it is a link to HG regions. Or we will need to provide an os function that does it. Either of these should communicate with the remote Gatekeeper service to retrieve the information.

(0021490)
TechplexEngineer (reporter)
2012-05-23 18:07

I would just like to point out that this data is already sent back on the remote xmlrpc call when linking a region, which was the way the lsl function operated when using the DATA_SIM_STATUS flag. Thus I'm inclined to disagree with Melanie's first comment here.

All this patch does is allow the script access to the region coordinates already acquired by the actions that happen behind the call GetRegionByName.

One final note, this data returned by the function when calling it with DATA_SIM_POS will be instrumental in seemingly overcoming the 4096 bug.

Thanks,
Blake

(0021532)
justincc (administrator)
2012-05-26 00:38

Committed as git master 33b6600 since the patch does not require another network request - it makes use of the data already returned by the earlier GetRegionByName(), thanks Blake.

However, this reuse of RegionSecret to store the final destination HG region handle is misleading. Can we create a new GridRegion.FinalDestinationHandle:string to store this instead or rename RegionSecret if it's not in use? This is a general comment - not a task for Blake.

(0021555)
TechplexEngineer (reporter)
2012-05-26 02:44

Maybe Diva can provide some info on why secret is a string. Really its just holding the region handle which should be a ulong.

Does that mean you don't want me to do it?

Surprisingly, it seems like its used in a bunch of places. Gonna try to refactor it to justin's suggestion.

(0021580)
justincc (administrator)
2012-05-28 22:09

You're welcome to make a patch to do it - this was more a reminder for me to talk to Diva about this. From my brief look, I believe that RegionSecret was already prior used to restrict access to regions, though this aspect may have fallen into disuse. Even if it has, though, I would argue that the property name is misleading.

In any case, this won't change until I know what Diva thinks.

(0021581)
TechplexEngineer (reporter)
2012-05-28 22:11

I didn't feel comfortable changing it as I couldn't discern all the various uses.

(0021582)
melanie (administrator)
2012-05-28 22:11

There is a purpose to RegionSecret and it should indeed not be used like this; another field is called for.

(0021585)
justincc (administrator)
2012-05-29 00:16

Yes. I think that we'll have another field for this. It's not completely straightforward since the data needs to be persisted as well, which means database migrations.

In fact, there are a number of very old and unused fields in the regions table that need to be cleaned up. I believe Diva is going to post more about this to the opensim-dev mailing list so I wouldn't worry about doing anything yourself, Techplex.

(0021598)
TechplexEngineer (reporter)
2012-05-30 17:16

Any reason this can't be marked as completed?

(0021600)
justincc (administrator)
2012-05-31 01:27

No, though I'd rather keep it only temporarily to remind me about the RegionSecret issue.

(0022840)
justincc (administrator)
2012-10-13 00:53
edited on: 2012-10-13 00:54

Still a problem but note now documented in the code.

Notes
(0021468) TechplexEngineer (reporter) 2012-05-20 01:47	I just found a random number generator. In the file HypergridLiner.cs:180 public GridRegion LinkRegion(...) Well this explains why the value returned is garbage. Is there a way to get the regions coordinates?

(0021469) melanie (administrator) 2012-05-20 03:08	The coordinate would be meaningless. A query for that would cause needless intergrid traffic and opens avenues for exploits. Not a good idea. What would be a valid use case?

(0021470) TechplexEngineer (reporter) 2012-05-20 03:54	The use case is that we want to write intelligent HyperGrid teleport scripts that will redirect users to an intermediary redirect station if the destination is more than 4096 away.

(0021471) BlueWall (administrator) 2012-05-20 15:44	Maybe it could detect the HG format of the region name and direct it to the gatekeeper? If not, then maybe an OS version would work?

(0021473) TechplexEngineer (reporter) 2012-05-20 18:49	Not Sure I understand what you mean?

(0021474) BlueWall (administrator) 2012-05-20 18:57	@TechplexEngineer: We would need to change the lsl function to switch to getting the remote grid info based on the region name, ie. if it is a link to HG regions. Or we will need to provide an os function that does it. Either of these should communicate with the remote Gatekeeper service to retrieve the information.

(0021490) TechplexEngineer (reporter) 2012-05-23 18:07	I would just like to point out that this data is already sent back on the remote xmlrpc call when linking a region, which was the way the lsl function operated when using the DATA_SIM_STATUS flag. Thus I'm inclined to disagree with Melanie's first comment here. All this patch does is allow the script access to the region coordinates already acquired by the actions that happen behind the call GetRegionByName. One final note, this data returned by the function when calling it with DATA_SIM_POS will be instrumental in seemingly overcoming the 4096 bug. Thanks, Blake

(0021532) justincc (administrator) 2012-05-26 00:38	Committed as git master 33b6600 since the patch does not require another network request - it makes use of the data already returned by the earlier GetRegionByName(), thanks Blake. However, this reuse of RegionSecret to store the final destination HG region handle is misleading. Can we create a new GridRegion.FinalDestinationHandle:string to store this instead or rename RegionSecret if it's not in use? This is a general comment - not a task for Blake.

(0021555) TechplexEngineer (reporter) 2012-05-26 02:44	Maybe Diva can provide some info on why secret is a string. Really its just holding the region handle which should be a ulong. Does that mean you don't want me to do it? Surprisingly, it seems like its used in a bunch of places. Gonna try to refactor it to justin's suggestion.

(0021580) justincc (administrator) 2012-05-28 22:09	You're welcome to make a patch to do it - this was more a reminder for me to talk to Diva about this. From my brief look, I believe that RegionSecret was already prior used to restrict access to regions, though this aspect may have fallen into disuse. Even if it has, though, I would argue that the property name is misleading. In any case, this won't change until I know what Diva thinks.

(0021581) TechplexEngineer (reporter) 2012-05-28 22:11	I didn't feel comfortable changing it as I couldn't discern all the various uses.

(0021582) melanie (administrator) 2012-05-28 22:11	There is a purpose to RegionSecret and it should indeed not be used like this; another field is called for.

(0021585) justincc (administrator) 2012-05-29 00:16	Yes. I think that we'll have another field for this. It's not completely straightforward since the data needs to be persisted as well, which means database migrations. In fact, there are a number of very old and unused fields in the regions table that need to be cleaned up. I believe Diva is going to post more about this to the opensim-dev mailing list so I wouldn't worry about doing anything yourself, Techplex.

(0021598) TechplexEngineer (reporter) 2012-05-30 17:16	Any reason this can't be marked as completed?

(0021600) justincc (administrator) 2012-05-31 01:27	No, though I'd rather keep it only temporarily to remind me about the RegionSecret issue.

(0022840) justincc (administrator) 2012-10-13 00:53 edited on: 2012-10-13 00:54	Still a problem but note now documented in the code.

Issue History
Date Modified	Username	Field	Change
2012-05-19 15:36	TechplexEngineer	New Issue
2012-05-19 15:36	TechplexEngineer	File Added: llRequestSimulatorData.lsl
2012-05-19 15:37	TechplexEngineer	File Added: Snapshot_001.png
2012-05-20 01:47	TechplexEngineer	Note Added: 0021468
2012-05-20 03:08	melanie	Note Added: 0021469
2012-05-20 03:54	TechplexEngineer	Note Added: 0021470
2012-05-20 15:44	BlueWall	Note Added: 0021471
2012-05-20 18:49	TechplexEngineer	Note Added: 0021473
2012-05-20 18:57	BlueWall	Note Added: 0021474
2012-05-23 11:37	TechplexEngineer	File Added: 0001-One-can-now-get-hyoergrid-region-co-ordinates-with-l.patch
2012-05-23 11:38	TechplexEngineer	Status	new => patch included
2012-05-23 18:07	TechplexEngineer	Note Added: 0021490
2012-05-26 00:38	justincc	Note Added: 0021532
2012-05-26 02:44	TechplexEngineer	Note Added: 0021555
2012-05-28 22:09	justincc	Note Added: 0021580
2012-05-28 22:11	TechplexEngineer	Note Added: 0021581
2012-05-28 22:11	melanie	Note Added: 0021582
2012-05-29 00:16	justincc	Note Added: 0021585
2012-05-30 17:16	TechplexEngineer	Note Added: 0021598
2012-05-31 01:27	justincc	Note Added: 0021600
2012-10-06 15:06	TBG Renfold	Relationship added	related to 0006340
2012-10-13 00:53	justincc	Note Added: 0022840
2012-10-13 00:53	justincc	Status	patch included => closed
2012-10-13 00:53	justincc	Assigned To	=> justincc
2012-10-13 00:53	justincc	Resolution	open => fixed
2012-10-13 00:54	justincc	Note Edited: 0022840	View Revisions