ThreadBoard ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
Multipath for all AWI OPs... (Wishlist)
Multipath for all AWI OPs... // Wishlistlady nighthawkJan 20, 2005, 8:39am
Why can't all AWI OPs be joined for use in all AWI building worlds? Why not
allow the use of AW, Megapath, Mars, ObjectD', etc, to be shared in all building worlds? Why limit AW to just AW op, Megapath to just Megapath op? Well ok Megapath and ObjectD' aren't building worlds but they are free objects offered by AWI ... so why not allow use of all their OPs in any of their build worlds? I was building at a gift site the other day in aw and was thinking how great it would be if I could have a megapath item for use there :o/ LNH -- kennethJan 20, 2005, 7:53pm
It would be nice except that there are a few objects that are different but
with same names. People's builds would be changed if like sign1.rwx from megapath was changed to sign1.rwx from aw world path. It would be great if they could pool all those objects together and just keep the ones that are doubled away from aw world, and keep the original aw world ones there, and just have 1 new OP. -Kenneth [View Quote] lady nighthawkJan 21, 2005, 4:14am
Ya that's true but if it's not doubled up would be nice to be able to use it
in other worlds ... prolly too much work for them to sort em all out LOL. LNH -- [View Quote] ferruccioJan 22, 2005, 2:26am
There would be a simple way around that. Somehow do a scan of all identical
objects in say, Mars world, then put an extra "m" at the beginning of the object name. Then do the same with atlantis, and other worlds. It would require a new OP, though, or at least a few new object file names to be added to each OP. [View Quote] lady nighthawkJan 22, 2005, 5:34am
Well I think the reason it's too complicated is even if they did that some
of the objects have the same name but aren't the same objects. So if in alphworld I used door5 and in mars I used door5 ... but they aren't the same door, my builds using that door might wind up with the wrong door. If they rename mars to mdoor5 then all the door5 in mars wouldn't load because the door name is wrong ... or if the paths are then joined door5 from aw would load instead of door5 from mars. Confusing enough? LOL no wonder they don't bother... LNH -- [View Quote] ubermonkeyJan 28, 2005, 2:40am
The entire arrangement could be set up using a PHP script, which would allow
each world to have a "priority" setup. So, for example, in Mars the first path to check would be the default Mars OP. This way, using "door5" will give you the Mars door even though there is an AW door5, since it stops looking once it finds the first match. Likewise, in AW the AW path's door5 will be used because the path priority is set up as such. This avoids any damage to existing builds or objects in each world affected. Then, in order to allow access to identically-named objects from other OPs, a special prefix in the object name could be used, like "_aw_door5" or something (could be any format, the idea is just to come up with something that will probably never conflict with object naming). So, in AW you could use "_mars_door5" to get the Mars door, or just "door5" if you wanted the AW door. The PHP script just knows to use the characters between the two _'s as, for a simple example of how to set it up, a subdirectory to look in for the object/texture/whatever. So you'd likely have your OP arranged with directories mirroring the world names, then the standard models/textures/avatars/etc. under those folders. You could also simply redirect to the proper AWI-hosted OP for each tag, but it's probably best to just keep it all on one server to minimize response time. By default, it would probably use the name of the world you're in as the "hidden tag," (meaning that, in AW, "door5" gets translated into "_aw_door5" when the script processes the download request), but you could also customize this configuration and have your world default to the OP from, say, AW (probably by setting your OP to "whatever.stuff/myopstuff/b0rk.php?default_tag=aw&path=" or something equally simple. If you were feeling especially picky about the order you could even do, "b0rk.php?default_tag=aw&default_tag2=mars&......" so that it checks Mars first if it doesn't find the object in AW, thus allowing you to minimize the amount of cell space wasted by specifying OPs per-object). This system should deal with all the concerns people were bringing up about the implementation of multipath for all public build worlds, aside from the obvious issue that someone needs to write the PHP script and set up said ultra-OP for testing. I'd do it, but I've moved away from AW development towards the Torque engine, so.. I won't. For all I know one of the existing AW OP scripts already supports this sort of functionality by default. I guess the real concern would be getting AWI to set it up for the public worlds, but running this sort of OP system for private worlds wouldn't be hard; there's not even anything to rename. Of course, now there's a bit of a matter of the registry. Realistically, you'd have to 1) create a registery from the whole multipath in the correct order, so that the data for each object matches the version which is the "highest priority" and will as such appear when that name is used. In other words, "door5" in the AW registry had best point to the AW door5's data, not the Mars version. Then, 2) append this registry with secondary registries created for each OP's tag. IOW, once you've completed step one, add every object from every OP *again,* but this time with the _worldname_ tag at the start. This should cover the registry requirements, but how you're going to go about generating that I don't know (err, well, paste each OP into the same folder in reverse order (highest priority goes last) then use that awesome registery generator tool). At least only step 1 needs to be repeated for each world; you can just save the full with-tag registery and reuse that each time. :O This is about what it'd take to give every public world the megapath without forcing any changes to existing builds or destroying the registry. Well, you people asked, it's not my fault I answered. :P -Monkies(TM) [View Quote] |