Bugs, crashes, typos & bad taste

[donk]

Yes I understand. And that made me think. Does there exist an invisible tile, or something, that has the properties that it prevents the map generation to place objects on top of them? That could be a way to prevent this from happening, if each craft had some way to remove blocks in front of exits by just using a special tile.

[Juku121]

The problem with that is that it'll prevent anything from getting placed on top, and you presumably do not want black holes of nothingness in front of your ramp. It's the conundrum of wanting something (the underlying terrain) but not something else (the bush) from the map. And I imagine there are enough cases where getting the bushes is actually desired, so one can't just blanket forbid those.

[donk]

Can you elaborate on that a bit? I can't think of a single thing I want to be on these 2 tiles at the ramp. It's not like I suggest a big area to be cleared, just the ones I point at in the pic for example.

[Juku121]

Green when you're in the forest, yellow when in the desert, cabbages if the plane lands in the produce?

If you're happy with some sort of patch of scorched earth universal to all maps, sure. Solarius doesn't seem to be.

[donk]

Green when you're in the forest, yellow when in the desert, cabbages if the plane lands in the produce?

If you're happy with some sort of patch of scorched earth universal to all maps, sure. Solarius doesn't seem to be.

I've said none of that, don't be silly.

[Juku121]

And I didn't attribute anything to you, besides this:

I can't think of a single thing I want to be on these 2 tiles at the ramp.

The above are examples of what others, including the mod author, usually want at these ramp tiles. You can either

• do nothing and live with the occasional uppity bit of foliage,
• retain the terrain and replace any objects with something (like the ramp itself does ), but that will be much worse than the occasional errant bush, since now there's a permanent blockage at the exit,
  
• or replace both the terrain and the objects, and have it be the same no matter the mission terrain, like my scorched earth patch example.
  

Currently, the first option has been deemed the least offensive. I don't know if y-scripts can affect mapgen but if not, then resolving this issue would need OXCE devs to sign off on a solution (in addition to Solarius actually wanting it badly enough).

[Akamashi]

I'm not sure if this is a mistake. Right now I had a huge massacre on IRON FIST crafti. And my agents got a plasma projectile through the windshield 20 times. There's definitely a hole there. Is that the plan??

[psavola]

In OXCE 7.10 (or actually 7.9.17) the visibility calculations changed, for example the smoke and darkness became much more effective. This also affects human ghost visibility. Before, they were shining beacons in the dark and you could spot them from all over the map. Now you may need to throw flares in the dark to spot them.

You may want to consider whether you keep those as-is and as changed by recent OXCE, or try to put in some new variables (or y-scripts as drafted by zsrr I think) to recalibrate these (especially the ghost visibility).

[Meridian]

In OXCE 7.10 (or actually 7.9.17) the visibility calculations changed, for example the smoke and darkness became much more effective. This also affects human ghost visibility. Before, they were shining beacons in the dark and you could spot them from all over the map. Now you may need to throw flares in the dark to spot them.

You may want to consider whether you keep those as-is and as changed by recent OXCE, or try to put in some new variables (or y-scripts as drafted by zsrr I think) to recalibrate these (especially the ghost visibility).

afaik, there was no change in how effective "darkness" is

you should not need a flare to see something that was visible before

report a bug, with save attached, if you spot something that is "wildly different than before".... to fix or clarify

[Yankes]

afaik, there was no change in how effective "darkness" is

you should not need a flare to see something that was visible before

report a bug, with save attached, if you spot something that is "wildly different than before".... to fix or clarify

"smoke and darkness" was critical part here as both stack with each other. If we use stock setting there is no difference as personal light make smoke bright (around player units).
but with low personal light smoke is more potent.

[psavola]

afaik, there was no change in how effective "darkness" is

you should not need a flare to see something that was visible before

report a bug, with save attached, if you spot something that is "wildly different than before".... to fix or clarify

