Chicago-Themed Terrain

[Liebatron]

I do promise I'm done adding trains! (Unless anyone has any requests!) I was a little worried about the size of the tile set in general, also. I'm thinking if I make any major changes at this point it'll probably be to take out two of the red boxcar recolors. I was originally thinking it'd be nice to have some variation in one of the colors so you can have a complete train without every single car looking identical, but realistically the 3 red ones are so close in saturation and hue that I probably only need one of them.

Also, for the names, I'm curious as to the reasoning behind wanting concise, descriptive tile names. Does it have to do with how they appear in the Lix editor, or is there another reason? Specifically I want to check whether it's important that the name itself be concise, or the full path. I made subdirectories for purposes of organizing the pieces in the set, which makes for longer paths than usual, so I also want to make sure that won't cause any issues. I did that in part to control the order in which pieces appear in the editor menu, and also to make it easier to work with different pieces in the set during set creation. I'm thinking I'm pretty happy with most of the tile names themselves at this point, but if you've got any changes to suggest, let me know and I'll make those!

If it's just a couple, I can just go through the levels and change them manually, but if you anticipate the subdirectories causing problems in the future, that really will require every tile to change. In that case, I'll come up with tile names that ensure that they appear in that order anyway, but at this point I think you're right, some variety of automated solution will be needed...

I've already gone through and changed most of the tile names in the first 8'ish levels about 4 times for various reasons, so it's interesting you mention that; I was considering some java-based solutions to the problem. I feel like I can't be the first person to run into that issue while making a new terrain set and accompanying level pack "Oh, I want to change this tile name, but I also have to change it in these 50 places now." It'd be cool to have a reusable utility for that kind of situation. Something where you could say "Hey, here's 40 levels. I want to change this tile name to this in all of them. Make it so.", or have it read in a list of arbitrary tile name changes as JSON or XML and do the same. Or... Potentially a thing where you could do the same thing, and give it the path to the tile set and the levels, and it would list the tiles for you, and you could rename them in the interface and it would do it in both places simultaneously and resave everything with the changes in a separate output directory. It might take me a minute to put that together, but it'd be a cool utility to have available.

Also no dice on the blank entry for 1830. I'm thinking at some point I might try downloading it from somewhere and running it for reals on DosBOX instead of using that online emulator thing. I never fully trust the online emulator to faithfully reproduce games. I don't really have a reason to doubt it, it just seems like a weird thing to exist.

Forestidia - Thanks for playing the levels and providing feedback! I'm checking out your solutions now, and they are fascinating. You came up with cool ways to solve these. It looks like I've got a lot of minor/partial backroutes and a couple major backroutes to fix still.

Spoiler

[Intended] Beating a Path - "I found it a nice and funny idea for stalling but dragged on too long in my opinion."
- I would agree. I originally made this level so I could play it with my fiancée since she's new to the game, and we both died laughing when we were playing it together. When you're playing it single player though it doesn't quite have the same appeal for as long. I think I'll keep the hallway as it is, but shorten the bridge span so you don't have to stall for as long.

[Backroute] Falling For This City - If intended it has nice actiony mechanic and is a neat little puzzle in total.
- This solution was fascinating. I would never have thought to do it the way you did it. I don't want my constraints to give away too much for the intended solution, but I think I see a way to prevent that backroute without making the intended solution too obvious... I kind of tried to build these levels as with "Chekhov Pieces" to hint at where the solution should be applied. To that end, I think I might actually need to take a couple pieces out in this one.

[Intended Solution] Promotionary Point - I got first stunned how this level is solvable but again a quite unconventional solution.
-Neat!

[Partial Backroute] Bi-Level Platform - It seemed a quite standard nice puzzle to me although it happened to work out tightly in the end. So I don't know if the solution is fully intended.
- Not the intended solution! I'm fascinated by your solution though because it employs a certain mechanic that I didn't anticipate, and Timballisto did the exact same thing when he first played it. I have a pretty basic change in mind that will eliminate the backroute you found though. At the risk of giving away the intended solution, you're right, it's not supposed to be that tight timing-wise at the end.

[Not precisely as intended, but same basic idea] Crimson and Clover - A quite unconventional use of the miner if intended, was intructive but also quite tight.
- Another fascinating solution; it's not exactly the one I'd intended, but it's very close. The way I intended is a little easier to time, but does require more skills.

