aliens

Author Topic: [OLD] Old OXCE discussion thread  (Read 780315 times)

Offline Juku121

  • Commander
  • *****
  • Posts: 1799
  • We're all mad here.
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1185 on: February 14, 2017, 07:49:39 pm »
Has anything changed about the terrain damage formulas, over what's written about the OG in UFOpaedia?

The reason I'm asking this is that I've broken terrain damage in some way, and since I'm not exactly sure what the current formulas are, I'm not able to fix things I don't understand.

Specifically, I've changed all Alien(-inspired) explosives to ResistType: 5 (plasma). The end result is, these explosives now do their nominal damage against terrain, resulting in hilarity like blowing the whole top off a Terror Ship with a Blaster Bomb.

Fiddling around with ToTile damage modifiers, I can resolve this on a weapon-by-weapon basis. A bit hackish, but fine. As a corollary, I tentatively conclude that terrain has 50% armor against explosives and 0% against plasma.

Now comes the weird part. I have two plasma projectile weapons, one with 100 power and the other with 120, both using the 2d100 damage model. If UFOPedia is to be believed, neither should be able to pierce outer UFO walls (armor 100), since 120 * 0.75 = 90 < 100. In practice, the 120-damage weapon pretty much obliterates UFO walls at will and the 100-damage version does so with great regularity, maybe 50-60% of the time as a guesstimate.

I've also seen Dioxine claim that projectile damage is 2/3 - 4/3 of nominal damage. That would make it 50% and 75% chance to blow holes in flying saucers, respectively. Given that I did not do any rigorous testing, this is pretty consistent with my experience. So far, so good.

I then changed the ToTile damages to 60%, making these two weapons effectively do 60 and 72 damage against terrain. Dioxine's formula now disallows any UFO wall destruction: 100*0.6*4/3 = 80, 120*0.6*4/3 = 96, both less than 100. UFOpedia obviously does so as well. But in reality I was still blowing away walls, a small trial run gave me 4 penetrations/28 hits and 7 penetrations/29 hits, making the destruction chances of vvery roughly 10% and 25%.

Since my base is Solarius's X-COM Files, an extensive mod in itself, plus a lot of fiddling with parameters I don't apparently understand well enough, it's entirely possible that there's another factor here that I'm not aware of that screws up the calculations. I'd really like to understand what exactly is going on, though. I'm unable to post ruleset snippets right now, but can do so tomorrow if requested.

Oh, and all these plasma weapons have ToArmorPre: 0.1, but as I understand it, walls and other terrain don't really have any armor values that this would apply to.
« Last Edit: February 14, 2017, 08:30:22 pm by Juku121 »

Offline Yankes

  • Global Moderator
  • Commander
  • ***
  • Posts: 3350
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1186 on: February 14, 2017, 08:22:35 pm »
a) In case of explosions, damage done to tiles is not randomized by `RandomType` property. Is only can be by `RandomTile` that is for default false.
b) HE and PLASMA both have `ToTile: 0.5` by default.
c) Armor of tile is not affected by damage type.
d) `ToArmorPre` and `ToArmor` affect only unit armor. And this stat determine DAMAGE to armor not effective of armor (`ArmorEffectiveness` is for that).

This is rough code flow how explosions damage tiles:

https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2129
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2132
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2243
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2296
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2316
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Battlescape/TileEngine.cpp#L2340


Offline Juku121

  • Commander
  • *****
  • Posts: 1799
  • We're all mad here.
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1187 on: February 14, 2017, 08:48:55 pm »
Damn, almost ninja'd. ;D

a) This is fine, I understand and can work with it. My problem is with non-explosive plasma weapons which are too powerful for some reason, either because I'm misunderstanding the formulas or another mistake like the one in b). What is the non-explosive damage algorithm? It's obviously randomized, but beyond that I can't really tell.

b) Perhaps I left in ToTile: 1.0 by accident. That would do it. By the way, which 0.5 is inherited for DamageType: 3 and DamageAlter: ResistType: 5. I'd guess the HE one?