Darkness and smoke is wildly different than what was before (visibility of 1/2 squares instead of ~5). Already reported in https://openxcom.org/forum/index.php/topic,11622.0.html , but Yankes doesn't apparently see this as a problem. I think this should at least have been noted with huge exclamation marks in the changelog.

Regarding ghosts, I can't reproduce this now. I could have sworn they have emitted light in my previous campaigns but it might have been another light source.

[Meridian]

"smoke and darkness" was critical part here as both stack with each other. If we use stock setting there is no difference as personal light make smoke bright (around player units).
but with low personal light smoke is more potent.

that's why I'm asking for a save, to see what it is

I don't know what's a "human ghost", I don't even know if it's a friendly unit or alien or neutral, so no idea what conditions apply

[CrazedHarpooner]

I found the issue. Turns out if the check for blocking option (BAI) is set these stairs stop working. Same for the ones on the cruise ship. If I turn it off it works again.

But that might lead to an other issue and that is that sometimes in the jungle a bush spawns at the ramp and if you have a tank in the front you are stuck. I tried to blow it up but it didn't work so I had to leave. It has happened a couple of times.

Out of sheer curiosity I decided to investigate possible causes of the ramp bush. Now I've managed to narrow down this particular case as a combination of the Osprey craft and the MOUNTBD_TROPICAL LZ blocks, particulary MOUNTBD02.

While using OXCE New Battle fuctionality I noticed something, the plant-bush in question is visibly overlapping the lowest ramp section and while viewing the mapblock directly with mapview2 I further noticed that the bush is placed in the tile's floor slot, not the content slot. Had it been placed as content, the ramp would have removed the bush entirely resolving this issue. In fact, the mapblock has a leafy bush to the lower left of that same plant-bush that is effectively removed by the mid section of the ramp. Additionally, this plant-bush can be found placed in other mapblocks using either the content slot or the floor slot depending on the mapblock being viewed. While it is not unusual to place some sprites in a slot different than its intended one when trying to fit multiple sprites into the same tile, this is not the case here since nothing else is being placed into that tile besides the plant-bush.

Anyway, this particular instance should be fixed by merely changing the slot used by the plant-bush in that mapblock to the content slot instead of the floor slot and filling the floor slot with any of the sprites available designed to be used as such.

[psavola]

that's why I'm asking for a save, to see what it is

I don't know what's a "human ghost", I don't even know if it's a friendly unit or alien or neutral, so no idea what conditions apply

There are two trivially created saves (with 'new battle') in the thread I linked.

Even ignoring 'personal light' behaviour changes, the visibility in smoke is very different in 7.9.16 compared to 7.10.

'Human ghost' is an alien unit. Let's ignore this part of my complaint for now, I may have been mistaken (as I can't reproduce the problem).

[donk]

Out of sheer curiosity I decided to investigate possible causes of the ramp bush. Now I've managed to narrow down this particular case as a combination of the Osprey craft and the MOUNTBD_TROPICAL LZ blocks, particulary MOUNTBD02.

While using OXCE New Battle fuctionality I noticed something, the plant-bush in question is visibly overlapping the lowest ramp section and while viewing the mapblock directly with mapview2 I further noticed that the bush is placed in the tile's floor slot, not the content slot. Had it been placed as content, the ramp would have removed the bush entirely resolving this issue. In fact, the mapblock has a leafy bush to the lower left of that same plant-bush that is effectively removed by the mid section of the ramp. Additionally, this plant-bush can be found placed in other mapblocks using either the content slot or the floor slot depending on the mapblock being viewed. While it is not unusual to place some sprites in a slot different than its intended one when trying to fit multiple sprites into the same tile, this is not the case here since nothing else is being placed into that tile besides the plant-bush.

Anyway, this particular instance should be fixed by merely changing the slot used by the plant-bush in that mapblock to the content slot instead of the floor slot and filling the floor slot with any of the sprites available designed to be used as such.

Oh, nice work there.  Nothing to add but it looks like you reproduced it exactly. Since I couldn't destroy the bush I suspected it had become part of the craft since it too is indestructible, but I know nothing of coding and modding so...