In my HubNet application each client has access to a slider which he or she can use to guess the answer to questions. I use the command
set slider-value 0
in order to reset the slider between questions. However, this only seems to set the global variable associated with the slider to 0, not the slider that the participant manipulates. How do I change the slider itself (from the server)?
It is of course very confusing for the participant as is since if he or she hits the guess button before she has moved the slider her guess will equal the global variable whatever the slider is currently set to.
I think that one reason for the confusion here is that the HubNet system is a "thin" or "dumb" client system.
In particular, the client does not have any awareness of the meaning of its interface elements. So, your idea (of updating the variable on the NetLogo server and expecting that the clients would be notified that the interface element that corresponds to this variable [its meaning] would be updated).
Instead, your NetLogo model needs to manage the meaning and its implications. So, the "slider-value" variable changes. And then the host needs to tell the clients to update their interface elements. You would do this by issuing a hubnet-send command.
For example, suppose the HubNet client was called "joe", the slider in the client interface is called "my-slider", and the relevant variable is, as you say, slider-value You would then write
hubnet-send "joe" "my-slider" slider-value
Normally, in HubNet models, there is a breed of turtles that is associated with clients (say "students" or "clients"), and these clients have a variable that keeps track of the HubNet client's identifier (say this variable is "my-id"). Then, to update ALL of the clients' sliders at once, you would say...
ask clients [
hubnet-send my-id "my-slider" slider-value
]
Related
This is about an API handling the validation during saving an object. Which means that the front-end client sends a request to the API to a specific end point, then on the back-end the API creates a new object if the right conditions are meet.
Right now the regular method that we use is that the models has a ruleset for each fields and then the validation is invoked when the save function is invoked, but technically the validation is done right before the object is saved into the database.
Then during today's code review I came across a solution which I wasn't sure if it's a good practice or not. And it was about that the front-end must send a specific parameter to the API every time. This is because other APIs are using our API as well, and we needed to know if the request was sent as and API request or a browser request. If this parameter is present then we want to execute an extra validation function on a specific field.
(1)If I would have to implement it, then I would check the incoming parameter in the service handler or in the controller level, and if I got one, I would invoke the validation right away, and if it fails I would throw an error.
(2)The implementation I saw however adds an extra variable to the model, and sets the model variable when there is an incoming parameter, then validates only when the save function is invoked on the object(which first validates the ruleset defined on the object fields, then saves the object into the database)
So my problem with (2) is that the object now grown bigger with an extra variable that is only related to a specific event. So I would say it's better to implement (1). But (2) also has an advantage, and that is when you create the object on different end point by parsing the parameters, then the validation will work there as well, even if the developer forget to update the code there.
Now this may seems like a silly question because, why would I care about just 1 extra variable, but this is like a bedrock of something good or bad. So if I say this is ok, then from now on the models will start growing with extra variables that are only related to specific events, which I think should be handled on the controller/service handler level. On the other hand the code would be more reliable if it's not the developer who should remember all the 6712537 functionalities and keep them in mind when makes some changes somewhere. Let's say all the devs will get heart attack tomorrow from the excitement of an amazing discovery, and a new developer has to work on the project while he doesn't know about these small details, and then he has to change something on the code that is related to this functionality - so that new feature should be supported by this old one as well.
So my question is if is there any good practice on this, and what do you think what would be the best approach?
So I spent some time on thinking on the solution, and I think the best is to have an array of acceptable trigger variables in the model class. Then when the parameters are passed to the model on the controller level, then the loader function can be modified that it takes the trigger variables from the parameters and save it in the model's associative array variable that stores the trigger variables.
By default this array is empty, and it doesn't matter how much new variables are needed to be created, it will only contain the necessary ones when those are used.
Then of course the loader function needs to be modified in a way that it can filter out the non trigger variables as well as it is done for the regular fields, and there can be even a rule set of validation on the trigger variables if necessary.
So this solves the problem with overgrowing the object with unnecessary variables and the centralized validation part, because now the validation can be always done in the model instead of the controller.
And since the loader function is modified to store the trigger variables in the model's trigger variables array variable, the developer never has to remember that this functionality was created. Which is good, because in the future when he creates a new related function or end point that should handle object creation, he will not miss it to validate it against the old functionality, because the the loader function that he modified in the past like this will handle it for him.
It needs to be noted tho, that since the loader function doesn't differentiate between the parameters, and where to load them other then checking the names of the parameters with the filter functions, these parameter names should be identical from each other, otherwise a buggy functionality can be created accidentally. Like if you forget that a model attribute with the same name was used, then you can accidentally trigger an event that was programmed to be triggered if the trigger variable with the same name is present. However this can be solved by prefixing the trigger variables for example.
I am an Engineering Student and as part of my diploma thesis, I am simulating the passenger changeover process in metros using the Anylogic Pedestrian Library.
In the simulation, it often happens that standing passengers "leave" the standing area and somehow get into the sitting places, blocking the way from other peds that would like to occupy the seat.
All passengers come from the Passenger Agent, where they have a boolean variable wantToSit. If wantToSit = false, they are routed into the standing area, with wantToSit = true they go to take their seats.
Now, I would like to restrict the access of peds with wantToSit = false into the area drown using polygonal nodes around the seat groups, so that the phenomenon written above cannot occur, thus only sitting passengers will enter this area.
However, when I try to define the condition for the access restriction in the polygonal Node, I always get the error "... cannot be resolved to a variable".
Here is the variable from the Agent "Passenger":
On the Agent "Main", where the Polygonal Node is, the auto code complete does not recommend anything for want or for ped. . For the word Passenger, see the picture below:
Is there a way to use the access restriction feature in this case? I don't know how to access this parameter of Passenger from Main, which is a different agent.
Thank you in advance for your help!
If you do the code complete action in the condition field before you type anything, you will see that the local variables available for you to use in the condition field is agent and self
And then if you choose agent you will see that the fields within your custom Pedestrian agent will become available.
Try not to type anything without code complete. It can save you a lot of time.
I´ve been looking around the Internet for a week trying to discover a useable function that I can use to change a players name in my Plugin, and since most information is waaaaay to old, I was unsuccessful to find anything.
This is what I have tried already:
player.setCustomName(args[0]);
player.setDisplayName(args[0]);
player.setPlayerListName(args[0]);
getConfig().set(player.getName(),args[0]);
Its not like I receive a Error or something, its just that not much happens to the player names (but the function is actually called, I checked).
Simply, you cannot change your full name that you entered in the client settings.
These methods you are trying to use will only change the name of the in-game server for the player object. These also affect the names of the chat, tablist and possibly scoreboard teams. There is a solution that can be used to change the player name for a given player in half, but it will not affect other servers or the client either. Using GameProfile from Mojang, you can change its name and UUID, but this requires creating a new instance and adding it to the existing PlayerInfoData list. If you don't have Spigot/Paper or some software attached to your project, you'll need to use Java Reflections to modify the values/list and everything else, especially in PacketPlayOutPlayerInfo. Or, if you want to avoid Java Reflections, you can use the PlayerProfile interface implemented by Paper, using the Player#getPlayerProfile method.
An example code using Reflections:
Player player = ...; // Your player object here
GameProfile gameProfile = new GameProfile(player.getUniqueId(), "newPlayerNameHere");
// packet is the new instance of PacketPlayOutPlayerInfo
// infoList is the list retrieved from PacketPlayOutPlayerInfo
// playerInfoDataConstr is the PacketPlayOutPlayerInfo constructor
// ping is the amount of ping the player have currently
// gameMode is the EnumGameMode object of the player
// text is the text parsed to IChatBaseComponent
((List<Object>) infoList.get(packet)).add(playerInfoDataConstr.newInstance(packet, gameProfile, ping, gameMode, getAsIChatBaseComponent(text)));
// Send the packet object to every online player on the server
For accessing to GameProfile class you'll need com.mojang.authlib dependency.
Using Paper API is kinda easy to implement.
I have to create a particular simulation for a college project. The simulation should feature several mobile nodes cyclically switch between 802.11 access point and station modes. While in station mode, nodes should read the SSIDs of access points around them, and then they should change their SSID in AP mode accordingly. There is no need for connections or data exchange between the nodes beside the SSID reading.
Now, I've been through Omnet/Inet tutorials/documentation (all two of them), and I feel pretty much stuck.
What I could use right now is someone confirming my understanding of the framework giving me some directions on how exactly I should proceed.
From what I understand is Inet does not implement any direct/easy way to do what I'm trying to do. Most examples have fixed connections declared in NED files and hosts with a fixed status (AP or STA) defined in the .ini file.
So my question is basically how do I do that: do I need to extend a module (say, wirelessHost), modifying its runtime behaviour, or should I implement a new application (like UDPApp) to have my node read other SSIDs and change his accordingly? And what is the best way to access an host's SSID?
You may utilize two radios for each mobile node e.g. **.mobilenode[*].numRadios = 2 (see also example in /inet/examples/wireless/multiradio/).
The first radio operates as AP **.mobilenode[*].wlan[0].mgmtType = "Ieee80211MgmtAPSimplified" which has to adapt its SSID.
The second radio serves as STA **.mobilenode[*].wlan[1].mgmtType = "Ieee80211MgmtSTA". Now, you have to sub-class Ieee80211AgentSTA which handles the SSID scanning procedure and has to change the first radio's SSID upon new SSID detection. Then you utilize the adopted sub-class within the simulation. Finally, active scanning has to be activated **.mobilenode[*].wlan[1].agent.activeScan = true.
First, thanks for any advice. I am new to all of this and apologize for any obvious blunders.
Second, the question:
In an interface for entering clients that often possess a number of roles, it seemed efficient to create a set of inputs which possessed both visual characteristics and associated data binding based simply on the inputs name.
For example, inquirerfirstname would be any caller or emailer who contacted our company.
The name would dictate a label, placeholder, and the location in firebase where the data would be stored.
The single name could be used--I thought--with a relational table (state machine or series of nested ifs) to define the properties of the input and change its outward appearance and inner bindings through property manipulation.
I created a set of nested iffs, and console logged the property changes in the inputs, but their representation in the host element (a collection of inputs that generated messages to clients as well as messages to sales staff) remained unaffected.
I attempted using the ready callback. I forced the state change with a button.
I was unable to use the var name = new MyInput( name). I believe using this method would be most effective but am unsure how to "stamp" the JavaScript into a heavyweight stamped parent element.
An example of a more complicated and dynamic use of a constructor and a factory implementation that can read database (J-son) objects and respond to generate HTML elements would be awesome.
In vanilla a for each would seem to do the trick but definitions and structure as well as binding would not be organic--read it might be easier just to HTML stamp the inputs in polymer by hand.
I would be really greatful for any help. I have looked for a week and failed to find one example that took data binding, physical appearance, attribute swapping, property binding and object reading into account.
I guess it's a lot, but each piece independently (save the use of the constructor) I think I get.
Thanks again.
Jason
Ps: I am aware that the stamping of the element seems to preclude dynamic property attribute and binding assignments. I was hoping a compute attribute mixed with a factoryimpl would be an option (With a nice example).