c) So tile 'armor resistance' is effectively made up of the default ToTile values of various damage types? Good to know.

d) Yeah, that's what I thought. I just wanted to cover all bases.

I have another lower-priority problem as well. There's something wrong with my grenades, and I can't for the life of me figure out what it is. Or rather, I think I know what the problem is, but I have no idea how to go on about solving it. As far as I can tell, sometimes when an Alien tries to use a grenade, it just CTDs the game. This idea is supported by the crash going away when I delete all the grenades from the save. There may be several changes responsible for it, because I've modified quite a number of related aspects (really low strengths to limit unrealistic throwing, changed priming and throwing costs of grenades, etc.) But there are no sneaky features inherent to the grenades, like TU damage going into negatives that I've also caught causing CTDs.

Does it look like some known problem or is there a way to trace the problem? Straight crashes usually don't give much log info.

Offline Yankes

  • Global Moderator
  • Commander
  • ***
  • Posts: 3350
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1188 on: February 14, 2017, 10:43:34 pm »
a) Biggest difference is that it use random range of damage (from `RandomType`) and hit only one element of tile.
b) `damageAlter` is overwritten when you set `damageType`, in your case it will have `damageAlter: ToTile: 0.5`, `ResistType` will be only use when unit is hit.


To find cause of crash best way is prove save and ruleset need to run it. Logs are not many times useful because only information is "its crashed".


Offline Juku121

  • Commander
  • *****
  • Posts: 1799
  • We're all mad here.
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1189 on: February 15, 2017, 01:19:36 am »
a) Biggest difference is that it use random range of damage (from `RandomType`) and hit only one element of tile.
Oh, I see. That’s where the Irwin-Hall distribution screws with my usual intuition. Thanks.

To find cause of crash best way is prove save and ruleset need to run it. Logs are not many times useful because only information is "its crashed".


Try the outdated mod from here against the attached savegame. I’m 90% sure the save’s still compatible. If it’s not, I’ll make a special save for the older version.

Offline Dioxine

  • Commander
  • *****
  • Posts: 5458
  • punk not dead
    • View Profile
    • Nocturnal Productions
