search

HalcyonGrid / halcyon

Halcyon 3d virtual reality world simulator
BSD 3-Clause "New" or "Revised" License
20 stars 19 forks source link

Losing textures during session #88

Closed Ana-Green closed 4 years ago

Ana-Green commented 5 years ago

Come in Building Bot is dancing, 3 hours later the Bot texture is grey - Solution relog and Bot has Textures back.

Regards, Ana Green

Ana-Green commented 4 years ago

I thought to put it here my dad has multiple issues but the main one is that Halcyon does not load an OAR file correctly using the console command: load oar Market.oar after loading and some errors the Market place is there but no ground textures, I did try 3 backups, all the same, I know for 100% sure that these OAR's are all fine - any help would be great. - Ana Green

emperorstarfinder commented 4 years ago

A couple of things here.

The grey textures matter is being worked on and is related to updates done by LL to the viewer that Halcyon does not yet support as evidenced by tests of InWorldz 3 viewer and Alchemy Viewer 5.0.2 working while the latest Firestorm and Dayturn viewers produce the problem.

The errors relating to loading an OAR would be a separate issue but likely caused by some things that are in OpenSim and not necessarily supported by Halcyon.

Ana-Green commented 4 years ago

Also a couple of things: The grey textures issues have been solved, it was account-related, FS 6.0.1 and 6.0.2 do work just fine.
OAR issue, using Halcyon 0.9.41.7023. The first picture was taken before my Dad deleted by excedent a building on the Market place, that looks like the picture below, as you can see a clean region:
Market Place So my dad loaded the backup (logical) to restore the Market Place and got this Region, now keep in mind this is Halcyon 0.9.41.7023, I say that as this version did even import OAR's from Opensim 8.2 and now it looks like this :
Gone Because something is going wrong with the DataBase I guess see snap console: loading OAR errors So if we would delete the content of region welcome, we will not be able to restore the backup, lets say we delete this: Welcome Area This all is likely NOT caused by some things that are in OpenSim and not necessarily supported by Halcyon. As it always worked with Halcyon 0.9.41.7023. But if this would be true all creation my Dad made by himself would be lost cause they were saved at that time with Opensim 8.2.1 and if that is true he would lose all his work what still works on OpenSim got then broken by (changes) in Halcyon. What would be very bad, but what I see in the pictureloading OAR errors is a none compatibility with OAR Import/Export with to/from Opemsim/Halcyon but a DB error or Assets.

With regards, Ana Green

Ana-Green commented 4 years ago

Then the region does load from the backup took about 32 minutes and this is left from it:

Region up after 32

Ana Green

Ana-Green commented 4 years ago

Compares between the orginal region before the backup and after that is NOT an Opensim issue and f so how can that be on Halcyon 0.9.41.7023? https://user-images.githubusercontent.com/36156774/70383749-713d5600-1973-11ea-9ad5-09596f52e753.png https://user-images.githubusercontent.com/36156774/70384298-085adb80-197d-11ea-9e35-cc802b61186b.png Ana Green

emperorstarfinder commented 4 years ago

To clarify a couple of things.

  1. Are you using the 0.9.41 release dated August 13, 2018, or are you using the latest from Master?

  2. An error that returns the message "unknown type extension" is not database related as the evidence proves data is being loaded to the database. This message generally means it thinks the XML document in the archive is not recognized.

If you are using the release version from August 13, 2018, then it is likely the error your seeing with the archive might be resolved by commits done by Appurist during the closure of InWorldz relating to the compatibility of the IAR/ OAR archival process to ensure people can take their archives to OpenSim.

Ana-Green commented 4 years ago

Answer:

Dad is using Halcyon 0.9.41.7023, 08-13-2018