[As Intended with a twist] Green Line - This level took the longest for me to solve and I only got it with a very tight squeeze and much manipulation of timing. So not sure if intended.
- This level actually has 2 potential solutions; the one you found is the more difficult of the two to execute. It has a few very minor variations, some of which don't necessarily hinge on timing, but the way you found is pretty fascinating because it comes really close to exploiting the key intended mechanic, but just barely bypasses it. Both potential intended solutions to this level are supposed to rely on "sliding" to get above the platform... I think. I may be misunderstanding what counts as "sliding." Technically there's two ways to do it, but one of them is technically the 'real' intended solution. I might considering making the solution more obvious for this one and bumping it down a difficulty level though... I think this one might be more difficult than I expected, but based on your feedback it seems like there's a chance that it's not difficult for the *reasons* I'd intended.

[Partial Backroute] Which Way is Up - Interesting torus level though I'm not sure if I backrouted since I abused the reset of fallheight by flingers and could have saved even one more I think.
- This was a neat backroute, but it's one I should have seen, since it really does take advantage of the primary intended mechanic (resetting fall height with a Lix detonation). I'll have to rework this one a bit to get that flavor of backroute closed without making the intended solution too obvious, because I reeaalllly want people to find the intended solution. It's tight but it's sooo elegant in practice... The intended solution almost gives me that feeling you get when a song hits a high note section... I think it's called Frisson.

[Backroute] End of Shift - Rough to get everything together.
- This is actually backroute, but the fact that you came up with this solution before coming up with the intended solution is making me doubt whether it's reasonable to expect anyone to actually arrive at the intended solution the way it's set up now... For the intended solution, you're supposed to erm... Reach for the stars. I kind of want to keep that part in place, but the intended solution also relies on a highly specific set of actions at a critical point after that, and it might be good to simplify that part just so people don't get to it and think "This might be a dead end. I think I took a wrong turn when I started running around on the stars."

[Backroute] Over and Under - At first stunned how to solve without constructive skills but in the end not that hard if you know how the terrain works.
- There's a more reliable way to do the first part of this level, but I like the efficiency of the solution you used. I'm actually glad to hear that you were briefly unsure how to get across the river without builders; that was the intent there. I wanted to make something that looked like it could be bridged, but have the actual river crossing occur through other means. As for the part on the other side of the river, just... Just... I have no idea why the solution you came up with there didn't occur to me. The solution I intended initially was completely reliable, but it did rely on some narrow timing. What you did is way easier. I'm... Again, strongly debating whether I should fix this one, or leave it as is and just change the skills to match your solution.

[Hilarious backroute] Overtruss Trek - Abused heavily the mechanic of the flinger.
Wow. So uh... The intended solution does abuse the flinger mechanic in two ways actually, but it has a number of steps in between as well. I love that your solution just went way over the top and was like "I don't need no intervening steps, I'm just going to super-abuse the flinger mechanic and throw all of my Lemmings all the way across the screen with a single detonation. That is just hysterical. So uhh... I'm going to go ahead and make some minor adjustments to this one. The funny thing is I actually already thought of a very similar backroute and I added the metal bar to close that route. Evidently it was not as closed as I thought. I will go ahead and rework a couple more things here...

[Intended Solution with a Twist] Station Transfer - Again very heavily reliant on knowing how the terrain works, therefore at first stunned as well. Solved it almost by accident.
- This was exactly the intended solution, but I'm sorry you ended up having to solve it by accident : \ I think I need to take out the purple RS3... The absence of anything up there and the inability to get a bridge up high enough to slide up on top of the platform was initially supposed to be a hint; I don't remember why I ended up putting that second engine in. This one also needs some additional work, I think.

[Simon]

Subdirectories within tileset are fine. Lix editor tile browser will flatten the subdirs. It's up for debate whether the browser should flatten for every tileset.

Naming: I like all-lowercase, consistency, and no redundancy with directory names; for example, if tile is in a dir called "trains", tile itself doesn't need to be called "blue_train", "blue" would be enough here.

There exists no tool for the tile renamig yet because I've always done it with shell one-liners. It's certainly conceivable to make such a tool. It's occasionally handy for maintenance, but it's extremely handy for tileset designers, indeed.

If you know Java, you can also peek at the Lix source. The object-oriented parts of D are heavily inspired by Java.

Still have to reply to many details, including the trap design. Will come back to you this weekend!

-- Simon

[Simon]

I wanted to reply about the trap design. I'm still sorting through the different zip archives, trap examples need the exact right version of the tileset to play. The most recent archive has subdirectories, the trap examples seem to need the old, flatter tree.

