cells.xt

[draxis]

What do the Vert and Horiz columns in cells.xt mean?
--
Specifically, the "2"s are throwing me off; I would otherwise assume it was saying whether the tile held up adjacent ones along that axis.

[Kyzrati]

(We don't have a cells.xt thread yet, so I moved your post here in case there are more. Oh, and welcome aboard draxis!)

Notice that many column headers have one or more level of supra-headers, which tell you more about what each column refers to. (I know this still doesn't tell you much, and you'd still need to ask me, but just pointing it out ) Vertical/horizontal support and stability all fall under the support header. So they all have to deal with the idea of "cell support".

These values control how nearby cells fall apart when a cell is destroyed, so you can control how sturdy a structure is overall, so that when you destroy a wall section of a weak building, more of it may crumble, but it would be less likely, or even impossible, with a stronger building.

Vertical support values:
0 = no support
1 = supports directly above only
2 = supports directly above *and* diagonally above (cardinal only)

Horizontal support values:
0 = no support
1 = supports cardinal directions

Every time a cell is destroyed, any cell(s) it is supporting must make a stability check to see if they fall too. This can cause a chain reaction. So "stability" is the likeliness of a cell to fall on loss of support, where 100 is a "normal" value (fairly likely to fall), and higher values make falling less likely (200 would roughly halve the normal chance to fall for the first loss of support). Stability also determines the max range of indirect vertical support, since even when one cell falls apart and threatens destruction of another one above it, nearby cells may continue to support that cell and override the fall. It's important to remember that a new roll is made for every adjacent loss of support. Also, cells DO support non-similar cells, so even if a cell provides no support, it probably need some stability of its own to avoid being dragged down too easily by neighboring destroyed cells. (You'll notice that all cells have *some* associated stability.)

Props have this same feature, and it works the same way--that's how the trees etc. are built, though props that don't generally have/use support don't need a stability value.

Also know that even if a cell/prop is not destroyed, simply falling will cause it to stop providing support.

[10101]

Those stairs work exactly like the Lifts in the UFOs but looking at it, it seems to be able to create at least some alternative.

Looking at the hillslopes, i think it would be possible to use something like 'Stairbase' as some kind of 'Earth' and the 'Stair' entry like the 'Grass' entry. The only question that rises is if i have to fill everything beneath the 'Stairbase' with 'Stairbase' or if i can make a room there.

[Kyzrati]

My thoughts exactly; in fact, I was going to try this very thing today. You should be able to implement stairs using slopes, as long as you have an earth-like stair base below it (this is what forces the pathfinder to check for a slope--the Skyranger ramp works the same way). I think overall this method will take up a lot of space, so it may only be appropriate for large/major stairwells, but we'll see. I'm not sure how effective it would be for towering staircases that spiral up multiple floors--that could start to take exponentially more space. For now I only plan on using it my two-story building which happens to have space for a large stairwell near the entrance.

[10101]

So there can be only one answer: Let's try it.

Hm, the Skyranger-Ramp has a zType of 'SLOPE='. is that '=' intended or simply a typo? Won't matter as that is an aggression-mod, but i ask just out of curiosity.


[PS] OK, i tried it and it seems to work perfectly until i get to the last step. from (5,4,2) to (5,5,3) i get the Message 'Invalid Move'.

[Kyzrati]

Certainly not a typo, since the data would throw an error if that line doesn't have a valid value. "SLOPE" and "SLOPE=" are two different kinds of sloping behavior. The full list is:

• NONE: No z-movement allowed
  
• VERT: enables direct vertical movement (stairs/lifts)
  
• SLOPE: enables slope movement--will automatically create four "sloped" versions of the Cell (horiz/vert/diagx2) and insert them along elevation change boundaries
  
• SLOPE=: same as SLOPE, but slopes are only formed between cells of the exact same type (whereas SLOPE can create slopes from non-matching types that all have the SLOPE designation)

I still haven't gotten a chance to try sloping steps yet. I can imagine they generally work, but the fact that they appear different from normal vertical stairs may throw some people off. It's easier to identify slopes outside since the lines all go in the same direction for an entire hillside, for example, while for stairs you'll just have a single line going in one direction, making it look almost like a wall of some sort.

[Kyzrati]