The message "unknown type extension" comes indeed from an XML document in the archive. However he has two grids http://www.DreamCastle-entertainment.eu/ with Halcyon 0.9.41.7023, 08-13-2018 in this case, I see also files compiled at 06-23-2019 this because Vinhold did run an update in between, the version and configuration did always run nice and smooth, even if Dad did copy a multiple OAR files together with Vinhold from his second server http://www.dsgrid.nl/ Opemsim 8.4.2 2019 called Imperium. This went always just fine till yesterday. Please advise me thank you.

Best regards, Ana Green

emperorstarfinder commented 4 years ago

I will need to touch base with Vinhold to see what updates he deployed to your server, however it sounds like the dearchiver thinks the xml file in the archive is not really an xml extension that it recognizes. This can be caused by either the archival service having a bug or being incompatible, or when the archive is created (in this case it sounds like it was created via OpenSim) it did not create the file in a clean and proper manner.

The way to test to see if the archive has a bad file would be to try to load it into an empty OpenSim region (not your father's custom version of OpenSim to ensure a clean archive load as customized versions sometimes break things unintentionally). If the problem doesn't occur there then try recreating the archive and reloading it into the Halcyon grid to see if the error appears again. If the problem goes away then it was just the archive and a potential file in the archive (this does sometimes happen that an archive goes corrupt or a file in an archive is not created correctly but will still work in some instances), if however, the problem persists then its a good chance we are dealing with a compatibility issue or a bug.

Ana-Green commented 4 years ago

"The errors relating to loading an OAR would be a separate issue but likely caused by some things that are in OpenSim and not necessarily supported by Halcyon."

If the above is the case, and it did occur after the update Vinhold did then Halcyon becomes obsolete. This is a particularly nasty one if OAR files are to be considered backups. And in the case of InWorldz OAR files captured at grid shutdown time back in July, it's worse, as these are the only copies. The common procedure for making a copy of a region is to issue a save oar command from the console, wait for it to complete, then copy the output OAR file elsewhere. Unfortunately, if you do not wait some amount of time after the OAR save has completed, the resulting file may be incomplete. This is due to the fact that the process returns to the console and new commands can be typed before the OAR save has completed. In the case of Opensim, we have the same "it's a compatibility issue" so yes I agree that it might the chance we are dealing with a compatibility issue or a bug. However why did it always load an OAR file Vinhold used, this went as follows, Vinhold needed some inventory files but IAR does not work with Halcyon yet at least not with Halcyon 0.9.41 so he used Opensim to create OAR files (mainly a free region with some boxes on it, in these boxes where outfits, etc [ Inventory content] ) that was then exported (Opensim 8.2.1) and imported to Halcyon 0.9.41 that went always just fine, as proof all regions on Halcyon came from my Dad's Opensim Backup (22 regions) and all worked well, this all ended yesterday as I said earlier.

At this point Dad can not even transfer load his own builds anymore to Halcyon, therefore I used the word " obsolete" to clarify the meaning of this word in context with what I wrote above.

Best regards, Ana Green

emperorstarfinder commented 4 years ago

"The errors relating to loading an OAR would be a separate issue but likely caused by some things that are in OpenSim and not necessarily supported by Halcyon."

That sentence was in relation to you having posted it in an issue relating to textures hence why it was a separate issue.

Appurist did implement compatibility for OpenSim OARs (and I believe it extended to IARs) during the course of his prepping OARs for folks at the time of InWorldz. Closure. As far as I am aware he made it compatible with the archiver version 0.8 which is used by OpenSim 0.8.2. The implementation happened after the 0.9.41 release, which is why I need to touch base with Vinhold to see what updates he deployed in June 2019 to your server. That will give me a better idea of whether you have those compatibility commits or not.

All the OARs I have imported into my team's internal testbed grid for Halcyon (created via our OpenSim testbed) do work as well which is why I am suspicious of the file in the archive itself. This does happen from time to time. I have seen this issue happen with grids running OpenSim and its various forks and derivatives. This is why it is a good idea to perform the test I mentioned with a clean copy of OpenSim 0.8.2.1 and not your dad's customized version. This way we can be sure there wasn't a break somewhere in the customizations that caused some issues in the archiver (I don't think there would be but one never knows it can happen even without it being known).

