View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0005293 | Valley 1 | Suggestion - UI Ideas | Dec 9, 2011 6:13 pm | Dec 12, 2011 7:20 am | |
| Reporter | TNSe | Assigned To | |||
| Severity | minor | ||||
| Status | considering | Resolution | open | ||
| Product Version | 0.548 | ||||
| Summary | 0005293: Looting goods from rooms -> Change Dungeon map color | ||||
| Description | When you kill a boss, the Dungeon Map loses its Boss Color, and receives the color of an uninteresting room. This also happens to rooms with Gems. I suggest that this also should apply to Yellow house rooms. (Possibly Green) so that you can see you have emptied the stash out. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | Feature Suggestion | ||||
|
|
This is a problem for multiplayer, though, because each player can collect an individual copy of stuff in stashes. With the boss rooms, it's a global thing. And with the gem rooms, that's going to be a global thing as well, even though it's not yet. |
|
|
I guess you are going to have to do the coloring logic clientside then. select * from room where useful = 1; ;) |
|
|
Bearing in mind, of course, that that data doesn't exist on the client side, but still. |
|
|
Ah yes, of course. Guess you are going to have to do this logic serverside on a per player basis before sending over map information. I really like that map updates and sets rooms as uninteresting, and I hope this will survive even with multiplayer in mind. |
|
|
And actually, even in solo and in multiplayer, the server doesn't have that info if you're not actively in the room at the time. The details about what's in the room get persisted to disk, and the room metadata is all that gets persisted to the server and the client in memory when you're out of the room. So in other words, what this would really require is an extension of metadata to be per-client, which I'm not... super enthused about. But it probably would be a good idea. |
|
|
It would be extra data to process on server and additional data to send to clients per client basis. But on the positive side, this would not update a whole lot, making it a very small amount of traffic outside of room (chunk?) generation. |
|
|
It's fairly small, yes, but it also then gets into disk storage, etc, etc, etc. It's a fairly minor thing in the main, but with metadata -- since that is always in memory when a region is open, and never on disk -- we like to be judicious. |
|
|
Not sure how you handle these data internally, but I guess a variable containing each interesting item in the room as soon as its scouted, which counts down for each picked up. Either that or a simpler bitflag. |
|
|
It would have to be a list of bools, because the number of players could be 1-n. And not on a per-object basis, it has to detect the uselessness of the room when you are in it (no more objects left to get) and then set the bool in the central list. And it would actually have to pair that with an ID for your player account on that server, actually, because in most cases not all players would even visit all rooms, so having them by index would be a huge waste in those cases (while having it include the id is a mild waste in solo, but solo worlds can become multi and vice-versa, so there can't be a difference). |
|
|
Might be better off with a bitflagged byte array then. 8 rooms/byte. List<Boolean> sounds just wrong to me. |
|
|
Nope and nope. The data is on the room, and has to track the players. It would be List<int>, actually, in the final implementation. List of players that find the room useless now. Putting it on the player object would make it hang out in memory even when not in the region. |
|
|
So each room would be a Dictionary<Player, int> on a per room basis? Or per chunk? |
|
|
No, there is already dungeon metadata that exists. On that object we get List<int> playersFindingThisUseless or whatever. That's literally it. |
|
|
Hey, no negative variable names. Call it List<int> playersFindingThisUseful, and delete players as they loot. Although this comes down to the assumption if players end up looting everything or if players tend to leave it unlooted. Useless might end up taking less space overall. |
|
|
No, it _has_ to be a negative variable name because a lot of the players that might or might not loot the room might not even be part of the server yet. Players can join a server whenever the heck they feel like, so we can't say "these are the players who have not been here and got everything," all we can say is those who have. And as I noted, if there are 100 players on a sever (not all active at once, just coming and going) it's extraordinarily unlikely that even 10% of them would visit any given room. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Dec 9, 2011 6:13 pm | TNSe | New Issue | |
| Dec 9, 2011 6:16 pm | Chris_McElligottPark | Note Added: 0017743 | |
| Dec 9, 2011 6:24 pm | TNSe | Note Added: 0017744 | |
| Dec 9, 2011 6:26 pm | Chris_McElligottPark | Note Added: 0017745 | |
| Dec 9, 2011 6:28 pm | TNSe | Note Added: 0017746 | |
| Dec 9, 2011 6:29 pm | Chris_McElligottPark | Note Added: 0017747 | |
| Dec 9, 2011 6:31 pm | TNSe | Note Added: 0017748 | |
| Dec 9, 2011 6:32 pm | Chris_McElligottPark | Note Added: 0017749 | |
| Dec 9, 2011 6:33 pm | TNSe | Note Added: 0017750 | |
| Dec 9, 2011 6:37 pm | Chris_McElligottPark | Note Added: 0017751 | |
| Dec 9, 2011 6:41 pm | TNSe | Note Added: 0017752 | |
| Dec 9, 2011 6:43 pm | Chris_McElligottPark | Note Added: 0017753 | |
| Dec 9, 2011 6:45 pm | TNSe | Note Added: 0017754 | |
| Dec 9, 2011 6:49 pm | Chris_McElligottPark | Note Added: 0017755 | |
| Dec 9, 2011 6:55 pm | TNSe | Note Added: 0017756 | |
| Dec 9, 2011 7:01 pm | Chris_McElligottPark | Note Added: 0017757 | |
| Dec 12, 2011 7:20 am | tigersfan | Internal Weight | => Feature Suggestion |
| Dec 12, 2011 7:20 am | tigersfan | Status | new => considering |
