Hi,
i wonder why the /save command doesn't work, the save macro is still in the keysettings (F11), but when i execute it, it says: '/save' is not a valid command.
Then should i commit the gentoo ebuild for 0.10.7 or should i wait for 0.10.8? Is there a release date for 0.10.8?

And is it normal, that when i change the resolution to higher then 800x600, i just get a black border, instead of stretching or increasing the viewport, is that normal or a linux problem?

Greetz
kur'k'tu

P.S.: I updated the music addon, so the download works now again.

Hello,

/save was removed (serverside) in (IIRC) some.10.6 interim> If it's still bound to f11 in the client, that's just an oversight.

Well, it's bound to '\' you can just change the key-setting in the F11-Menu.

Was removed because it has never been useful (saving always happens on logout, server shutdown, and periodically automatically) and can (and has) been used by naughty players for 'item duping'.

Ohh how rude of them..
Well i thought about using /save because my Instant-Use-Slots (F1-F8) are always gone when reconnecting.. :-/

I'm pretty sure the black border is normal. I did make a client a while ago which scaled everything (widgets and maps) which was pretty cool. At least with SDL 1.2 there is a bit of a performance tradeoff here (actually, not huge).

Sounds good, why not include that feature in the standard client? At least as an option in the settings or a make option?

Increasing the viewport (how much map you can see) has gameplay (and bandwidth) consequences. The max is likely too always be 17x17.

Then how about a clientwise memory of about 32x32 or so? The memory tiles could then be a bit more dark-grey shaded compared to fresh tiles from the server. Because i think the blank black tiles are the most annoying part about daimonin.

greetz
kur'k'tu

Are you running client version 0.10.7?

Yes. But it seems to work now, weird a few days ago it didn't.

Quote from: smacky on 30, June 2016, 21:26:58

Increasing the viewport (how much map you can see) has gameplay (and bandwidth) consequences. The max is likely too always be 17x17.

Then how about a clientwise memory of about 32x32 or so? The memory tiles could then be a bit more dark-grey shaded compared to fresh tiles from the server. Because i think the blank black tiles are the most annoying part about daimonin.

On the one hand, I agree it is annoying and the small fixed size map makes Dai look very retro (not in a good way).

On the other, that in itself is no solution. Well, depending what you exactly mean.

The server itself must only send map updates for a max 17x17 area. Anything else is too easy for a coder to exploit in their client (IOW the server sends 32x32 but the client only shows 17x17, but it's OS so someone recodes their client to show the entire area for which they have data).

But that's assuming the server sends 32x32 live data. There is already a Fog Of War feature where the client 'remembers' the map and basically draws the entire 17x17 map as remembered (ie, static data) with a colour filter (say dark blue or sepia, or we could even get fancy and process the graphics somehow to be 'foggy'} except the bits you can see (ie, dynamic data sent from the server each tick) which are drawn in normal colour.

For reasons I'm not entirely clear on this feature was disabled a few years agp. I reenabled/reworked it in the previously mentioned client (and made it optional). I think there must be a screenshot around here somewhere... brb...

EDIT: No screen but here's a thread: https://www.daimonin.org/10905/fog-of-war/

I apparently put all this stuff on trunk so you should be able to checkout the revisions mentioned in that thread to have a go. It's not current because basically we (well, I) painted us into a corner and had to burn the room down and start over,

Yes, right. Once the server has sent whatever data it deems fit to the client, the client is free to do whatever, render however, remember as long/short as it likes that data or any subset of that data.

That's really the basis of our transfer ptocol: server sends the minimum amount of data it possibly can (while still being useful), client uses (and reuses) that data however it likes to extract the maximum utility it can.

And on this error where the client crashes after fast relogin.. i did a backtrace but seemes debug symbols are still missing, so heres the backtrace and a screenshot from the point where it crashed, probably someone can still read it even without debug symbols:

Trying to save options... OK!
Image ID too big (9710 9277)
Image ID too big (9498 9277)
Image ID too big (9498 9277)
Image ID too big (10588 9277)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000407221 in ?? ()
(gdb) bt
#0  0x0000000000407221 in ?? ()
#1  0x000000000040788d in ?? ()
#2  0x0000000000407de6 in ?? ()
#3  0x0000000000425aa8 in ?? ()
#4  0x0000000000410dd0 in ?? ()
#5  0x0000000000410af7 in ?? ()
#6  0x0000000000404e65 in ?? ()
#7  0x00007ffff6d7e620 in __libc_start_main () from /lib64/libc.so.6
#8  0x0000000000406159 in ?? ()
(gdb)

Fixed.