So I tried out the sloped stairs. Pretty cool since I didn't think to even use slopes as stairs, though yes, somewhat hard to read visually. And of course they take up more room, and you can't quite stack them properly. Perhaps for this kind of stairs I could add a new way to represent the ASCII. Spites may make them easier to show as well.

For others to see what it looks like, I've attached an image of the entryway of this building I made, F1/F2, where the stairs go up to the left. (The ASCII code to force a square block like that is LDBLCK, by the way, which I haven't used anywhere before so you wouldn't know.)

Attachments:

[10101]

Intresting. My stairs look slightly different, but you definitly can't reach the Sky with them (aka the 4th Level of Height).

[10101]

ARGH! I only wanted to see an preview not to post that. He doesn't want to add my attachment.

[Edit]Silly me. Might have helped to allow JAVAScript... [/Edit]
but it's a shorter - and a # so something like:
====
=--=
=.#=
====

Oh, and the Tower now works with the new stairs (despite it not being a tower any longer somehow as it now only has a height of 3. At least it now has a roof)

[Kyzrati]

Yep, can't add attachments after the initial post.

Height of 3 can still sort of be considered a tower! You can also forgo a roof entirely to get the extra level. I was thinking of doing that for my tower I'll be working on later.

[10101]

I did that before, but as it seems, those slope-stairs can't reach the highest level producing a 'Invalid Move!' trying to do so. Beneath everything works fine.

Though i prefer them to the lifts as they create a better feeling to the level an a littlebit more room vertically to shooting etc. (remember those Fireballs). About the space occupied: It's in the nature of these things, that stairs need more space than a Lift.

The thing that makes me curious now is, if i could increase the need of Stamina while walking upstairs (or the slope upwards). So people get exhausted, when reaching Level 6 or 7.

At least i now can get that darn picture in there.

Attachments:

[Kyzrati]

Is that a spiral staircase going up the tower? (Only one level so I can't quite tell, but it looks good.) I do very much like the idea of sloping stairs and will probably use them more later. They are definitely more realistic and have a lot of advantages; where space-saving is concerned I was mostly thinking about map/building design in general, how walls now take up an entire space instead of sitting between spaces like the original X-COM, so some percentage of the map space is lost to that effect, and having stairs take up a little less room is one of the few ways to regain a few cells... Then there's also the idea that the '>'/'<' stairs occupying a single cell are more "roguelike" in nature, though I'm not real adamant about that.

I'll add stamina cost modifiers in a future version. For now it's always diretly based on the TU cost as in X-COM (see here), which is probably better at this point since most of the values/costs aren't yet transparent to the player, so adding even more changes to the original rules could make the lack of predictability more annoying than it already is ;p.

The added TU cost for stairs is already pretty detrimental--you can always up that if you want by adjusting the Movement > TU column, which will both take longer, and tire them out more.

EDIT: I need to look into the "slopes not allowing you to reach the top z-level," since I'm not sure I tested them that high and if you can't do it, then that's a bug.

[10101]

Yes, it is a spiral staircase. But there are no overlappings as i didn't get high enough for a complete circle. Seems i have to force that for testing's sake. It isn't much more as Level 1 as Level 2 is the room at the top and Level 3 the roof.

Those walls between cells might work if used as props instead of cells, but i think it would be difficult to make them visible in the game. (and i assume it wouldn't be very 'roguelike' )

[Kyzrati]

You'll be able to play with skyscrapers one day, but until then we'll keep everything at a reasonable height from the ground ;p

Walls between cells wouldn't work at all, since the engine wasn't built for it--intentionally, of course! Also not very roguelike, yeah, but that's less an important point as it is making everything work more easily visually, which the roguelike form just happens to accomplish.

[10101]

Hm, this is strange. This construction worked and the varg even got to level3 without problems. Can't estimate why it didn't work in that tower..

5 = stairs (SLOPED=)
4 = stairbase (like 'Earth')

[EDIT]I found it! It somehow seems that you can't move upstairs if you can't see the slope-tile on the next level for whatever reason.

Simply to repeat: Start the sandbox and move a single soldier to the slope in front of the skyranger. Now start the debug mode and clear the map with ctrl+c if you then don't see the next level's slope, you can't walk there. [/Edit]

Attachments: