I'm currently working on a training plugin, where every player would get his own region, to learn bridge for example. So when a player joins, the plugin should automatically generate a new area for this player and delete it when he leaves.
I've created a SetupCommand where you have to set the start and end of the region that should be copied.
Now the only thing to do is copy the region and teleport the player to it, however, I couldn't find any good ways to do that. The only solution I found so far is to loop through all blocks and copy them one by one. But I can imagine that this is not the best solution and would cause lag, not only server-side but also client-side.
Are there better ways to clone a region than that?
I've read you should use Schematics but they weren't going into detail.
If you are experienced with java and feel comfortable about your skills you can try to get the blocks in the list as List and save it as base64 into your database or whatelse. You can parse it everytime back into a list of blocks and replace it. I would rather recommend you to make a custom block class with implements Serializeable and then add some values like Location, Material and BlockData to it.
Use FAWE or WorldEdit to copy/paste sections
If you use Block#setType, performance will be very slow, so if you don't want to use the API, you should use NMS, but using NMS is not a good practice.
Disadvantages of NMS:
Most nms methods are obfuscated. In one version the method is called f(), in the next version maybe c().
How to copy/paste with FAWE:
https://www.spigotmc.org/threads/how-to-paste-a-schematic-with-fawe.402950/
How to copy/paste with worldedit:
https://www.spigotmc.org/threads/worldedit-api-schematic-copy-save-load-and-paste.498476/
In conclusion, it is recommended to use the API
Related
I have been coding in java for about a year and a half, and have made some small games and programs that I think turned out very well. The problem is that I am mostly self taught and I most of my code and class structure is not organized or "correctly structured". This didn't matter to me for the smaller things I made, but if I were to take on a larger project I would want to structure it correctly and make it organized.
In a previous mini-RPG game I had
Main Class (Main loop + Main method)
Player Class (containing player position and player stats)
Engine Class (containing map and collision detection between player and map
Map Class (containing map data)
My Main class contained an instance of Player and of Engine, and Engine had an instance of Map. The problem is that Player then could't tell the Engine where it was, and the Engine couldn't adjust Player's position and stats when something happened on the Map. So I ended up having some static variables and methods in both Player and Engine to get them to communicate.
I guess my overall question is is this the correct structure of classes, and is it correct to use static methods and variables here? If not, how would you structure these classes, or would there need to be more or less classes?
My overall objective is to understand how to structure classes in this previous game so I can better structure classes in a bigger project I want to take on.
It is a rather broad question, but the general answer is no.
As a rule you shouldn't use static fields to connect instances. (There are a couple of possible exceptions, but as a rule of thumb it's a useful one.) The basic idea of OOP is that everybody has a reference to whoever they want to send messages to. So if a Player needs to tell the Engine something, it should have a reference to whichever Engine instance it belongs to. Or you can redesign your architecture so only Engine sends messages to Map and Player, it's difficult to tell without more detail about your setup whether that would be appropriate in this case.
Another piece of general advice is to try to sit down with a piece of paper, write down the name of all three of your classes and in a separate column write down all the things the system has to do. And then you should try to figure out who's responsible for what. In a good design this decision is simple, if you find yourself shoehorning different things into one class, that's a sign that you should maybe need a more detailed model with more classes.
I would also suggest you take a look at the observer pattern and the publish-subscribe pattern, as it might be what you need.
Try take take a look at some design-patterns.
Which design pattern you want to use depends on what you prefer. Some can be found here on Wikipedia.
I also take it that you are familiar with OOP? Some more general info can be found here on Wikipedia.
Looking at your specific story, I think a MVC-design would be a nice solution.
MVC meaning Model View Controller.
Here you have your Model, classes holding different forms of data.
Your Controller, controls your Model, contains all the real logic.
And your View, this is the graphic end of your application.
You'd probably want to put and instance of your player in your engine as well. That way your engine will control everything (the player and the map). Hope that helps!
From what you described there a few possible ways to handle this. One would be to use a messaging system. I would look into Java Messaging Service (JMS). Another would be to make your app event drive. Here is a neat little tutorial on how to do this using spring : https://spring.io/guides/gs/messaging-reactor/. Having said that, if your intent is get a better understanding of problem solving using Java, I would first try and mimic these two approaches on your own, without any bulky frameworks.
As far as I know Stream API is intended to be applied on collections. But I like the idea of them so much that I try to apply them when I can and when I shouldn't.
Originally my app had two threads communicating through BlockingQueue. First would populate new elements. Second make transformations on them and save on disk. Looked like a perfect stream oportunity for me at a time.
Code I ended up with:
Stream.generate().flatten().filter().forEach()
I'd like to put few maps in there but turns out I have to drag one additional field till forEach. So I either have to create meaningless class with two fields and obscure name or use AbstractMap.SimpleEntry to carry both fields through, which doesn't look like a great deal to me.
Anyway I'd rewritten my app and it even seems to work. However there are some caveats. As I have infinite stream 'the thing' can't be stopped. For now I'm starting it on daemon thread but this is not a solution. Business logic (like on connection loss/finding, this is probably not BL) looks alienated. Maybe I just need proxy for this.
On the other hand there is free laziness with queue population. One thread instead of two (not sure how good is this). Hopefully familiar pattern for other developers.
So my question is how viable is using of Stream API for application flow organising? Is there more underwather roks? If it's not recomended what are alternatives?
This is one of the questions that involves crossing what I call the "Hello World Gulf" I'm on the "Hello world" I can use SQLite and Content Providers (and resolvers) but I now need to cross to the other side, I cannot make the assumption that onUpgrade will be quick.
Now my go-to book (Wrox, Professional Android 4 development - I didn't chose it because of professional, I chose it because Wrox are like the O'Reilly of guides - O'Reilly suck at guides, they are reference book) only touches briefly on using Loaders, so I've done some searching, some more reading and so forth.
I've basically concluded a Loader is little more than a wrapper, it just does things on a different thread, and gives you a callback (on that worker thread) to process things in, it gives you 3 steps, initiating the query, using the results of the query, and resetting the query.
This seems like quite a thin wrapper, so question 1:
Why would I want to use Loaders?
I sense I may be missing something you see, most "utilities" like this with Android are really useful if you go with the grain so to speak, and as I said Loaders seem like a pretty thin wrapper, and they force me to have callback names which could become tedious of there are multiple queries going on
http://developer.android.com/reference/android/content/Loader.html
Reading that points out that "they ought to monitor the data and act upon changes" - this sounds great but it isn't obvious how that is actually done (I am thinking about database tables though)
Presentation
How should this alter the look of my application? Should I put a loading spinning thing (I'm not sure on the name, never needed them before) after a certain amount of time post activity creation? So the fragment is blank, but if X time elapses without the loader reporting back, I show a spiny thing?
Other operations
Loaders are clearly useless for updates and such, their name alone tells one this much, so any nasty updates and such would have to be wrapped by my own system for shunting work to a worker thread. This further leads me to wonder why would I want loaders?
What I think my answer is
Some sort of wrapper (at some level, content provider or otherwise) to do stuff on a worker thread will mean that the upgrade takes place on that thread, this solves the problem because ... well that's not on the main thread.
If I do write my own I can then (if I want to) ensure queries happen in a certain order, use my own data-structures (rather than Bundles) it seems that I have better control.
What I am really looking for
Discussion, I find when one knows why things are the way they are that one makes less mistakes and just generally has more confidence, I am sure there's a reason Loaders exist, and there will be some pattern that all of Android lends itself towards, I want to know why this is.
Example:
Adapters (for ListViews) it's not immediately obvious how one keeps track of rows (insert) why one must specify a default style (and why ArrayAdapter uses toString) when most of the time (in my experience, dare I say) it is subclasses, reading the source code gives one an understanding of what the Adapter must actually do, then I challenge myself "Can I think of a (better) system that meets these requirements", usually (and hopefully) my answer to that converges on how it's actually done.
Thus the "Hello World Gulf" is crossed.
I look forward to reading answers and any linked text-walls on the matter.
you shouldnt use Loaders directly, but rather LoaderManager
I'm having a bit of trouble figuring this out so if you can help that would be great.
I have written a bit of code that gets a list of URLs from a sitemap. I then go each page, scrape all the links, and then test their status(200,404, etc).
I am using HttpClient. I have it all working OK but as I am new to Java I reckon my code is a complete hack/maze and I could most likely get far better performance if it was organised correctly. So what I have is
Main class - This builds the gui
Parse the sitemap class - This parses the sitemap and get a list of the urls.
Class called PingURl - I'm sure my above is poor but this is the bit I reckon is worst. This class opens all the urls, scrapes them for links, then tests the links for their status and returns it. I presume this class should be broken down? Most importantly I think I should be isolating the testing of the links in it's own class, so it would be easy to implement threads later on?
Basically I'm looking for advice. If someone could help me with laying out the project a bit better. Secondly I believe this is my weakest area so to improve I need to learn more about this, I don't even know what to call this(design/layout problem?). Can you also recommend resources to learn more about this?
Java is a language which IMO, embodies good OO design. Designing with OO in mind is very effective.
http://java.sun.com/developer/onlineTraining/Programming/BasicJava2/oo.html
In terms of your problem, I think it works pretty well. You are kind of following a Model-View-Controller pattern: http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html
I can't tell you how to design your code, but I will tell you how I would do it if I were presented with the same problem:
I would get a class to represent a hyperlink. In that class there would be the hyperlink that has been scraped, and a getter and setter. As well as a boolean value and a ping function. That means that if I create a "hyperlink" object, then I can invoke ("ping") on that object because it is part of that class. That means that the ping function simply sets the boolean that represents connectivity.
That way, your parser basically gets a page, and for each link it finds, it creates a new "hyperlink" object based on your own "hyperlink" class. And puts it in an array. So once your parser executes you get an array of pointers to hyperlinks.
Then all you have to do is invoke the ping function on each one to see if it is there.
I think this design is the best because it scales from doing one hyperlink test to doing 1000 quite easily.
There is soooo much stuff out there about design, there are countless principals as well. There is never one absolute way to solve a problem. But the more experience you get, and the more you read up on design patterns and models the better you will get at it :)
This is somewhat of an open question.
I'm in the process of developing a simple game for android and I've gotten to the point where I'm trying to enable thee user to save their progress and return later.
As i'm a beginner, I'm not exactly sure where to start, so I was hoping some of you might have at least some suggestions.
A little info on the setup of the game:
All animation is done in a thread through a canvas and alternation of stored bitmap frames based on a 30 ms loop.
Everything is an object, the characters, the background is simply a 2d array of objects. and each object is generally referenced and created dynamically through a hashmap.
Now how to save? I know I could brute force it, and simply save coordinates and current actions blah blah etc. etc. for each object in each map.
But is there a better way to do this? I've briefly read that in python there's a method of sterilizing objects called "pickle," and there is something similar called "kryo." Am I looking in the right direction?
You should look into Java serialization. It's not perfect, it has problems, but it's the safest, quickest way to turn a complex tree of objects into something that you can save to a file or a db, and load it back when you need.
Else, there's always the possibility to use your own specific serialization using INSERT SQL queries, etc. But be very careful, it's easy to miss parts of what you want to save / restore. One example of that would be to turn your objects tree into XML and save that XML as a file. There are very good 3rd-party libs to map objects to XML and back in Java.
Well.. That's not STERILIZATION, but SERIALIZATION.. Which is a programming technique. And serialization is also the technique you want to use.
Doesn't matter if you use a predefined method or something you write on your own, but the only thing that matters is to loop across the objects and write to the file (or saving structure) the date you need to be later reloaded.
Anyway yes, you're looking the right way.
The best way to do it is implementing a serialization interface. Each object for which the serialize() method is called must save it's data and then call the serialize() method for each child object it owns.