Search the Community

Showing results for tags 'access'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Official Buildings
    • GM Hall
    • City Hall
    • Website News
    • Public Test Board
  • Back Streets
    • Town Square
    • Community Assistance
    • Village Recruitment Center
    • Suggestions & Ideas
    • The Creative Commons
    • Wood Scraps
  • Jackal
    • Jackal Discussions
    • Jackal Market
  • Freedom Isles
    • Celebration
    • Deliverance
    • Exodus
    • Independence
    • Pristine
    • Release
    • Xanadu
    • Freedom Isles Market
  • Wurm Unlimited
    • Unlimited Discussion
    • Server Listings & Advertisement
    • Unlimited Modding
    • Technical Issues
  • Maintenance Buildings
    • Technical Issues
    • Server Bugs
    • Client Bugs
    • Model and Sound Bugs
    • Other Bugs and Issues
    • Wurmpedia / Wiki Maintenance

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start















Website URL















Found 4 results

  1. So i was skimming around the forum and didnt really see this suggestion. I did see some sorta liek this but not exzactly. Here is my idea. I think we should get door management perms for house doors, very similiar to mine doors. I know of a few people who are working on specail projects like INNs and community town hallls. But cant really manage it as they would like. As it stands right now the only think people can do is be added to a Writ of a building. Which gives them access. My idea would be to make them not be able to enter cetin rooms of that building unless they have their name added to the door. Very similar to the mine door. This could help people make single writ buildings and still be able to assign players parts of that building. In fact take this as an example. My current deed has a town hall. In fron of my town hall there is a 2x3 area of nothing but arches. and inside those arches are fences. I use this area for community storage. The only roblem wit this is i have to add them access to my writ to use the items in the arch section of the building. Doing this allows them access to the inside of the house as well, (even if locked) and this i do not want. I could see giving access tio a door by using keys like a gate. But i feel that could get a tad annoying with people losing their keys. So id suggest using thee same System as the Mine door, where u can actually assign a name. Also perhaps adjust the current Writ system so insead of needing them on your friends list. You could just add their name to the writ, like the mine door. In conclusion I feel this would open so many more possibilities for players to customize their deeds more freely and create more creative builds. Maybe even possibilities for like Player owned Rooms of an INN, or whatever. I can see how making it so they control a room can be difficult to adjust. seeing as the writ gives currently access to whole house and not sub sections of it. But allowing door management liek mine doors, You could give as many people access to your writ as you want. BUt certin rooms still wont be able to enter because of the Door lock. I havent played on any PVP server to know how this would affect Lock picking and stuff. But im sure it could be adjusted to allow lock picking to bypass the doors or something. So what are your opinions on this? Give a +1 If you agree. Maybe Devs and GMs will read this and add it soon. Please keep this post flame free.
  2. Rather than resurrect an old thread from several years ago, I feel that this one has enough merits for a fresh airing. One of those difficult things on Chaos is to manage permissions on each individual mine door, building, boat or anything else that Rolf adds. Some things can be done remotely, some have to be done locally. Especially with mine doors where unless you keep an exhaustive list of locations and the current settings then changing them all when someone needs adding or removing is prohibitive. Even then its painful to go round and visit them all when something changes. Personally I'd like to spend my time playing the game rather than have to focus on access management. The idea of this is similar to firewalls, a simple rule set is attached to whatever needs it and someone who attempts access is tested against the rule. At the first match the action of the matching rule is taken. If there is no rule match then access is denied. For a town writ there would be one list per role specifying who is in the role. The dialogue to manage a rule list needs the following - add a new rule (prepends or appends) - delete a rule - move a rule up or down within the list - test a target against the rule list (response is allow, deny or manage) The format of the rules is simple action target where action can be deny, allow or manage (manage implies allow) and target is of the format player_name@location (not dissimilar to email addy) - if player_name is blank then it means any player - if location is blank then it means any location - players names are a single word which is nicely convenient but locations can be multi-word so everything after the @ is considered location, spaces included - The object owner is a hidden rule which always prepends the list manage player_name@kingdom The kingdom part of the target is fixed as the kingdom the owner was in when they created the object. This means that if they change kingdom they can no longer manage the entity. For boats which are a personal item the prepends rule would be. manage player_name@ I do envisage a few special keywords such as base kingdoms if appropriate, for example on Chaos to exclude all new freedom players from accessing a building you could do deny @FREEDOM That is all the definitions. The other thing to consider is sequence, it is important and some examples are in order. 1. a mine door owned by JK in a war situation deny @MRdeny @HOTSallow @JKthis will explicitly block any MR or HotS player from using but allow any JK player but it could just as easily be written as allow @JKas the fall through action is always deny. 2. as (1) but this time a suspected alt belonging to another kingdom called imnotaspyreally is blocked too allow @JKdeny imnotaspyreally@now this would fail because the allow rule is hit first and it should be deny imnotaspyreally@allow @JKwhich will now block the offending individual. Note that when specifying individuals you only normally need to do player_name@ as names are unique. Also when changing rules always use the test feature. 3. The Hells Kitchen town has made a cave in which are three utmost veins and they want to keep for themselves, but also keep out three noobs in case they unwittingly mine the veins at low skill. deny noob1@deny noob2@deny noob3@allow @hells kitchen 4. MR are at war with a dummy MR town griefersville but they have a spy in there called lolwutme and want him to have access to a gatehouse allow lolwutme@deny @griefersvilleallow @MR5. A player account transporter is used at war deeds and often changes towns for a number of reasons (including right now access issues). We want to allow him into a gatehouse while he is a member of one of two towns, but not at a third. allow transporter@town1allow transporter@town2allow @wardeed6. I've created a mine door in a war situation and want to allow Nadroj and Horton to help manage it manage nadroj@manage horton@allow @MRSummary The use of lists can reduce the management effort on a LOT of writs while mine doors and boats will automatically compensate for player moves between towns and kingdoms. The lists will generally be a lot shorter than than the current tick lists, in fact in a worst case scenario it would only be the same length as the current lists are. They should also be of arbitrary length to avoid the mine door issue we currently have. In terms of converting any existing permissions, any invidual one would become allow player_name@ which could then be pruned down. Where there is a "all in my village" as with boats that would become @my_village. To cope with the optoin of allow friends this would insert the appropriate of name@ into the permissions but it would have to be handled manually there after. If its only friends you are allowing you could easily empty and reinsert that particular permissions list. Comments?
  3. I built a rock mine door today and unchecked the "Everyone in your village..." option. After that I no longer had access to the door and was unable to manage door settings. (Fortunately I allowed access for one of my my alts earlier, so I was able to change settings with that other character.) Also, the management window showed different information for different users (options were checked for one user, unchecked for others).
  4. I've been getting a lot of client crashes lately partaining to overflows and indexing issues of arrays and strings. The crashing seems to occur far more when I multi-client rather than single-clienting. A few examples are the following. First: Unexpected crash while playing The error was: <-907159351> I've had both negative and positive values for this kind of crash. Second: Unexpected crash while playing The error was: <String index out of range: 7> This is the first time I've had the above error. I've had more, such as one about an array boundary (ArrayIndexOutOfBoundsException). Also, none of the above are generation crash logs. I've had more crashes, but these are just the standard # EXCEPTION_ACCESS_VIOLATION (0xc0000005) error. I've given Java the ability to use over 4GB of RAM, so I don't believe that I should be crashing with a problem relating to memory usage as I only run 3 clients at most (which, currently are at 545,000k, 380,000k, and 359,000k memory usage). One client is running full settings and resolution (1080p), while the others run at a 640 resolution. Is there going to be any kind of fixing of the client as far as multi-clienting is concerned? I can post my specs if needed, but that shouldn't even be an issue. This is on the Unstable Client (v3.1.75). Edit: Whoops, can be moved to the technical issues forums. Sorry!