Guild of Writers

I've been trying to find a way to get the Great Zero's beam to appear in the new Pub (as it's located in Ae'gura) and I finally had a breakthrough! This'll be handy for anyone working on a cavern location who would like the GZ beam to pass over everything.

Behold!

Show Spoiler

A rough draft of the tutorial is done for now, but there will be additions later. For instance, a section needs to be added to make the beam only appear when the actual GZ is activated on a shard.

http://www.guildofwriters.org/wiki/Great_Zero_Beam

If anything doesn't make sense, let me know and I'll see if I can clarify. If you find any tricks or shortcuts while doing this yourself, feel free to add them to the tutorial. Good luck!

EDIT: Thanks to some help from Deledrius, we eliminated the need to work in PrpShop entirely! I also added more pics for reference to make things easier.

wow - congrats, Doobes!

Wow, cool Nice job.

About having it in sync with the GZ - that's a good idea, but isn't the GZ always active online anyway ? (I don't exactly remember). Plus, there is the matter of fetching the state of the GZ across Ages, and uhmmm... let's say that's possible, but in most cases that's a real headache (might be possible, but this could require special instancing rules, which Shard admin may be reluctant to use).

By the way, can PyPRP generate MarkerModifiers (or whatever they are...) so we can get KI coordinates in the Age ? I recall they are easy to setup but I'm not sure this has been implemented...
One has to be careful with these, though, since they actually give a precise location of the place, which could be lore breaking. That said, the same can be said of the projection light. And Cyan often did not bother with it themselves, so...

Sirius wrote:By the way, can PyPRP generate MarkerModifiers (or whatever they are...) so we can get KI coordinates in the Age ?

Yeah. It appears it's just a regular object (probably an Empty in Blender would work) with a Maintainer's Marker Modifier attached. No idea if there's AlcScript for that though.

As far as the GZ always being active, there was that big event back in MOUL where it turned on for the first time. Before that, the beams had to be there in the city and such, but shut off. And in Gehn, the GZ is currently off, so I'd assume something is set in the shard and the Age files to turn things on simultaneously? *shrugs*

Sirius wrote:About having it in sync with the GZ - that's a good idea, but isn't the GZ always active online anyway ?

It's active when 'calibrated', which is server-specific. Admins can choose whether it's running or not. Cyan has left it running on MOULa since it was turned on initially.

Sirius wrote:Plus, there is the matter of fetching the state of the GZ across Ages, and uhmmm... let's say that's possible, but in most cases that's a real headache (might be possible, but this could require special instancing rules, which Shard admin may be reluctant to use).

From what I see at the moment, each city sub-Age which has the GZ beam just uses its own independent islmGZBeamVis SDL to activate the responder (why they're using a responder instead of a simple SDLBoolShowHide, I'm not sure yet, but it might be for the start-up and shut-down animations in the main GZ chamber). It's relatively simple to just flip them all on or off using the globalsdl command on dirtsand.

Sirius wrote:can PyPRP generate MarkerModifiers (or whatever they are...) so we can get KI coordinates in the Age ? I recall they are easy to setup but I'm not sure this has been implemented...
One has to be careful with these, though, since they actually give a precise location of the place, which could be lore breaking. That said, the same can be said of the projection light. And Cyan often did not bother with it themselves, so...

Doobes wrote:Yeah. It appears it's just a regular object (probably an Empty in Blender would work) with a Maintainer's Marker Modifier attached. No idea if there's AlcScript for that though.

Yeah, the coordinates for some of Cyan's locations are a bit... unlikely.
Looking at PyPRP, the way to make a fully-functional Maintainer's Marker is to add a dummy at the same location as your lamp with an alcscript property calibration: calibrated. Thanks Paradox for figuring out the value on that. Other possible values are broken and repaired.

Deledrius wrote:Looking at PyPRP, the way to make a fully-functional Maintainer's Marker is to add a dummy at the same location as your lamp with an alcscript property calibration: calibrated (If it's not exporting anything else on it to give it a Coordinate Interface, you'll need to add type: point as well). Thanks dpogue for figuring out the value on that. Other possible values are broken and repaired.

Couple of things to add to this. First if you're using an empty object for the Maintainer's Marker you don't need to add anything to get a coordinate interface. All empties get coordinate interfaces regardless of the alcscript or what they're being used for. Second if you meant the figuring out the values for the calibration that was actually something I had done as I'm the one who added the Maintainers Markers to PyPRP.

Also, I'd suggest, if you want to use a Maintainers Marker, until we figure out the basic layout of the cavern and a system to make the Marker coordinates make sense, use the "broken" setting. That causes the marker coordinates to randomly change.

GPNMilano wrote:Couple of things to add to this. First if you're using an empty object for the Maintainer's Marker you don't need to add anything to get a coordinate interface. All empties get coordinate interfaces regardless of the alcscript or what they're being used for.

I wasn't sure about that, thanks for the clarification! (I've fixed the post to remove that)