It's getting too late today, I'll come back to that in a couple days!

If you already have the tiles/matching levels in git somewhere on the internet, that would help me. But don't stick the tiles in git merely for me; if you prefer zip archives, then stick with those. Eventually, we'll put the tiles directly in the Lix main repository.

-- Simon

[Liebatron]

I hadn't considered a git repo, but I do have a github account... I might do that eventually, but for the time being I haven't made any changes to the tileset, so you've still got the most up-to-date version.

Also there's absolutely no rush!

I know everyone knows the holidays themselves are busy, but I feel like the post-holidays are frequently underappreciated for how busy they are. You've got just... Lots of stuff to put back the way it was, and you're already tired, and work things all pick up at the same time as people rush to be like 'What was I doing...', and you have to deal with that after this kind of emotional de-escalation of everything, because the 'big events' are over, and you're basically not running on adrenaline anymore. I feel like January is often a mess in that way, and it goes unrecognized.

I'll keep checking back and stuff. I was gone for a while, but now that I'm here again I want to remember to check in and hang out here with at least some regularity even if I'm not in a highly active phase of a specific project. It's just a good place, and a good group of people to stay in contact with.

[Simon]

All right, I'll look at the example levels in your current version, then, to figure out the best way for the traps.

On first thought, I'm fine with adding traps, but reluctant to add new types of traps/animations. We can think about reorganization of how the editor's browser offers the traps. Still, let's try not to spam traps merely because of animation reason. Trap animations have their known problems, e.g., the dying lixes are part of the trap and thus aren't recolored in multiplayer.

See also: github #347: Improve some odd trap death effects #347

-- Simon

[Forestidia86]

I thought train traps would fit better as fire traps (more fitting sound) but I can see a point for water traps as well (like pulled under the train).

