Alloc

Can you try creating a folder named "logs" in there manually and see if that helps? Also, don't run games as administrator. Devs generally aren't that trustworthy either

Would still be interested in knowing what exactly you changed and didn't seem to apply. Permissions are definitely reloaded live (you'll see that in the log output when it happens), so I assume it must be something very specific I missed. Actually that's vanilla. It just defines what permission level is required so that a user can view landclaims of all players, not just his own. Note that this API only provides info about the Map to the frontend, it doesn't actually control whether the map images can be accessed. For the vanilla web dashboard that indeed means it would not show the "Map" menu entry as it requires access to this API to know details on what to show, so for *most* practical reasons that is doing what you want. But it might not meet other people's use cases so wanted to make this one clear

> 1. What is "Login"? dont work at all for me It allows you to log in to the page. The login popup tells you what to do to create a user. > 2. why i cand "scroll" on the "mods" entry? Bug in the first release, it's already fixed and the fixed version will be included in 21.2 > 3. What are "markers? Only some bvlue "?" bulbs... It's just an example mod to show how mods can interact with this new system to add their own stuff. If you don't want it to show up you can disable it by removing permissions (i.e. permissions to e.g. -1), or you can delete the whole mod from the mods folder.

Thanks for reporting the input box bug, might also affect other things so good to know. Tried reproducing it being in the wrong spot but for me it works fine, placing the marker correctly. When you say it creates it in the wrong spot, did it show correctly in the table or was that showing the wrong spot too?

If you can't connect to the page at all it's not related to permissions. Logs might give further hints.

Well, "it's not working" is not going to get you help. We need more details, i.e. *what* is not working, logs? That would happen if your server does not have the TFP mods available.

Yes, no web module "web", but "web.map" (as you did in your sceenshot) should be just fine. This looks like you actually removed the MapRendering mod from your server.

They can just run it again at any time.

Set the permission for web.map to 2000 ("webpermission add web.map global 2000"). See above and don't forget enabling the maprendering in the serverconfig. So you are saying you tried editing the file while the second server was *running* and it did not pick up until restarting it? No, webserver already is quite heavy on the .NET runtime, SSL/TLS would drastically increase this again. You are advised to run this behind a reverse proxy like Nginx or Apache.

To clarify a few things: - You do not *need* the WebDashboardUrl - as per comment in the config it's only if the webserver is not available through its public IP (e.g. because you have it firewalled and behind a reverse proxy, which is actually recommended) - For the map to work at all it needs to be enabled in the serverconfig - No need to restart the server for permission changes to apply (no matter if done manually in the file or through console commands) - The default permissions allow users with permission level 0 full access to everything, other users (no matter if logged in or not) will not be able to do anything - You should not touch the "webapi.map" permission. This is about the *API* providing the frontend information about the map setup, it's not the map - If you want users with permission level > 0 see the map you need to change the permission level of the module "web.map". Either 2000 so it becomes visible even to users not logged in to the dashboard at all, 1000 so it becomes visible to those logged in only or any other value so it's only visible to those with that permission level (and above). - The console API does not have to be protected any further, the actual console commands define who can access what - If you do not *want* the console to show at all though you can set "webapi.command" method GET to level 0 (or 1000 if you want it to be available to all logged in users only). Currently this permission also controls the visibility of the settings page. - "Mods" menu entry is controlled by "webapi.mods" method GET.

You should not read too much into that mod. It's purely meant as an example on how to add something new to the dashboard (still need to make the source publicly available). Other than that you basically found out everything about it: - It creates five random markers at load time - You can add new ones with the boxes above the list - You can edit existing ones by double clicking the coordinate cells - You can delete existing ones by selecting a row and pressing the delete key

Map rendering needs to be enabled in the serverconfig. The "enablerendering" command is only an override to disable it at runtime. Arguments are "1" to turn on or anything else to disable (command help will be improved).

No, it's a completely independent thing. The scripts are for installing/managing servers on Linux, the mod can be used with any 7days server no matter the OS

You probably didn't enabled MapRendering in the config. Legacy mod still works and provides some stuff the new vanilla version can not serve yet. If you only need the map but no offline players / inventories the new version should serve you well. Also, wrong thread

Oh, was that announced already? But you can actually use it now already if you want, it's available as a mod for A20 Not sure what exactly you mean. All of the mod's source is available through the as linked from the doc page: https://7dtd.illy.bz/wiki/Server fixes If you meant something else please let me know

No, the only official "documentation" is the backend and frontend code of the mod. Also note that with A21 that version of the mod will be deprecated (i.e. only supported in it's current state for A21, probably with A22 at latest will no longer work) as A21 will get a vanilla implementation. The first versions won't have the full featureset of my mod (anything requiring the persistency file is not yet supported) so that's why some people might want to keep running the old mod in parallel for the time being.

That token is something you set up yourself. Have a look at the "webtokens" console command for setting it up, then you just pass that data to the API requests.

Hm, first time I've read such a complaint (other than some issues with the IDs being a bit of a nuiance). Not saying this could not be the case but I don't see how it would happen without at least an appropriate error/exception being logged at that point. I am aware though that the current system for storing that data really sucks but I can promise it's definitely going to be different soon(TM)

There are major changes planned but not even remotely close to a point to announce a release timeline. The current version should work just fine for the time being, at least not seen any reports of issues with 20.5 (other than possibly having to delete the data file when migrating from < 20.4).

Talking to the EOS team, but nothing that we could fix. They are not sure yet if they will (be able to) fix it, definitely would take a bit. After all the Phenom II is over 10 years old by now ...

Vanilla command "visitmap" (see its help for detaills). Note that it will create all chunks for the world so can increase the size of the save considerably.

Yeah, game prefs are all supported, this had been added to A16. Mostly for server providers to force certain settings so customers would not hurt anything e.g. by setting random directories or ports, but obviously can also be used for any client. Yes, Steam passes to launcher which passes anything non-launcher (-show-launcher, -from-steam, -skip-launcher) to the game. But passing the arguments from within Steam does not seem like the typical case, as that would again mean you basically only have one location. Unless you'd only do it to not store anything on the default location. As I said, it *might* consider a UDF specification, but it will definitely not read any serverconfig.xml.

In short: no, it does not care about a serverconfig.xml. - As the launcher runs the game with custom arguments it "can" not itself know about what's passed to the game. - The launcher is for running the client, not a server. serverconfig.xml (as the name implies) is for running servers *only*. Using it to override prefs is not meant to be done by passing a config but rather the prefs themselves on the command line. Not planning to add new prefs for logs, screenshots individually. That's what the idea of the UDF is: A place for storing files from the game (logs is a special case as the launcher has to pass the path to the executable, thus it is not aware of any custom UDF, thus always writes to the same location). Not sure about the last question. If you mean provide a UI for selecting UDF: Maybe, but unlikely. For the regular user that's not helpful and for those that actually would use it setting the UDF pref should be sufficient, either by having one in the launcher, or even passing it to the launcher through shortcuts or batch files.

Curious, what's the exact CPU model you use?

As you noticed I haven't really looked into that, but I don't see why adding such a layer would be an issue. Just needs some code to pull that data and provide it to the web frontend. Though most likely it would only work in areas around online players as I think the data is stored with the chunks. Meaning the data is only available when those chunks are loaded which in turn is only around players. Will definitely keep an eye on that one, might get done in one of the next updates maybe