Re: [EXE] OpenXcom Extended
« Reply #1190 on: February 15, 2017, 09:11:51 am »
Oh, it's the most egotic person on the planet again :)
If the crash happens when alien is about to throw a grenade, the cause is likely broken route map (nodes at z-1 or somesuch). Use OXCE+, it generates a message if something is wrong with the map. If there is, you need to repair RMPs (nodes exceeding map limits are what you're looking for).
« Last Edit: February 15, 2017, 09:15:27 am by Dioxine »

Offline Juku121

  • Commander
  • *****
  • Posts: 1799
  • We're all mad here.
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1191 on: February 15, 2017, 10:27:41 am »
Happens on plain vanilla maps, too, so it's unlikely. Otherwise Solarius would be hip deep in crash reports right now. :)

But I'll test anyway, it just in case... how do I get advanced logging, again? I recall there being command line parameters in OXCE, but a cursory search turns up nothing. And if you mean just plain openxcom.log, that one's got nothing, either.

It's a useful tip, though, so thanks. Off-topic, and I admit I've not looked for it, but has there ever been some sort of 'modding wisdom' thread where veteran modders share nontrivial tips they've learned over the years? To give you an idea what I mean, tips #1 and #2 would likely be 'if it crashes at midnight, it's probably faulty research' and 'getOneFree really only works on live Aliens... sometimes’.

Offline Meridian

  • Global Moderator
  • Commander
  • ***
  • Posts: 9099
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1192 on: February 15, 2017, 11:00:41 am »
Try the outdated mod from here against the attached savegame.

The linked mod doesn't work for me, see attached.

EDIT: after fixing the bugs, I can confirm that the crash is caused by a node outside of map (coordinates: [6,11,-1]). If you upgrade to the latest OXCE/OXCE+, it will not crash anymore (any new battle that is, the one from the save is doomed already) and give you a nice warning in the log file.
« Last Edit: February 15, 2017, 11:19:30 am by Meridian »

Offline Juku121

  • Commander
  • *****
  • Posts: 1799
  • We're all mad here.
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1193 on: February 15, 2017, 11:54:58 am »
It indeed was the desert terrain that was bugged. Solarius has already fixed this, inconveniently at exactly the same time as he updated to the  new 3.5+ format. Note to self: test features on at least two different terrains before assuming the mistake is in the ruleset.

Sorry for needlessly wasting your time with an already resolved issue. I really do need to upgrade before asking for help again.


Offline Dioxine

  • Commander
  • *****
  • Posts: 5458
  • punk not dead
    • View Profile
    • Nocturnal Productions
Re: [EXE] OpenXcom Extended
« Reply #1194 on: February 15, 2017, 08:10:54 pm »
Why was default grenade unpriming removed? I get that it is covered by 'custom unprime', but removing option useful to 99% so they need to declare every fucking thing like that 1% who needs special unpriming? Why?

Offline Yankes

  • Global Moderator
  • Commander
  • ***
  • Posts: 3350
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1195 on: February 15, 2017, 09:00:15 pm »
Why was default grenade unpriming removed? I get that it is covered by 'custom unprime', but removing option useful to 99% so they need to declare every fucking thing like that 1% who needs special unpriming? Why?
Primary because I made overhaul of handling of unpriming, now is same action like priming. Old code do not fit new one and I decide to remove it (old one was more a hack than proper feature). Probably I did it probably too hastily and I didn't ask how often it was used. I think that I can partially bring back it in next release.
Only difference will be that will have same TU cost as priming not half by default.

Offline clownagent

  • Colonel
  • ****
  • Posts: 380
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1196 on: February 16, 2017, 10:21:25 pm »
I tried to mod in a grenade that explodes instantly and if not thrown in the same turn should explode in hand:

Code: [Select]
    fuseType: -2
    isExplodingInHands: true

But the grenade does not explode in hand.

Is the "isExplodingInHands" tag only working for other fuseTypes?


Offline Yankes

  • Global Moderator
  • Commander
  • ***
  • Posts: 3350
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1197 on: February 17, 2017, 12:37:41 am »
Yes, `fuseType: -2` explode only when throw, image this as bottle of nitroglycerine, you can put it on ground and it will not explode but if throw is go boom.
If you want "real" grenade use fixed time: `fuseType: 0`it will explode at end of turn even if you keep in hand or throw (of corse if `isExplodingInHands: true`).

Offline clownagent

  • Colonel
  • ****
  • Posts: 380
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1198 on: February 17, 2017, 09:24:58 pm »
Yes, `fuseType: -2` explode only when throw, image this as bottle of nitroglycerine, you can put it on ground and it will not explode but if throw is go boom.
If you want "real" grenade use fixed time: `fuseType: 0`it will explode at end of turn even if you keep in hand or throw (of corse if `isExplodingInHands: true`).

If I understand correctly `isExplodingInHands: true` is doing currently nothing for `fuseType: -2`.
Would it be possible to change it so, that the grenade explodes at the turn it was primed, if `isExplodingInHands: true`?

The thought behind this is that I want to prevent pre-priming AND grenade-relay tactics with certain grenades.

Offline Yankes

  • Global Moderator
  • Commander
  • ***
  • Posts: 3350
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #1199 on: February 18, 2017, 12:17:54 am »
If I understand correctly `isExplodingInHands: true` is doing currently nothing for `fuseType: -2`.
Would it be possible to change it so, that the grenade explodes at the turn it was primed, if `isExplodingInHands: true`?

The thought behind this is that I want to prevent pre-priming AND grenade-relay tactics with certain grenades.
Yes, its do nothing but this is consistent with behavior of this grenade on ground (`isExplodingInHands` ==  "inventory work same as ground").
I think proper solution for this is add different fuse type that will explode on impact and at end of turn.