Also, Vinhold has OARs that are probably older (made years ago) that would work. Though he does go through his OARs on a local standalone region and weed through them and cleans them up and then recreates the archive via the save oar command. So that way he isn't getting anything that is cluttered or would be a potential issue.

Another test you can try to is try one of Linda Kellie's OARs (they are old so they should work without a problem) on a standalone local halcyon setup. If that works then try your OAR locally and see if the error still pops up. In that case its probably the OAR having issues with the one particular file in the archive.

Ana-Green commented 4 years ago

Vinhold is going to take a look at it so he wrote to my Dad, and my Dad is going to perform the tests you wrote, I'll keep you up-to-date until then :)

All issues will be posted here if they are important enough also for others.

Best regards, Ana Green

Ana-Green commented 4 years ago

Well don't get it done I just added a completely new floor using DS that did work but if I say save oar DCS Market.oar it says creating a halcyon? archive, etc with 0 assets so the original OAR was 8 Gbyte the new one 56,3 MByte without. oar extension.

Now I wonder do I have to deal with an archive section what has a bug and who inserted that? In any case, this can't be used as backup how I just saw it.

Regards, Ana Green

Ana-Green commented 4 years ago

Ok I tried again now using dcsmarket no space, now it is saving but with a lot XML warnings - pages full with red lines but I let it run see what happens, so in short, Dad did delete a house on the market, the original backup did store almost everything back except the ground prim + textures (_material.xml had a wrong extension it said), I took the ground prim with textures only from Dreamscape (Opensim) had to rip Dad's floor ... anyway did put it on Halcyon (DreamCastle) so the floor was back manual as it did not load the original market floor. Did save it as DCS Market.oar it says creating a halcyon? archive, etc with 0 assets so the original OAR was 8 Gbyte the new one 56,3 MByte without. oar extension. Then I used only save oar dcsmarket.oar it started to save more but with pages full red lines, no idea or the archive can be used is still saving as it is a kinda big file. Will post or/if that archive can be used, why not build in a rar, zip archive section?

Regards, Ana Green

kf6kjg commented 4 years ago

[Edit: posted this before I understood everything that was posted above, my apologies for the misunderstandings.] tl;dr: To summarize: if you use OARs for snapshotting a region state only for restoration on the same grid and use conventional backups to keep your asset server's data safe, then you're fine. Anything else will have issues.

Halcyon OAR backups default to backups of a region for that grid - thus they WILL NOT contain assets as those assets are in the immutable asset storage system. Think of it as a way to take a snapshot of the region for the purpose of restoring on the same grid - not for transfer to a different grid. If you are needing to backup assets, please backup the asset server itself.

If you are trying to load OARs from OpenSim... Well, that's not a feature that was originally intended to be kept when InWorldz forked: cross grid OAR transfer is fraught with problems as any grid admin who has allowed them has come to learn: expect severe asset breakage when you load an OAR in a different grid than it was saved in, or if the grid lost its asset server - even if you load it in another OpenSim grid. Appurist did do a TON of work to try and make it all work so that he could provide people with OARs for export to other grids, but it was only on a best effort basis as that's all he could guarantee - and he really put a lot of effort into it.

The problem comes down to the fact that it's a super complex problem to guarantee that all the assets in the region are saved. If you try to restore an OAR from one grid on another grid, or if the asset server was wiped, you'll have problems - no matter if it's OpenSim, Halcyon, or anything else. I've gotten lots of reports of missing assets being reported by the hundreds in Anaximander logs when someone decided to load an OAR on a grid. Vin can attest to having to do cleanup of peoples databases and regions because of the same.

kf6kjg commented 4 years ago

An OAR is a zip file.

emperorstarfinder commented 4 years ago

Last I knew the OAR import was working from OpenSim. If the archive size is 8 gigs, I can sort of see a potential problem with the assets getting loaded into WHIP (i.e. the conversation Rick and I have been having). I will have to look at my notes on what I have been told about the archiver system to see for sure. But definitely something to have a look at.

