Yes I know how. I'm not really interested in doing it myself (and you'll want to add them to 0.9 which I'm even less interested in).

Edit the font files as Grommit suggests (the one(s) you want to edit already have some smileys in so they're easy to spot).

Then edit this function in misc.c to convert your smiley text into the appropriate single chars:

Off the top of my head I don't think there's any more to do.

There would definitely be sensible boundaries; eg, GT would never be wussed down to level 1 (or even level 51).

But for example, maybe a map would have a base difficulty (which is what the mapmaker sets). Using this on the level_ color table would give a difficulty range within which the dynamic difficulty could be set according to how good or bad the player was. Thus mobs would be spawned (traps would do damage, chests would contain random treasure, etc) according to this dynamic dfficulty.

For example, a map with base difficulty 50 gets '{ 36, 41, 49, 52, 55, 61}, /* lvl 50 */' from the level_colour table, so dynamic difficulty could be set to one of those values, depending on how easy/hard you wanted to make it ingame. Mobs would then have their level set relative to the dynamic difficulty.

The player would then have wussier or tougher mobs to fight according to his abilities and would automatically be rewarded appropriately too as mob level determines exp and random treasure for example.

So in theory it's a way to keep the game accessible both to the kind of player who rushes around killing purples all the time and marvelling as his exp goes through the roof, and the kind of player who likes a more relaxed time of it but still wants to progress.

Of course, as mentioned, it wouldn't work so well on multiplayer maps where both types are playing at the same time, but would probably be for (group) instances only.

That can be done already with a script. In fact it sort of is done already in PotD (Lippy introduced attack_ and resist_ attribute reading and writing to Lua for this purpose IIRC).

Well I fixed a couple of small issues the other day.

Although up to level 200 can be handled by the colour table, the level attribute itself is sint8 (I have no idea why), so can only store -127 to 127. It's probably no particular problem to make it sint16 or so but because various types use level for various purposes I'd want to do a lot of testing before I committed such a change, and I can't be bothered ATM;  it's not that big a deal to me. So for now mobs are limited to level <= 127 (purple to <= 105, red to all others).

So with that, I'll commit this to trunk in a bit.

Longir's suggestion is better handled in a script and the dynamic map difficulty stuff is clearly not much wanted anyway

I hope her avatar was not a photo

Thanks Torch. Committed to trunk.

Hi Zilla. What happened to that brilliant avatar you had?

He's talking about the client, not a web browser.

No, you can't use alpha in the fonts. IIRC (I'm pretty sure I do), it's a 0 or 1 type thing ATM.

Yeah I think the pickmap idea is better. And I'll mention this in the use part of the types.xml help.

But I also want to make these work properly with all the movement flags (walk/fly_on/off). Currently they don't work properly with _off (really, the various bits of code that handle these flags were so broken in many different ways it's a wonder anything ever worked at all).

So it'll take a couple of days (I already addressed most issues in a couple of streams, but the streams essentially rewrite the connection system so I'll need to only extract and modify the relevant bits to work with the existing system).

I'm going to commit the v4 lamps to trunk in a bit. Not because they're perfect, but because they're good enough.

A couple of improvements might be:

• draw a fat oil reservoir at the bottom of the lamps or even a large metal base concealing a reservoir, like this:

and perhaps extend the distance between the arm and the bulb of the lamp slightly so it looks more like a lamp hung on a post rather than a single unit electric lamppost.

• 'roughen' up the metal texture so it doesn't look so computer generated/unrealistic.
• draw a flourishy bracket thing attaching the top of the vertical to the arm, for more realism (ie, structural strength) and decoration.

The brightness, and lack of, is down to the client, and not something you can change in an image (well you probably can to an extent, but I don't think it'll work very well). For example, you could definitely add a 'pool' of light on the area 'under' the bulb, but this pool will be noticeably under mobs and players and the square will still be lit or not as above as well.

Oh yes, I need 8 off images too -- no yellowness.

Currently pedestals, inv checkers, and detectors are layer 3 in the arch. AFAICS this is just wrong. They should be layer 0 sys_object 1.

Grepping the unofficial maps suggests everyone else agrees, as, with very few exeptions, the map objects are changed in this way. The few exceptions are where the map objects are is_invisible 1, which I think is where the mappers have misunderstood the difference between sys_object and is_invisible.

I can see no situation (beyond the highly contrived) where pedestals should be detectable, and even if they should it would make more sense to make this alteration in the map.

IOW I shall change the arches to layer 0 sys_object 1 unless there is good reason not to I have overlooked.

You make a good point.

Nevertheless, perhaps it'd be useful on low-level dungeons, or tutorial quests, or certain plot-related quests (should there ever be any) -- having the story freeze because you just can't get past a certain point sucks.

Yes I was thinking to in effect allow maps to autotailor themselves (in terms of mob strength anyway) to the player(s). I guess this only really makes sense on instances.

But for example, you might record the time the player/group enters the map and then compare it to the time they reach a given point. If the time taken is too little, the map difficulty is too low, so increase it. Future spawns will be relative to this new difficulty (but bear in mind that the players will still be the same level, so care is needed). Or match map difficulty to player level. So if the player levels in the dungeon, the dungeon gets harder.

And as you say, this sort of dynamism is particularly suited to bosses (although for those purposes -- particular mobs it is probably better to stick an apply script in the spawnpoint, as here: http://www.daimonin.com/add_eventactivate-t7546.0.html ).

Yes, if item_condition > 0 you will generate x random numbers per spawn (where x is potentially 40 but in reality usually less than 10 or even 5). It's a server thing, so done in C, not Lua. I'm not sure what you mean by 'doing some floating point math with them'. Here's the actual code:

Now any efficiency gains gratefully received (I think it might be better to declare 'int modifier = monster->condition' then refer to modifier throughout -- IIUC this is a shade faster, but I really have no idea if that's true).

I mentioned doing it in Gridarta to Ragnor a few months ago, thinking to tow the party line and save our precious server from doing anything. The flaming on #gridarta went on for quite some time . (Not real flaming, but the suggestion was not well received.)

Besides, that doesn't really achieve the same -- sure, each spawnpoint has a varied mob, but it is always the same varied mob every spawn.

IMO, absolutely, because I don't think there''ll be any noticeable 'load' on the server. Of course the only way to know for sure is to try it on a public server and ATM we can't.

How do you mean? How would you have randomisation with nothing decided at runtime?