I have configured a queue filled by static or dynamic members (both tested) and joinempty=true. When all the members are busy, any other incoming call is placed into the queue instead of following dialplan next steps.
Any help would be great
Seams like you not understand what policy do.
; joinempty = yes
Asterisk 1.8:
; paused - a member is not considered available if he is paused
; penalty - a member is not considered available if his penalty is less than QUEUE_MAX_PENALTY
; inuse - a member is not considered available if he is currently on a call
; ringing - a member is not considered available if his phone is currently ringing
; unavailable - This applies mainly to Agent channels. If the agent is a member of the queue but has not logged in, then do not consider the member to be available
; invalid - Do not consider a member to be available if he has an "invalid" device state. This generally is caused by an error condition in the member's channel driver.
; unknown - Do not consider a member to be available if we are unable to determine the member's current device state.
; wrapup - A member is not considered available if he is currently in his wrapuptime after taking a call.
Related
In some contracts, I see they use constant slot numbers. But how are they guaranteeing that that slot will never be used? For example in EIP1967 there is a slot for implementation:
// bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1)
_IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;
and another example is in the Gnosis's contract:
// keccak256("fallback_manager.handler.address")
FALLBACK_HANDLER_STORAGE_SLOT = 0x6c9a6c4a39284e37ed1cf53d337577d14212a4870fb976a4366c693b939918d5;
The question is: Is it safe to use any slot using this approach? Can some dynamic array or mapping be used in this slot? For example:
// keccak256("some.dummy.address.address")
SOME_SLOT = 0x47bd68279a41c9ae1cc277c8922809c3c82881c5143963fcfc95b91a61097eb5;
Ethereum writes to the free memory slots. Fromt the docs:
Solidity always places new objects at the free memory pointer and
memory is never freed (this might change in the future).
if you already wrote into a slot, Ethereum will not store anything in that slot. Now it is up to developers to keep track of which slots they already have used. In order to define which slots they are going to use, developers use inline assembly. (This is one of the advantages of inline assembly. It gives you granular control over the memory)
I've read a few forum posts that some people prefer to use raise event over rpc,
but I can't find the reason why they prefer it. Is raise event interchangeable with rpc?
I mean I get it raise event is easier to use than RPC , because RPC requires the gameobject holding it to have photon view. But is there a situation where I should be using rpc instead of raise event? Any input is greatly appreciated !
RPCs and Events are very similar, but have some key similarities/differences:
Both:
Have options for buffering: (RpcTarget.*Buffered and RaiseEventOptions.CachingOptions)
Have options for encryption: (RpcSecure and SendOptions.Encrypt)
Have options for targeting specific users: (RpcTarget and RaiseEventOptions.Receivers)
Only RPC(s):
Require the [PunRPC] method attribute
Require (and run) on a particular object with a PhotonView
if the object no longer exists on the remote, the RPC never runs and is dropped
Have parameters defined by the method declaration only
Does support method overloading, but not optional parameters
Can have PhotonMessageInfo parameter
Only RaiseEvent(s):
Are always sent "ViaServer"
Your local client will be sent a copy of the event through the server, rather than executing locally immediately (assuming you're a receiver)
Can be circumvented by calling your OnEvent method directly, and using ReceiverGroup.Others
Uses a callback target defining the OnEvent method
Can be called without the need for a target PhotonView
Parameters arbitrary defined, they must be manually parsed/casted by the client
Have a limit of user-definable IDs: 1-200 (can be circumvented with parameters as sub-IDs)
Can be sent both reliably and unreliably via SendOptions
TL;DR: Generally, you'll want to use an RPC if something is related to a PhotonView, and a RaiseEvent call if not. They have basically the same capabilities otherwise
Source: Photon PUN Documentation: "RPCs and RaiseEvent"
I'm simulating a security control process, and i can't do that each passenger pickup their baggage. I have tried with Match, Combine, Pickup, but I still can't execute the commands correctly.
I've created the follow flowchart, and the problem is in the wReclaimPax, pickup and wReclaimBags blocks (you can see them in the picture).
https://ibb.co/v3V57Tm
I saw this link Anylogic - Combined multiple items back to original owner to understand something, but I still need help.
I've created 3 functions:
isMatch:
if(equipaje.pasajeroLink.equals(pasajero.equipajeLink)){
return true;
}
return false;
paxBags:
for(int i=0;i<wait.size();i++){
Pasajero p=(Pasajero)wait.get(i);
if(isMatch(p,bag))
return p;
}
return null;
bagsPax:
for(int i=0;i<wait.size();i++){
Equipaje e=(Equipaje)wait.get(i);
if(isMatch(pasajero,e))
return e;
}
return null;
Assumed context
You haven't really explained how your code is related to your process but I'm assuming the following:
Because this is luggage-retrieval, you want to ensure that a passenger
agent (Pasajero) only enters the Pickup block (representing taking bag from
carousel) when his bag (Equipaje agent by the look of it) has
arrived into the wReclaimBag Wait, and been released from it to
queue4 Queue.
For this you need triggers (to remove agents from Wait blocks) when
either a passenger (Pasajero) arrives in wReclaimPax Wait, or a bag (Equipaje) arrives
in the wReclaimBag Wait (because you don't know whether the passenger or their bag will get to their respective Wait blocks first).
So your paxBags function is called in on-entry action of the wReclaimBag Wait, and your bagsPax function in the on-entry action of the wReclaimPax Wait.
Possible problems with current approach
Without knowing more of your model it's hard to say but problems I can think of based on what you've supplied are:
Your functions return the Pasajero or Equipaje if there is one that matches. Your match check relies seemingly on bidirectional connections (links) between Pasajero and Equipaje. Obviously if they're not setup properly the model won't work and, if you're using bidirectional connections you shouldn't need to check both ends.
Your functions need calling so that, if they return non null, they then free the matching agent from the other Wait block, and free themselves. Are you doing that? Without checking, there may be issues with calling free for yourself as you enter a Wait block (since this kind of depends on AnyLogic internals as to whether you count as being 'in' the block at this stage and can be freed). If this seems to be the problem you could create a timeout 0 dynamic event instance to do the free so that you're not doing it within the scope of the on-enter action.
Your pickup block (since it's been setup so that the entering agent will always want to pickup the first agent (Equipaje) in queue4) just needs to be set as waiting for quantity 1 (though see below).
If you've done all this the most likely problem is that the underlying events ordering of AnyLogic is affecting things. When you free agents I'm fairly sure the freeing actually happens in a timeout 0 event scheduled under-the-covers. So it may be that the passenger arrives at the Pickup before their Equipment arrives in queue4 though, if you set the Pickup to be "Exact quantity (wait for)", with quantity of 1, it should handle that.
The animation of the process (numbers in/out/within each block and details when clicking on blocks) should also help you debug what is going wrong; e.g., are bags being left in the Wait when they should have been released, etc.
P.S. With this kind of thing you should always create a minimal example model to make testing the issue/solution easier (and for sharing in help forums such as this where the rest of the complexity of your model is irrelevant). Often you find the problem 'naturally' in the process of trying to construct such a model that reproduces your problem in a minimal way.
In Unreal GameplayAbilitySystem, e.g. Cancel Abilities With Tag is documented with
Cancels any already-executing Ability [..]
and the source code says (in GameplayAbility.h)
Abilities with these tags are cancelled when this ability is executed
To know at design time, which abilities will be affected when setting those tags, it is required to be sure about:
When a GameplayAbility is considered as executed and when as executing?
According to the documentation linked above, the GA is executed with CallActivateAbility(). However, activation can be interrupted, if cooldown/costs conditions are not fulfilled (e.g. "not enough mana") in CommitAbility().
CommitAbility() checks if the ability can be activated via CommitCheck() (cooldown/costs) and only if this succeeds, CommitExecute() is called (which applies cooldown and costs).
Before CommitAbility(), PreActivate() is called, which
1) sets (for instanced GameplayAbilities):
// ...
bIsActive = true;
bIsBlockingOtherAbilities = true;
bIsCancelable = true;
// ...
2) and blocks/cancels other GameplayAbilities with given tags using UAbilitySystemComponent::ApplyAbilityBlockAndCancelTags
Detailed questions which might help to answer the question above:
Is executing a GameplayAbility the same like activating a GameplayAbility or have these terms different meanings? (both terms are used in documentation and function names/variables)
Is a GameplayAbility always considered as executing as soon as PreActivate() is called? (since that function blocks/cancels other abilities via ApplyAbilityBlockAndCancelTags and therefore - according to the second quote above - is considered as executing)
This would imply, that a GameplayAbility is considered as executing
independently from the outcome of CommitAbility()?
as long as UGameplayAbility::ActivateAbility() is executing?
How is a GameplayAbility detected as executing?
Is it enough to check for UGameplayAbility::bIsActive == true (for instanced GameplayAbilities)?
Or are executing abilities registered somewhere in UGameplayAbilitySystem?
...
Hypothesis
The terms activate/execute a GameplayAbility (GA) and active/executing GameplayAbility are used when the abilities influence each other with GameplayTags. So when designing, these terms are important for understanding the GameplayAbility interaction via tags. As a consequence, an:
activated/executed GA may block/cancel other GAs (via adding tags)
deactivated GA may unblock other GAs (via removing tags)
active/executing GA must be able to receive a block/cancel via tag changes, when another GA is executed
Conclusion
To make best usage of tags for controlling the interaction between GameplayAbilities, keep the following in mind: A GameplayAbility is
activated/executed when CallActivateAbility() is called (in blueprint, the Event ActivateAbility and Event ActivateAbilityFromEvent are triggered by that function via ActivateAbility()).
deactivated when EndAbility() is called (which is also called by CancelAbility()).
active/executing between the calls of UAbilitySystemComponent::TryActivateAbility() until EndAbility().
In case that EndAbility() is not called, the GA is executing for the lifetime of ActivateAbility() (again, in blueprints this is almost similar to the lifetime of the implemented Event ActivateAbility and Event ActivateAbilityFromEvent).
Explanation
When a GA is considered activated/executed and deactivated (1, 2)
UAbilitySystemComponent::ApplyAbilityBlockAndCancelTags() triggers GAs to be cancelled or blocked/unblocked. Therefore calls to it define the moment of activate/execute and deactivate.
Block/cancel are called by PreActivate() which is called by CallActivateAbility()
Unblock is called by EndAbility() (which is also called by CancelAbility())
When a GA is considered active/executing (3)
When it can be blocked
A GA can be blocked only during its activation. CanActivateAbility() checks (via DoesAbilitySatisfyTagRequirements()) the blocked tag list of the GameplayAbilitySystemComponent (ASC) (UAbilitySystemComponent::BlockedAbilityTags). If one of the tags is present there, the ability activation is aborted.
and when it can be cancelled (unregarded the fact if the GA allows it)
A GA can be cancelled by other GAs via tags as long as it is registered in the GameplayAbilitySystemComponent (ASC) in UAbilitySystemComponent::ActivatableAbilities and as long as that stored GA spec returns FGameplayAbilitySpec::IsActive() = true.
It gets added to that container via UAbilitySystemComponent::GiveAbility() and removed via UAbilitySystemComponent::ClearAbility()
FGameplayAbilitySpec::IsActive() will return true, as long as FGameplayAbilitySpec::ActiveCount > 0. This variable will be incremented upon GA activation (in UAbilitySystemComponent::InternalTryActivateAbility()) and decremented upon GA deactivation (in UAbilitySystemComponent::NotifyAbilityEnded).
UASC::InternalTryActivateAbility() is called in UASC::TryActivateAbility() and UASC::NotifyAbilityEnded() is called in EndAbility(). These two conditions are the reason that I considered a GA only as active/executing between those calls instead of between UASC::GiveAbility() and UASC::ClearAbility().
How those tags are triggered
When a GA is activated/deactivated, it triggers functions in the GameplayAbilitySystemComponent (ASC):
For un-/blocking
UAbilitySystemComponent::ApplyAbilityBlockAndCancelTags calls ...
UAbilitySystemComponent::BlockAbilitiesWithTags() respectively UAbilitySystemComponent::UnBlockAbilitiesWithTags(), which (finally) call for each of the tags in its list UAbilitySystemComponent::BlockedAbilityTags ...
FGameplayTagCountContainer::UpdateTagMap_Internal(), which adds respectively removes the tag
For cancelling
UAbilitySystemComponent::CancelAbilities() which compares the tags provided by the cancelling GA with the tags of all activateable abilities stored in the Ability System Component (in UAbilitySystemComponent::ActivatableAbilities()), which are currently active.
If there is a match, all of those GA instances are cancelled.
What about CommitExecute()
That function is independent from interacting with other GAs via tags, so the Execute part of the name can be misleading.
CommitExecute() is called only if the costs of the GA can be afforded and if the GA is not on cooldown (all of that happens in CommitAbility()). But blocking/cancelling other GAs already happened before and unblocking GAs also happens independently from that function.
So what about CommitAbility()
For an executing GA, it doesn't matter, if this is being called.
If CommitAbility() fails, the GA might be deactivated immediately after being activated, depending on the implementation of the GA. So it can have an influence on the execution duration, which however is unimportant for the design process of the GAs interaction via tags.
What about SetShouldBlockOtherAbilities()
This public function can be called to un-/block other GAs via tags from an arbitrary place in C++/blueprints.
E.g. it could be called several times during the lifetime of ActivateAbility() to un-/block other GAs. Furthermore, it is not able to cancel other GAs. It is not clear what are the best practices for using or avoiding this function. It seems to lower the transparency of GA interaction via tags.
(if no parent namespace is present, all functions are members of UGameplayAbility)
Other ways to block/unblock GAs (e.g. via inputID) or cancelling GAs (e.g. via UAbilitySystemComponent::CancelAllAbilities()) are not considered. This is about GA interaction via tags. Also triggering GAs via tags (or GameplayEvents) is another topic.
It would be nice if a designer of the Unreal GAS could clarify things, correct incomplete conclusions or leave some words about best practices.
This is sort of a follow up to an earlier question at Scala variable binding when used with Actors
Against others' advice, I decided to make a message containing a closure and mutate the variable that closure is closed under between messages.. and explicitly wait for them.
The environment is akka 1.2 on scala 2.9
Consider the following
var minAge = 18
val isAdult = (age: Int) => age >= minAge
println((actor ? answer(19, isAdult)).get)
minAge = 20
println((actor ? answer(19, isAdult)).get)
The message handler for answer essentially applies isAdult to the first parameter (19).
When actor is local, I get the answers I expect.
true
false
But when it is remote, I get
false
false
I am simply curious why this would be the behavior? I would have expected consistent behavior between the two..
Thanks in advance!
Well, you have come across what may (or may not) be considered a problem for a system where the behaviour is specified by rules which are not enforced by the language. The same kind of thing happens in Java. Here:
Client: Data d = rmiServer.getSomeData();
Client: d.mutate()
Do you expect the mutation to happen on the server as well? A fundamental issue with any system which involves remote communication, especially when that communication is transparent to a client, is understanding where that communication is occurring and what, exactly, is going on.
The communication with the actor takes the form of message-passing
An effect can pass a boundary only by the mechanism of message-passing (that is, the effect must reside within the returned value)
The actor library may transparently handle the transmission of a message remotely
If your effect is not a message, it is not happening!
What you encounter here is what I would call “greediness” of Scala closures: they never close “by-value”, presumably because of the uniform access principle. This means that the closure contains an $outer reference which it uses to obtain the value of minAge. You did not give enough context to show what the $outer looks like in your test, hence I cannot be more precise in how it is serialized, from which would follow why it prints what you show.
One word, though: don’t send closures around like that, please. It is not a recipe for happiness, as you acknowledge yourself.