There is a new issue(#411) concerning better trap management.

[Simon]

I will reply in detail within a day. Gist:

• Issue #411: Better trap design has ideas to improve existing traps and allow you to better realize what you want to do. I'm 50:50 whether it's worth it. Format change considerations etc.
• When a tile is divisible by 8 or 16, I encourage you to make it align with the grid better. Whenever you can design a tile so that it aligns with the 16 grid, do it, or try to aim at least at the 8 grid. One train gadget looks like it should align, but it doesn't.
• Tileset encourages levels that depend on icky details in the physics.
• Some sizes not divisible by 16 even though there is no clear reason to deviate, e.g., box girder. I'll have to find the exact tile again.
• Steel is hard to see. Nubs aren't enough at first sight. Color it much closer to white? Reserve light grey for steel and make other stuff darker?
• Police trap is amazing, everybody in Lixtown will be locked away for misdemeanor.

More details soon!

-- Simon

[Simon]

Traps: If you want permanently-running trains, I agree that the empty crossing plus decorative animated background is problematic. It's too easy to use one part without the other during level design. The 0x0-sized trigger is cute, but ultimately goes against Lix's spirit that everything animated should have an effect.

I recommend that you implement this idea with a single tile (not two tiles that shall be overlaid) and make it water or fire. It will kill lix continuously, which is appropriate for a train running through; it won't kill only one lix at a time.

The crossing can either become terrain, or become a graphical variant of the single-tile trap.

If #411 goes through, we can then replace the water/fire with a functionally identical trap that has your already-designed death effect, but is still continuous. If #411 doesn't go through, I feel like the water/fire is still the least-nasty way (compared with two tiles that kill one-at-a-time).

Please consider supporting the 16-grid. E.g., Chicago/active/Water_CTA_2400_car_1.W looks like it aligns only to a 4-grid. It would help if it sat on the ground perfectly whenever both the ground and the trap are placed under the 16-grid (4th button in editor's top row).

-- Simon

[Liebatron]

Thanks for looking these things over! I appreciate you taking time out of your day to inspect my silly train tiles!

I figured there was a pretty good chance the perma-trains and crossing gate would go that way, but I'll keep a local copy for nostalgia, and in case there's ever another place to use them!

I'm thinking I'll turn the static crossing into terrain then, and keep the animated crossing attached to a dedicated "Trap with crossing" object which will also be water. I initially made it water just as a placeholder, but when I saw it in action I realized that the drowning sound can also kind of sound like a crushing sound if your brain hears it while paired with the visual of a Lix getting pulled under a train. If you're ok with it, I think it'll work out ok!

As for the 16 grid, I think I know why that is... I might not be 100% clear on what the misalignment is until I can look at it in the Lix editor again, but I'll take a look at that on a per-object basis too and try to optimize for 16- or 8-grid compliance.

I was kind of having the same thought myself about the steel tiles towards the end too. It's pretty obvious when they're compared to the non-steel beam variants, but when it's just the steel ones standing alone, the bolts don't stand out as much as I would have liked.

I am glad you liked the police trap, also!

[Liebatron]

Done so far:

Made closed crossing gate into a small detail terrain piece; "crossing_gates_closed_1"
Renamed "open_crossing_gates_1" to "crossing_gates_open_1"
Removed "Trap_CTA_2400_car_1.T"
Removed "Trap_CTA_2400_car_2.T"
Removed "Trap_CTA_4000_car_1.T"
Removed "Trap_CTA_4000_car_2.T"
(Now the only remaining railcar trap variants are the ones that act as water)

All traps, hatches, and exits are now 16 pixels tall (or a multiple; one is 32)

Left to do:
Make railcars multiples of 16 pixels tall where possible (The Forney is *17* pixels tall right now and I can't really take a pixel off the height... Debating whether I should make it 24px, or just go all-in and make it 32 pixels tall with 15 pixels of empty space?
Fix steel tiles to be more obviously steel
16 pixel horizontal alignment... Would be a lot trickier for the hatches and such, but might also be worth looking into. The hatches/exits/traps are already 8-pixel compliant; debating whether or not to add 8 pixels of empty space, or if I should just leave 'em as is... It would mean 8 pixels of blank space on a graphic that's already a multiple of 8 pixels. Pros: Would align to 16-grid. Cons: Would bug me... I should just go ahead and make it align, shouldn't I?

[607]

Wow, I love it!! The trains are beautiful! I like the buildings a lot, too.

[Simon]

Support for grid 8 is already good, it's your call if the extra mile for grid 16 is worth it. Empty space, hmmmmm, it's nasty that empty space is the only way in current file formats to align to a grid.

At least grid 8 is a good start for things that are hard to support grid 16.

For comparison, the truss square is 42x42 and is designed to overlap with copies of itself by 6 pixels. As it stands, neither grid 8 nor grid 16 will get us anywhere near what we want to do, and we'd use grid 2 with this square. The truss square looks like it would benefit the most from becoming 48x48 (40x40 in a pinch), with an overlap by 8 pixels.

-- Simon

[Liebatron]

Alright... In that case, then after much deliberation, being distracted by other things in life, and pain thinking about 15 pixels of empty space, I think I'm going to go ahead and make the Forney have *7* pixels of extra space at the top. That will be less than half as painful as 15 extra pixels.

Still still to do:

Make truss squares 48x48, or possibly make two versions; one 48x48 and another 32x32...
Fix steel tiles to be more obviously steel
Add 7 pixels to Forney type
Fix level pack up for new sizes
Fix "Up" arrow key on keyboard, since it's decided it doesn't want to work anymore

Also, thanks 607!

[Liebatron]

Make truss squares 48x48, or possibly make two versions; one 48x48 and another 32x32...
Fix steel tiles to be more obviously steel
I ended up doing a bit of a compromise here; I decided I couldn't really make the steel obviously steel without scaling it up a bit in terms of thickness, so I went ahead and did that, which also resolved the 8-pixel overlap tiling issue. The resulting steel piece is 48x48!

I do still really like the thinner square truss though, and I like the idea of having a generic square truss that *isn't* steel, so I did just add it separately under the "truss" section as a non-steel square truss piece with the same size. That one doesn't tile with the same 8-pixel overlap, but it would tile with a 4-pixel overlap, and it's still 48x48. If you needed to tile them on an 8-pixel grid, it would still work, you'd just have double-trussed vertical and horizontal bars. Let me know if that sounds like an acceptable solution!

Add 7 pixels to Forney type
I mixed this up; I needed 7 pixels to the *side* to adhere to the 8-grid. That's more palatable than a bunch of empty space at the top. This is done!

Fix level pack up for new sizes - Still need to do this part!

Fix "Up" arrow key on keyboard, since it's decided it doesn't want to work anymore - Ordered new machine. This one is starting to do some interesting things anyway, aside from the key failure. This has been an outstanding machine for several years, but I think it's time...

[Simon]

Thanks! I've downloaded it and taken a first glance. Lots of reallife stuff to do, but in due time, I'll look with much more detail and write feedback.

-- Simon