Well, think about it.

If you write 1. CloseGump() 2. SendDialogLayout(), there is no gump to close because you haven't send it yet. If you try 1. SendDialogLayout() 2. CloseGump(), on the other hand, send function holds script until player replies, and because of that, once you try to close the ...

Nice, but!

Is there any way to follow the tracker as easily as it is to follow forums? Here we have this "View new posts" link, but there's nothing like that on the tracker, I think. That's why I don't really know what's going on there, though I'd like to.

I'm glad if someone corrects me on this.

There seems to be no syshook for that, so the short answer is no.

However, you can work your way around this. E.g. add a is-there-yet-a-party check in the CanAddToParty hook and launch a control script if there isn't - run it for DeclineTimeout seconds and if leader gets his party, run the party ...

You may want to test another way to accomplish that. Basically it's the same but without all those neat variables. Documentation will tell you more about foreach statement if it's a new one to you.


foreach player in EnumerateOnlineCharacters()
if (player.cmdlevel == 0)
Start_Script("::XXX ...

This looking good.

Nando_k added the above wished CloseGump() function to core some days ago, and aside the misconstructed packet in my version, it works. No longer is the gump sending process required be killed!

As an additional, though minor, feature request, it would be useful to allow response ...

Beware, RunUO, here we come!

If you're still using 095, it's about time to update anyway.

You have to use packet object methods. Like this:
This information will hopefully ease the testing you'll do.

I spent some time studying this and I'm sure it will help someone out there (distro team, hehe?). Thanks for sharing! Hopefully one day your priorities will change again --- until then, have fun outside!

I like it!

Sounds like a feature.

Nice one!

We had a nice discussion with Nando_k, and the workaround got a bit cleaner.


SendPacket(who, "2727");
who.ClearGottenItem();


Handles the issue -so it seems- correctly, and does not show "You can not pick that up." message in journal. So I'll use it until the improved core is released. I post ...

I tried out 4.0.0.a and 4.0.2a, they share the same behaviour.

To my setup, the latest 098 beta release fixed the issue.

Thanks for doing extra work with this, especially because I as the scripter am the one to blame.

Hey, just retested this one using 098 BETA 3: still occurs. Client was the good old 5.0.1j.

Tell me if you need more details or testing.

Duh, it will take some time to try out even most of the stuff! Thank you and keep it coming!

A shame we already moved to 098...

But, hehee, nice work guys!

Hey,

First of all, thanks for the new MOVEITEM_IGNOREMOVABLE flag added to MoveObjectToLocation() function. This, however, arised a new lack of feature: there's yet no neat way to move item to (in) container if it's set unmovable.

Thus I wish you could add a new parameter to MoveItemToContainer ...

As far as I know, no.

Closest thing you can do is to save lightlevel of character every time it is send by server; but, this doesn't help you in this case, as what server tells the client to do forces nothing.

If you have a working day/night cycle you could of course add a how dark is it out there ...

Yukiko, you mean itemdesc members like graphic, color, script...?

I don't see why this couldn't be done and I'd vote yes if asked. And this reminds me of an old feature request I should have posted an age ago, UO::ContainerHasSpaceForItem(container, item), which would be a must-have after the ...

I tend to test things couple of times before reporting, but if you wish, I'll recheck this one. After all there are new releases and it's been a while since I noticed this, so I can't say for sure no longer.

It will take at least few days, but I'll take another look at this and eventually get back ...

Ability to define aliases to module functions sounds like a feature to me.

It could be as simple as aliases.em where each line represents an alias, like

Msg(character, text, font := _DEFAULT_TEXT_FONT, color := _DEFAULT_TEXT_COLOR) SendSysMessage( character, text, font := _DEFAULT_TEXT_FONT ...

Yeah, looking good.

Not only the mentioned fix but also the post reply button is right where it's supposed to!

Thank you all again.

// This I check right after the program block.
if (!CanUseCommand(who))
return;
endif
// ....



function CanUseCommand( who )

if (GetProcess(who.GetProp("#UsingCommand")))
return 0;
endif

who.SetProp("#UsingCommand", GetPid());
return 1;

endfunction


- No need to erase cprop ...