GPNMilano wrote:Second if you meant the figuring out the values for the calibration that was actually something I had done as I'm the one who added the Maintainers Markers to PyPRP.

Nope, I meant the actual usage syntax in AlcScript. I was looking at your commit for reference but failed to use the enum values rather than integers. Paradox set me straight in IRC.

GPNMilano wrote:Also, I'd suggest, if you want to use a Maintainers Marker, until we figure out the basic layout of the cavern and a system to make the Marker coordinates make sense, use the "broken" setting. That causes the marker coordinates to randomly change.

This is equally problematic. If you're making a cavern location it would make no sense for that Age's marker to be broken; we know the GZ is working fine (at least on shards where it is enabled). I agree with you in theory, but in practice neither option is ideal. In the end, if people use an honest "best guess" we're not worse off than Cyan's already-broken coords.

Deledrius wrote:

GPNMilano wrote:Also, I'd suggest, if you want to use a Maintainers Marker, until we figure out the basic layout of the cavern and a system to make the Marker coordinates make sense, use the "broken" setting. That causes the marker coordinates to randomly change.

This is equally problematic. If you're making a cavern location it would make no sense for that Age's marker to be broken; we know the GZ is working fine (at least on shards where it is enabled). I agree with you in theory, but in practice neither option is ideal. In the end, if people use an honest "best guess" we're not worse off than Cyan's already-broken coords.

I understand what you're saying but, the marker isn't the same as the real maintainer's marker that Maintainer's set in ages that were "Maintainer Approved". The Marker Modifier's just enable the GPS for the KI. The only age that would have it anyway is an age with a GZ. So far that is only Earth. The broken setting can be explained in any number of ways 1. Being too far away from the GZ, the KI just scrambles the number as it searches for the GPS of the GZ. The materials in the walls screwing with the GPS in the KI etc. The "Best Guess" approach however can lead to stuff like, "Oh this area is sitting on exactly the same spot that the Kahlo Pub is at." Especially when the average person that builds ages, they're going to be building everything from the 0 plane of the 3d modeling window, so they'll likely set up the Marker in the wrong location relative to where everything Cyan made is.

I'm not entirely certain of that. My understanding was (and it's been a while since I read about them) that those markers were placed at the GZ-equivalent spot for the Age, and were indeed meant to provide coordinates for the KI in those Ages as well. Perhaps not.

Anyway, I'm not saying that it can't be explained (The Cleft has no GZ coords, which is odd given the KI seems to work generally everywhere but not the GPS function? I guess distance matters after all...), just that barring such an explanation there's no reason to assume it doesn't work (because it should). Anything else is just making IC-allowances for OOC-mistakes or OOC-laziness, and those should be avoided when possible.

I think it's unlikely anyone will end up duplicating locations if they bother to place one, and if they do it's something that shard-owners can work with the Age's author(s) to rectify for consistency before inclusion. In every other aspect, there's no guarantee that anything about a fan-made Age makes sense or is consistent with the rest of the game (and in fact many existing ones in the wide list available already don't bother). You make a great point about building at the origin though. That certainly increases the likelihood of conflict.


In the end, the choice lies with the author. We can only offer guidelines:

• Use the broken setting.
• Use the repaired setting, and provide a reason for the lack of proper GPS.
• Use the calibrated setting, and be sure to measure out your location properly.

So, here's the interesting thing.

In Uru CC the player has to do a quest to start the Great Zero, and once the GZ is started you can see the GZ line show up in the main city as well.

There is also the GreatTreePub converted from MOUL, which wasn't specifically designed to work with CC, but luckily the GZ line there still syncs with the GZ being on or off, just like it does for Ae'gura.

This is just a hypothesis at best, but I think the important thing is for it to have an SDL var of "islmGZBeamVis". That would probably make it sync for the offline game and I would guess it would be important to have a consistent name for the beam across 'ages' on an online server too?

Guess that's somewhat what Deledrius already said, though