How to format your forum messages like a pro!

Links

• You can dump the address in the text, without any tag around it, and hope the forum software recognizes it.
  http://www.example.com → http://www.example.com
  
  
• Alternatively, put [url] around the address, to guarantee linkification:
  [url]http://www.example.com[/url] → http://www.example.com
  
  
• For very noble formatting, you can rename the link via [url=address]:
  [url=http://www.example.com]Example Website[/url] → Example Website
  

Named spoiler tags

[spoiler]Secret message[/spoiler] becomes:

[spoiler=Custom clickable text]Secret message[/spoiler] becomes:

Copying other people's formatting

You see other people's posts, and wonder how they got the formatting right.

Click "quote" on their post. Their message's source code will appear for you to edit. Study the source code to see how they formatted their text.

---

Icho has raged! With spoiler tags, the always-visible name goes into the tag, and the content goes between the tags. With URLs, the always-visible link name goes between the tags, and the URL content goes into the tag.

-- Simon

Hi,

Nepster has shown me a level that breaks in D Lix, because the terrain rendering is subtly different than in C++ Lix. We now have to decide -- which version has the bug. :-) And what our strategy should be.

The problem

Frame a) shows a terrain tile with odd dimensions, 57 x 57 pixels. There was an inconsistency in Allegro 4.x in how odd-dimensioned terrain was rotated. C++/A4 Lix built for Windows would rotate the terrain differently than C++/A4 Lix built for Linux.

To combat this inconsistency, I load the tile like frame b) in C++/A4 Lix: Odd dimensions are rounded up, padding at the right and bottom if necessary. The level format says where the top-left corner of each tile is, thus padding doesn't affect physics yet.

D/A5 Lix is written as if this bug/bugfix never existed, loads the tile like a), and rotates the tile like frame c).

C++/A4 Lix instead rotates the tile like d). Since the level format remembers the top-left corner of the rotated tile, the padding introduces a 1-pixel offset between the rotated tile c) and the rotated tile d).

Impact

This offset was enough to break 6 of Nepster's 107 replays.

Nepster has sent me a level where the above wooden tile, matt/earth/30, is aligned in a very precise way with the surroundings. The 1-pixel difference makes an intended walker's path impossible in D lix.

6 out of 107 is not that much. But it's enough for replay collectors to worry about this.

Solution strategies

Leave inconsistent: This doesn't require any work. We call it a bug in C++ Lix, don't fix it there, and continue to rotate like frame d). We hope that D/A5 Lix dosen't need a similar workaround, and continue to load the tiles as in frame c).

Port bug: I write code in D/A5 Lix to mimick the 1-pixel offset in C++/A4 Lix's handling of graphics and physics.

New level format: We could introduce a new level format that breaks C++/A4 Lix's forward compatibility with D/A5 levels.

geoo is considering tile-grouping instead of no-overwrite. I'm considering multiple skillsets per level, to enable handicapped games, asymmetric multiplayer maps, and different hatch numbers per player. All this would benefit highly from a better level format that allows grouping. I'd like to look into JSON or SDLang for this. <LetsAvoidMaking="Another">Bloated</XMLformat>

Unrelated improvement

No matter what we do, in D/A5, I want to infer the physics mask from the tile before rotating it, then rotate both graphics and mask. In C++/A4, I rotate the tile first with the graphics library, then check pixels of the rotated tile for solidness. This behavior as in C++/A4 has caused the inconsistency in the first place. I should have been carefully moving the graphics into place, keeping the physics simple and straightforward.

-- Simon

Very sensible suggestion. (No time limit) is more common than all other values combined.

-- Simon

Okay, thanks for checking back with miner & steel, and for the PM.

Yes, no-overwrite is a huge mess right now, if presentation and physics differ. I have to invest time and energy into drawing next.

-- Simon

C++ Lix has automatic centering on the average of all hatches, with optional manual choice of start position. Result: People haven't used the manual starting position anymore. The automatic thing seems to have been good enough:

hatches
    .filter(only hatches of local player)
    .map(hatch => spawn point)
    .average
    .centerScreenOnThere

...with a reasonably smart averaging function, taking into account torus properties of the level.

Yes, the manual setting could specify a center point, not the top-left corner. Nonetheless, a manual setting remains complexity that can be removed both from level design, and from the program design. The existing culture suggests that this removal is a good idea.

Specifying a center is better than specifying the corner. Yet, due to arbitrary resolutions, there is no guarantee about what's visible.

-- Simon

This problem depends on where the NL ship is sailing on the strategical level -- what are your main data structures going to be.

(Lemming style per graphic) may eventually run into this problem: From the view of a single level, there exist no graphic sets, there exist no packs. Graphic sets are trees of graphics. Packs are trees of levels. Is this still a design goal?

-- Simon

The rubbish is present in the data file, right?

The L1 devs have moved terrain far out of the visible area instead of deleting it. Alternatively, their convention for what denotes an existing piece isn't the same as ours. Since there is no specification of the L1 level format by its authors, we can only guess.

-- Simon

Full speed ahead for a clear separation of vanilla Lemmix and NL, including editor UI.

With direct drop, we (at least most of us) have agreed that mechanics should be fixed per engine. Within the same engine, any difference in behavior must be glaring. Nonstandard steel settings wouldn't be obvious at all. Such mechanics should be decided upon, then used engine-wide.

I'm more hesitant about level conversion. Vanilla Lemmix comes with a permanently fixed specification -- anything different from L1 is a bug. On the other hand, a conversion yields content that wouldn't see much play otherwise.

-- Simon