kf6kjg commented 4 years ago

Import is working, yes. But there are multiple situations being often conflated here:

  1. Importing an OAR from an OpenSim grid to a Halcyon Grid.
    • Often has missing items and assets.
    • Often has problems due to the differences in OpenSim and Halcyon.
    • Creator and Owner will be a source of headaches: this is an open problem in even the latest OAR format.
  2. Importing an OAR from a Halcyon grid to a different Halcyon Grid.
    • What Appurist mainly worked on.
    • Often has missing items and assets, or even script issues. This is due to that best-effort solution to the hard problem of guaranteeing that all needed assets are saved.
    • Creator and Owner will also be a source of headaches.
  3. Importing an OAR from a Halcyon grid to the same Halcyon Grid, but the asset server having been wiped.
    • Mostly the same effects as 2, excepting that Creator and Owner should survive if the user database table was kept intact.
  4. Importing an OAR from a Halcyon grid to the same Halcyon Grid, asset server intact.
    • Should work fine - assuming export worked correctly and completed fully.

If the export never properly completed, then import will have even more issues in all cases.

emperorstarfinder commented 4 years ago

Yes, the asset problem even with an OpenSim is and was and always will be a nuisance. I will add to my list of things to look at this week.

emperorstarfinder commented 4 years ago

To provide a more in-depth answer to Ana's question:

Will post or/if that archive can be used, why not build in a rar, zip archive section?

