Put the Python in the repo

[JWPlatt]

Hi folks,

As we continue to learn a process, Mark and I discussed it just a tad more. Not a lot - just a tad. In regards to the MOULSCRIPT repo, and probably in things generally going forward, he seems happy to commit the MOULa changes to the MOULSCRIPT repo. That keeps it official. And we intend to combine the MOULSCRIPT-dev repo into the MOULSCRIPT repo, but on a site or developer branch within it. The default (main) branch (trunk) would always reflect what is on MOULa so people can always grab MOULa compatible code; exactly what's on MOULa. The default branch gatekeeper would then be Cyan Worlds or anyone they assign.

On our end here, an "ou" branch would be for all the changes that have been reviewed (in some manner - more on that later). Developers would be able to push to their own branches to await review, but not to "ou" or default. The "ou" gatekeepers would merge developer branches to "ou" and the Cyan Worlds gatekeepers would merge or push to default.

To this end, we'll be moving D'Lanor's committed changes from the default branch to an "ou" branch until they make it to MOULa. At that time, they'll come back with a push or merge to the default branch.

At least, that's the theory. So please excuse our mess as we continue to learn. Roadwork and cones ahead.

Thanks.

[D'Lanor]

xKI - Unknown senders of buddy messages are added to the Recents lists

It seems the jury is still out on this one because technically it is considered a change in functionality and not a bug fix. According to the rules described here a change in functionality requires a consensus in order to be accepted.

So I'll give you an explanation of the problem:

Someone has added you to his/her buddies list and is chatting to you in buddies mode from another age. You want to reply but unfortunately this person is not on your own buddies list. You search your recents list but alas, he/she is not there because currently only chatting age players and senders of PM messages are added to recents. This makes it is impossible to reply.

Even if this is not a bug as such it certainly has been bugging me for a long time.

This change adds players chatting in buddies mode to the recents list as well, but only if they are not already on the buddies list.

So... anyone else who believes this would be a useful change?

[JWPlatt]

Yes, useful. You should be able to reply to anyone who sends a message, regardless of origin, except maybe "special" invisible avatars. Furthermore, there have been proposals for ad hoc groups - not just age, buddies and neighbors. The concept should extend to receiving a message from any group, including ad hoc groups if and when that feature is implemented.

[a'moaca']

I want to make clear (in case it isn't to all readers) that this is MY rule, in my role as limited-time only gatekeeper. This requirement for consensus is not, to my knowledge, any kind of OpenUru.org rule. I simply did not feel that in a temporary role, I should be making judgments about functional changes.

I think decisions about what the rules should be, or decisions about functionality like this, should be in the hands of people with vested, active interests in the projects. I am not that person for the Python.

I nominate D'Lanor to be the first such person here. If he's interested and willing, of course. He clearly is active, made an effort to bring in others' changes, and is certainly well-equipped to make decisions about future contributions.

- a'moaca'

[JWPlatt]

Seconded.

[Nye_Sigismund]

Anyway - I'm not a code developer, but I can give my opinion, I guess. The change is a good idea - like JWPlatt said, you should always be able to talk to someone who is talking to you. If it's one small step towards fixing the Ki, I'm all for it.

[a'moaca']

Indeed, the museum and library doors were removed because they didn't work properly. So this file may have some future fixes coming anyway.

It is my firm belief that the xHighLevelStarTrekDoor cannot be fixed in the Python, and that it requires at least two changes in the objects in the PRP files.

Cyan spent several updates making the Python more and more complex to no avail. I think the whole thing should be abandoned, and a new version written for the use of new ages, because it works much better if the responder is built like the Teledahn prison doors. The "working" one y'all see on modern Alcugs shards is the one I built in the hex editor. Even that one is flawed, though.

My writeup is available upon request. It's quite long.

- a'moaca'

[JWPlatt]

My writeup is available upon request. It's quite long.

Wiki addition?

[D'Lanor]

Indeed, the museum and library doors were removed because they didn't work properly. So this file may have some future fixes coming anyway.

It is my firm belief that the xHighLevelStarTrekDoor cannot be fixed in the Python, and that it requires at least two changes in the objects in the PRP files.

Cyan spent several updates making the Python more and more complex to no avail. I think the whole thing should be abandoned, and a new version written for the use of new ages, because it works much better if the responder is built like the Teledahn prison doors. The "working" one y'all see on modern Alcugs shards is the one I built in the hex editor. Even that one is flawed, though.

My writeup is available upon request. It's quite long.

- a'moaca'

Actually I made a fail safe automatic door for Shell 415 in Ahra Pahts without any Python code at all. This door still gets stuck though in one particular situation but that is always in the open position so no one can get locked in. This happens when a person backs away without entering the door before it has fully opened. And these doors never remain stuck permanently. They always reset when someone walks through the activator region again.
However, not using Python could result in a repetition of the animation if one or more age players are experiencing latencies which are higher than the time it takes to play the responder.

As for your proposal, I need time to think this over. I'm not nearly as active as I used to be. My active Uru time at the moment is maybe three or four hours a week. And that includes the weekly Sunday TMP Hood meeting in MOULa and skimming the forums.

[a'moaca']

Actually I made a fail safe automatic door for Shell 415 in Ahra Pahts without any Python code at all. This door still gets stuck though in one particular situation but that is always in the open position so no one can get locked in. This happens when a person backs away without entering the door before it has fully opened. And these doors never remain stuck permanently. They always reset when someone walks through the activator region again.
However, not using Python could result in a repetition of the animation if one or more age players are experiencing latencies which are higher than the time it takes to play the responder.

Unfortunately, you're going to have to reevaluate whatever approach you used against MOSS/MOULa. I've just checked the code, and it's still the case that the Alcugs server doesn't do the right thing with plNetMsgTestAndSet. Diafero's done a lot of good work so I was hoping it would be fixed. Anyway, this means that the activator region actually behaves differently multiplayer in MOULa/MOSS vs. Alcugs. (Single-player it will be the same.)

Just a caution. Age writers will bump into more of these sorts of things, I'm sure.

- a'moaca'