Innectis Community Forum
Innectis - Minecraft Server => Suggestions => Topic started by: ArronM on October 24, 2011, 12:31:11 PM
-
Lately people have been making drop's that will kill ya :(, but then when people get in their houses they decide to abuse it. However that is not my case. I want to make locked buttons to make a SECURE train line AKA making it not possible for people to get into my lot via a train line unless they have permisson on the button which controls the piston to put the track in place.
-
I would like this idea if it was a lot flag that could be turned on/off. (Flag = Switches ?)
-
I want to make locked button...making it not possible for people to [use]...unless they have permisson on the button.
Great idea. I'd love to see it implemented similarly to how chests work. And also this, so that the whole thing can be turned on/off on a global scale for each lot.
I would like this idea if it was a lot flag that could be turned on/off. (Flag = Switches ?)
Flag = NoSwitches would make more sense; you'd want others to be able to use them by default.
-
Put the button behind an iron door
-
The thing you have to think is if you protect all buttons then you have lots of space in the IDP Database taken up from just buttons. Some contraptions can easily have 10+ Buttons & Leavers without trouble. If you track all these then the database will just explode with entries and IDP Will become Real slow.
Put the button behind an iron door
Is the best idea.
-
But opening a door while ur on a track is quite tricky
-
Hop out of the cart
-
If you track all these then the database will just explode with entries and IDP Will become Real slow.
Not if it was designed correctly.
A simple table like so in mysql (excuse my pseudo-text/code):
locked_mechanical_items {
id int(11) PRIMARY auto_increment; // unique id
x int(11) INDEX; // location of button/switch
y tinyint(3) INDEX; // location of button/switch
z int(11) INDEX; // location of button/switch
owner_id int(11) INDEX; // id of owner, assuming IDP has a table like that
type_id int(11) INDEX; // item id, allowing button/switch/etc.
date_placed DATETIME INDEX; // when this item was placed in the world, or added to the table
date_lastused DATETIME INDEX; // when this item was last used successfully
lastuser_id INDEX; // who last used this item successfully
}
// note: I have an index on all the fields above so that:
// - you can search by the id itself
// - you can search by xyz location
// - you can search by who own's what
// - you can search for what item id's are where
// - you can search for when an item was placed or used
// - you can search for who last used an item
locked_mechanical_item_members {
id int(11) PRIMARY auto_increment; // unique id
locked_item_id int(11) INDEX; // refers to the id column of locked_mechanical_items, this can be repeated (it isn't a PRIMARY or UNIQUE index)
user_id int(11) INDEX; // refers to the user id, assuming innectis has one again; zero could mean "%" or "any" if done this way
allowed tinyint(1) UNSIGNED; // a boolean yes (1) or no (0).
}
// allowed is _not_ indexed since I don't think it would be appropriate to do a WHERE clause on that column.
Really simple table structure, allowing for at least a million entries (it's setup similarly to how I have one of my large mysql databases done, and it has over 2.3 million entries in some tables, and doesn't execute/query slow even on a shared system).
However unlikely this feature may be added, I just wanted to share this detail to users who know what it means. If a table is designed correctly or efficiently, it won't necessarily be slow. It's important to know what terms mean when designing tables, such as the difference between a primary key, unique key, an index key, and a fulltext key. All four differ slightly on mysql. I can describe them if anyone wants me to. It's also important to note that not all columns in a table should have indexes; the only time a column should have an index is when you're going to be querying the table using that column in a WHERE clause, or if you need the data to behave in a certain way.
Also note that my table structure above is probably far from perfect. It could probably use some work. But it does make a fair attempt at holding large amounts of data while maintaining query/execution speed.
Regards,
- Jailout2000