By default when you save an oar (i.e. using the command save oar dcsmarket.oar) it will save the archive as a compressed file in the .oar format (a carryover from OpenSim prior to Halcyon being forked). You can, however, edit the command and say save oar dcsmarket.tgz which will create a tar gz file (which can be opened with Winrar but do not do that or you'll corrupt the file). In all fairness over the years I have never been able to answer the question of which format is really better for saving OARs. The same is true with the IAR format (not working in Halcyon as far as I am aware) in which case you could either save the IAR archive in the .iar format or the .tgz format.

mdickson commented 4 years ago

Ok a couple of things:

Ana-Green commented 4 years ago

The question is what compression would be better ZIP, RAR, even ARC then ZLIB has a streaming compression as far I know, about and around this whole compression debate emperorstarfinder wrote By default when you save an oar (i.e. using the command save oar dcsmarket.oar) it will save the archive as a compressed file in the .oar format (a carryover from OpenSim prior to Halcyon being forked). You can, however, edit the command and say save oar dcsmarket.tgz which will create a tar gz file (which can be opened with WinRAR but do not do that or you'll corrupt the file). In all fairness over the years I have never been able to answer the question of which format is really better for saving OARs. The same is true with the IAR format (not working in Halcyon as far as I am aware) in which case you could either save the IAR archive in the .iar format or the .tgz format. Over the years several compressions have been used one was better for data compression other where better for Sound (MP3 or AAC and DTS, AC3) and more … but the key is compatibility, you not going to change a jpg file or png file because it's used in Halcyon you maintain the same structure, the same for all other compressions and methods over the years like RLE (Run Length Encoding) So I would never change a ZIP file lets say into a different structure you can do that if you made your own compression method. Lossless compression is a class of data compression algorithms that allows the original data to be perfectly reconstructed from the compressed data. By contrast, lossy compression permits reconstruction only of an approximation of the original data, though usually with greatly improved compression rates (and therefore reduced media sizes). Lossless data compression is used in many applications. For example, it is used in the ZIP file format and in the GNU tool gzip. It is also often used as a component within lossy data compression technologies (e.g. lossless mid/side joint stereo preprocessing by MP3 encoders and other lossy audio encoders). Lossless compression is used in cases where it is important that the original and the decompressed data be identical, or where deviations from the original data would be unfavourable. Typical examples are executable programs, text documents, and source code. Some image file formats, like PNG or GIF, use only lossless compression, while others like TIFF and MNG may use either lossless or lossy methods. Lossless audio formats are most often used for archiving or production purposes, while smaller lossy audio files are typically used on portable players and in other cases where storage space is limited or exact replication of the audio is unnecessary. As for Halcyon why not do the same as on top of some compatible protocol like TCP, UDP the layers stay the same but on top they use SIP, but you can put anything on top in that way you remain compatibility and on top a layer only for Halcyon. They did the same for the protocol Bink, anyway that are my opinions, if compatibility fails it would be a chaos.

Regards, Anna Green.

mdickson commented 4 years ago

The format the file is written in doesn't change if you change the file name. An oar is a gzipped tar file with an fixed internal structure. You can use cygwin gnu tar on windows or regular gnu tar on linux to "unpack" the archive although it will just be an encoded set of files in the internal format defined by the OAR spec.

emperorstarfinder commented 4 years ago

I don't see why an 8 gig OAR should be a problem (other than there are probably some really hi poly mesh objects in there) with Whip. Again the issue isnt object size its data compatibility.

The problem I foresee is the problem Rick and I have been discussing relating to delays between the time an upload is completed and the time It is fully available in-world due to some delays between the cache and WHIP.

There is no asset problem with OpenSIm at all. OARS including OARS with assets work fine in opensim. It's moving data to/from OpenSim and Halcyon that is the issue. OARS are a glorified region snapshot mechanism in Halcyon as implemented now.

In fact, this is an incorrect statement as Rick outlined. If assets (or objects) are deleted and you export an OAR you will get data for assets that in fact are missing in OpenSim. That is what he was outlining as a problem, not necessarily that its a problem with the architecture.

As to the file format of an OAR, it is correct to say that the OAR structure would stay the same regardless of whether the saved oar is saved in the .oar or .tgz format. Where I questioned which is the better format is based on the use case and the chances of the corruptibility of each format. In fact, often people tend to post issues relating to OARs when they use the .tgz file format as opposed to the .oar format from what I have seen.

If the overall goal is to have exact compatibility with OpenSim's OAR and IAR system then in the current format, no Halcyon probably will not ever be fully compatible. Likewise, if that is the goal then the question of whether Thoosa and the use of SimpleDB and the current form of ProtoBuf throughout the codebase should be kept comes into play.

mdickson commented 4 years ago

Well if assets are deleted before the OAR is made then yes you'll have a problem. They can't be fetched when the oar save is done. But that is breaking the underlying assumptions for assets. They're not supposed to go away.

For the large assets and delays.... Well IMO bottom line is asset writes need to be transactional. For a couple of reasons. Firstly the issue in Halcyon, if an asset is in a region cache and not yet on disk then a call to aperture to fetch a texture (or mesh) can realistically fail. And potentially cause a negative cache entry in the viewer which will later require a viewer cache clear. You might decide to put a cache in the asset server and do write behind. That COULD work if its the only cache in the system (which it wont be in Halcyon) and if you can limit the # of assets servers to 1. In other words that solution constrains the architecture such that you can't add asset services to scale for load. It only works in the degenerate case of 1 service.

So the short answer is an asset isnt live until its written to storage and that transaction completes. That way its always resolvable regardless of where you put caches, etc. FWIW thats how whip used to work before cloud files was introduced and there was an attempt to put caches in places to "fix" slow asset performance without consideration of cache synchronization. That also includes me btw (I did some work on the existing asset cache in the region to expire assets) before we understood the timing issue that was introduced.

emperorstarfinder commented 4 years ago

There is a definite delay. I clocked it over the weekend to approximately 30 seconds from the time I uploaded a texture to the actual time I tested dropping the texture on a prim in-world. so the delay is apparent. When I said I could foresee an issue with larger amounts of assets to upload (in bulk) that will create some issues with things, not rezzing in-world until they are live because of those delays.

As to whether the asset write should be transactional or not it probably would solve some issues, but I think before rushing into going that route we first should look at the entire asset issue including were to really store the assetcache (region vs aperture). My understanding is that aperture was meant to boost the speed of rendering mesh and textures. So it might make sense to put the assetcache there instead of at the region server level.

I still have a lot of reading to do through the documentation and the code relating to assets to understand fully what was done by InWorldz. In a way, it is sad that the commits from the old SVN repository have been lost as those commits could have been helpful to see.

mdickson commented 4 years ago

If there is a 30 second delay between uploading a texture and its availability to Aperture something else was busted about what should be a synchronous operation. A delay like that sounds like someone delaying writes to batch them or some such. Assuming no CF or external dependencies the whip path should be super fast. I did tests early on and pushed ridiculous amounts of asset data across that connection with sub second writes for the most part. A big texture might be slightly slower but not 30 seconds.

Aperture was originally textures only. It handled fetching with discard levels so textures could load progressively. Mesh was added later since it seemed like a reasonable place to put it. Get the large data out of the C# Region Process where GC could be a problem.

And yes there is lots of history from the SVN work that's probably only riding around in a few people heads now. Moving to git was the right thing to do at the time but the lost history would help understanding around some of this evolved for anyone not there at the time and familiar with it.

emperorstarfinder commented 4 years ago

It wasn't a big texture. It was for a pretty basic seamless wood texture. (tested with textures from OutWorldz website). My understanding is that some folks have been seeing issues with bulk uploads (i haven't tested this part yet) so if the timing for 1 simple small wood texture takes about 30 seconds to become live upon upload I would say there is a definite issue.

Ana-Green commented 4 years ago

Alternate change detected - the two pictures are for to Compare between DSGrid and DreamCastle besides the floor there are worse loaded spots. this DSG is the original on DreamCastle its complete a mess. Be aware ZIP compression does not change any content, data, music files or even compressed video unless the two OAR aka ZIP files do not have the same (not equal) content, data, music files or even compressed video. The flaw if any has been produced by Halcyon or the code has changed so much that Halcyon and Opensim are not compatible as result you can not exchange OAR files anymore, what in this case is a disaster for my Dad he can not put his own work on Halcyon, if the data so the way Halcyon works most or should be altered for reason for me unknown then why not let the user decide like Compatibility mode on / off for Opensim in the halcyon.ini file or a separated ini file?

Let's face it Halcyon has been forked from Opensim, so you could say its an altered clone from Opensim with a different name. That does not mean that Opensim is worse or better and the other way around.

, For example, MariaDB is a Fork from MySql yet still compatible with each other only MariaDB has better performance, I believe with 27% ...

good on DSG_001

NOT good DreamCastle_001

Regards, Anna Green CEO Cisco since yesterday - YAY :)

