Bukkit saves automatically every few minutes, and also saves when it shuts down.
I need a way to not save the chunks, because I'm in need of a system to make my minigame map to be completely fresh when the server restarts, for another round of the minimap.
What I tried to do:
Setting the save-automatically off in the server.properties;
Running the following to try to shutdown without saving:
Bukkit.getServer().unloadWorld(getServer().getWorlds().get(0), false);
Bukkit.shutdown();
What you have tried is the correct way to do this.
The problem is that you cannot unload default worlds (which are the Overworld, the Nether and the End).
You have to create a new one.
You need a WorldCreator object.
WorldCreator seed = new WorldCreator("arena");
World arena = seed.createWorld();
This is a custom world: regions are saved (if not set otherwise) but Bukkit will not know about it after the server restarts.
So you must run the code above the first time to generate the files, then to load them from disk if found.
Related
I am currently streaming information in the form of a String from an Arduino to an Android application via Bluetooth. My application currently just displays the data on a series of progress bars as the values come in. I would like to store the data as it comes in to be viewed later but am unsure as to how to achieve this.
I have a BluetoothActionListener which runs when new data is available. This is called up to 20 times per second so I am worried as to whether adding a memory save to a file within this function will have an effect on its performance.
The data arrives as a string via bluetooth and I would like to be able to store the entire session's worth of data (upto 10mins) in the same file on a different line. A simple text file with a timestamp on each line is sufficient.
Would using a internal/external memory write cause my foreground visuals to slow down or even become unresponsive, as each new string arriving causes each of the progress bars to update?
At twenty times a second? Probably not. Just keep the file open rather than closing it, and flush it every few writes.
I'm trying to switch my server over to a new mod pack, while keeping player inventory and a few other aspects of playerdata. I want to be able to transfer a player from one server to another, while resetting their location data. Are there specific tools I use to view and edit these values, and which files specifically under the playerdata folder would contain them?
To clarify, When their location data is reset I would like them to go to spawn. If it wont default, then entering a value will be a little more work, but sufficient.
I've already transferred the playerdata into my new world file. I plan in switching the server every-so-often and allowing these item transfers quite abit, so I need to know for the future how to solve this without requiring all of my players to be coordinated during the transfer.
Minecraft 1.7.6 or newer (UUID)
On Minecraft 1.7.6 and above, Mojang uses a new UUID format. Use a UUID lookup tool, like http://minecraft-techworld.com/uuid-lookup-tool to determine the UUID of the player you wish to reset.
Make sure that the player you wish to reset is logged out of the server.
Use FileZilla to connect to the server FTP.
On the remote site, open the game folder.
Open the world folder. It is usually world, unless you have changed it.
Open playerdata.
Simple: Delete, or download/rename and then delete, uuid.dat. Replace uuid with the UUID that you looked up.
Advanced: Instead of deleting uuid.dat, download it to a location on your computer such as your desktop where you can easily find it.
From NBTExplorer, press the "Open NBT Data Source" button that looks like a folder.
Navigate to where you saved the uuid.dat file, select it, and press open.
Scroll down untill you find the tag labeled "Pos" with 3 entries and press the "+" symbol next to it. These are the data tags that store where a player is in game.
Double click on the tags one at a time and change their values. The tags aren't labelled, but they are X, Y, Z in that order. Y is height. Be careful what you set these numbers to as you can cause a player to spawn in the ground. I suggest setting their value to your world's spawn or a known safe coordinate location.
Upload the uuid.dat back to your server in the same place you got it. Overwrite or delete the original one. Make sure that the player in question is not online at the time or it won't work.
SOURCE
You can write a plugin,
which can get all offlinePlayers() and then use a for to iterate the array to set the spawnlocation to the new one on the other pack.
This you can trigger with a cmd which you code for it.
I'm developing a sort of parking meter counter app for a few specific locations. The app asks the user where he is (dropdown menu, saves column letter and number, like A6) and then shows a screen with the given location, a timer (chronometer class) counting up from 0 and the price that has to be paid on exit (calculated using elapsed hours * base price).
This all works nicely, until the user or the OS kills the app (task manager or memory management). Then, the next time the user opens the app, he's back at the main menu and his location, time and price has been lost.
I need a way to save all of the user's information and be able to load it up on app restart.
Initially I had thought to save the user's location and the exact time the chronometer started (DateTime.Now() maybe?) to a .txt file in the internal storage so that it would read:
mallname,columnLetter,columnNumber,startTime
This way, if the app is killed, or any time the app is started up from scratch, the MainActivity will first check if a file.txt exists in the app's internal storage, if it does, it immediately starts the lastPage activity, reading the .txt file to pass the values as parameters (thus, the comma separation). If there's no such file, it would just carry on normally. The last page does contain a reset button that would delete the file so that the app can start up normally the next time it's used.
I don't know how efficient this method is, but it's the first thing that came to mind. However, I don't know how to go about this. I have this same exact method programmed in C# for Windows Phone, but I don't know how to translate it into Java for Android. Also, in C# I didn't actually use a chronometer, rather, I had the startTime saved and used a timer that would calculate startTime - DateTime.now() on every tick (every second) and update the textBlock to show this.
Any help would be greatly appreciated.
Usually user data should be saved to a SQLite database, however in your case, since you're talking about a few variables, it'd be much easier for you to save these values in the application's SharedPreferences.
For every value you'd like to save, add this line to your Chronometer's onChronometerTick() method:
PreferenceManager.getDefaultSharedPreferences(this).edit().putInt("your_key", <Your_value>).commit();
This can later (whenever your application recovers from a crash, for example) be retrieved by:
PreferenceManager.getDefaultSharedPreferences(this).getInt("your_key", <Default_value>);
Regarding performance issues, if your Chronometer ticks once every second this should have no effect on your app's performances and is completely acceptable.
I have a group of nodes who send measurements to a bootstrap server. In the end I want the bootstrap server to sum all the measurements and write it to a file. One way to do that is to over-write the data to the file each time a measurement message is received(after summing up the current measurements). But this would be very inefficient. I want to store the measurement data and write it to file only once after the simulation is completed.
But the problem is that the simulator code that I am using is not under my control, its a library that I am using. So, I cant tell when exactly the simulation is going to end (and hence I cant tell which measurement message will be the last one).
I naively tried to store the measurement data in a static class but this data is not accessible when the simulation terminates. Is there any other way that I can do this ?
Thanks,
I would find the last message using a timeout.
Write to disk if you have new data but you haven't got anything for a while e.g. a second.
If you cannot store the data you need in the process (which it seems you can't, since the static class failed), you need to persist the data some other way. To an on-disk file is one option, and another common one would be to a database.
here's the situation.
In a Java Web App i was assigned to mantain, i've been asked to improve the general response time for the stress tests during QA. This web app doesn't use a database, since it was supposed to be light and simple. (And i can't change that decision)
To persist configuration, i've found that everytime you make a change to it, a general object containing lists of config objects is serialized to a file.
Using Jmeter i've found that in the given test case, there are 2 requests taking up the most of the time. Both these requests add or change some configuration objects. Since the access to the file must be sinchronized, when many users are changing config, the file must be fully written several times in a few seconds, and requests are waiting for the file writing to happen.
I have thought that all these serializations are not necessary at all, since we are rewriting the most of the objects again and again, the changes in every request are to one single object, but the file is written as a whole every time.
So, is there a way to reduce the number of real file writes but still guarantee that all changes are eventually serialized?
Any suggestions appreciated
One option is to do changes in memory and keep one thread on the background, running at given intervals and flushing the changes to the disk. Keep in mind, that in the case of crash you'll lost data that wasn't flushed.
The background thread could be scheduled with a ScheduledExecutorService.
IMO, it would be better idea to use a DB. Can't you use an embedded DB like Java DB, H2 or HSQLDB? These databases support concurrent access and can also guarantee the consistency of data in case of crash.
If you absolutely cannot use a database, the obvious solution is to break your single file into multiple files, one file for each of config objects. It would speedup serialization and output process as well as reduce lock contention (requests that change different config objects may write their files simultaneously, though it may become IO-bound).
One way is to to do what Lucene does and not actually overwrite the old file at all, but to write a new file that only contains the "updates". This relies on your updates being associative but that is usually the case anyway.
The idea is that if your old file contains "8" and you have 3 updates you write "3" to the new file, and the new state is "11", next you write "-2" and you now have "9". Periodically you can aggregate the old and the updates. Any physical file you write is never updated, but may be deleted once it is no longer used.
To make this idea a bit more relevant consider if the numbers above are records of some kind. "3" could translate to "Add three new records" and "-2" to "Delete these two records".
Lucene is an example of a project that uses this style of additive update strategy very successfully.