Ana-Green commented 4 years ago

The above is for #88 Anna Green

kf6kjg commented 4 years ago

From personal experience I can tell you that MariaDB and MySQL are NOT 100% compatible - especially when you get into GIS. Likewise Halcyon and OpenSim are not 100% compatible - especially when it comes to materials. In the latter case it's because of totally different and mutually incompatible implementations. A better comparison would probably be OpenOffice vs LibreOffice: LibreOffice is based on an older version of OpenOffice but they've diverged so much that there's not much ability to share code any more.

Anna this issue, #88, is it more about "losing textures during session" as it's currently titled or about problems loading OARs from OpenSim? If the latter then we should change the title.

emperorstarfinder commented 4 years ago

@kf6kjg I suspect its a bit about both. The textures she was noticing originally came from an OAR she was trying to load into a Halcyon based grid from an OpenSim based grid.

The fact that the architecture is a fork of OpenSim or not really isn't relevant here to this particular issue. The reality is there will always be differences in the various virtual world architectures regardless of whether there is a problem or they are a fork or not.

The results from the test Vinhold has indicated he will be conducting should give us the answer to the question of whether the assets here are getting loaded or not. As I indicated earlier, I did find a delay between the time of upload to the time the asset goes live of about 30 seconds. I suspect that this is part of the problem along with the unknown file extension type.

mdickson commented 4 years ago

As I've previously stated the materials implementations in OpenSim and Halcyon are absolutely NOT compatible. Persistence is entirely different, Halcyon OARS where never meant for portability. Jim did some work on that but not that solved the essential issues. And the OAR support for converting formats was never done.

Ana-Green commented 4 years ago

And also as I have previously stated the OAR's did always load from Opensim to Halcyon, [ .39] explain me then if that is not the case why all the 4 regions did perfectly load, these same OAR's and I say it again the same OAR's do not load anymore! namely DSG1.OAR, DSG2.OAR, DSG3.OAR, DSG4.OAR. @kf6kjg "The results from the test Vinhold has indicated he will be conducting should give us the answer to the question of whether the assets here are getting loaded or not." They did not proceed with this test as my Dad could not copy 4 x 8 = 32 Gbyte from one server to the other, why 4 oars because of all load wrong. Anyway, the 4 center regions can not be loaded by Halcyon, that tells me (1) the content is not compatible with the content from OpenSim OAR's, for Grid Owners the IAR compression algorithm has been taken out, so there is almost no way to get content from other servers to Halcyon unless it is also Halcyon or by directly Database Insertion. The DSG oars where the first present on the Halcyon server but due a crash fixed by **TransIP Inc.** all started again [ still .39 ] but the oars where lost.

And I disagree it is relevant that there is some sort of access without Database Insertion, even from other sources [We at CISCO] for example have to convert tools from SIP not compatible with Skype to Yealink SIP, not relevant? Yes it is relevant, such a convertor from Halcyon to Opensim and from Opensim to Halcyon is not that complicated after all the ZIP compression remains the same you just use a table (a compare convert list if you will) to do the conversion, so that takes out that the persistence is entirely different, Halcyon OARS were never meant for portability. well; maybe not Halcyon OARS but as I said build a conversion tool, does not tell me anything about the fact that it first did work in [ .39] That was my last message about -> https://github.com/HalcyonGrid/halcyon/issues/88 as it seems it does not make any progress. <-

Excuse me for some typos but I have to run, need to work.

Anna Green

Ana-Green commented 4 years ago

Well, all nor I or Melanie have no clue how to make from Dream Castle an SL looking world and payment system in a short period of time, then Melanie her time is limited. Content creators will not come to an empty Grid because I can't upload oars in the way they were intended to. The 4 center OAR's where build by 3 people a woman, Robert and me now I can't even import them in the correct look or way/shape even if I could transfer them with HG it would not work, so there is a need for an Open-sim Converter, [1] Decompress [2] the Open-Sim OAR, create a world (somehow) and then [3] Compress them again in the Halcyon format using compare tables so one table move A to C and so re-create from that content a working Halcyon OAR, impossible? nothing is impossible with the right people. Impossible is only on your own agenda with I do not want it that way.

Frank Orbis, Melanie Bell (SL content creator) and Anna Green

Ana-Green commented 4 years ago

Well, all nor I or Melanie have no clue how to make from Dream Castle an SL looking world and payment system in a short period of time, then Melanie her time is limited. Content creators will not come to an empty Grid because I can't upload oars in the way they were intended to. The 4 center OAR's where build by 3 people a woman, Robert and me now I can't even import them in the correct look or way/shape even if I could transfer them with HG it would not work, so there is a need for an Open-sim Converter, [1] Decompress [2] the Open-Sim OAR, create a world (somehow) and then [3] Compress them again in the Halcyon format using compare tables so one table move A to C and so re-create from that content a working Halcyon OAR, impossible? nothing is impossible with the right people. Impossible is only on your own agenda with I do not want it that way. Frank Orbis, Melanie Bell (SL content creator) and Anna Green

kf6kjg commented 4 years ago

Ana due to the long and convoluted history of this issue ticket, covering multiple issues and problems, please create a new issue requesting that feature and we can proceed from there.