1
OpenXcom Extended / Re: [SUGGESTION] Burning downed unit lighting.
« on: August 13, 2022, 02:48:46 am »
I added light from burning units on ground, for now it give light with power of 10 (normal burning unit give 15).
Welcome, Guest. Please login or register.
Did you miss your activation email? August 15, 2022, 07:34:40 pm
Did you miss your activation email? August 15, 2022, 07:34:40 pm
News: If you can't login, please contact us with your username and e-mail so we can fix it.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
OpenXcom Extended / Re: [DONE][Suggestion] Monthly purchase limit
« on: August 12, 2022, 07:38:57 pm »
Yes, fixed amount is "fun", beside request was to add limit not new sub-game: "hunting for rare toilet paper in shop".
3
OpenXcom Extended / Re: Ctrl+N issues
« on: August 09, 2022, 07:46:18 pm »
right-Alt could be aliased to Alt+Ctrl on Polish keyboard
4
OpenXcom Extended / Re: [SUGGESTION] Burning downed unit lighting.
« on: August 08, 2022, 10:20:35 pm »
Btw unit in hand should give light too? :>
[ps]
Unit light is not cosmetic feature as it affect visibility. But probably it have low affect to gameplay as you need have source of fire to lit unit and use it as torch.
[ps]
Unit light is not cosmetic feature as it affect visibility. But probably it have low affect to gameplay as you need have source of fire to lit unit and use it as torch.
5
OpenXcom Extended / Re: [SUGGESTION] Burning downed unit lighting.
« on: August 08, 2022, 10:05:02 pm »
Probably doable, it performance impact could be similar to electric-flares.
6
Help / Re: unit without corpse (and more)
« on: August 05, 2022, 05:56:46 pm »Even with overKill: 0.0, I would still have to define the corpse, otherwise game would not start, I think.Yes as you can "neutralize" units without killing them. As there is multiple conditions when this can happens only good solution is always require corpse.
I'll just define the corpse, invisible, not a big deal.
I did not realize I could use flatHundred there.
Thanks!
Probably you need create only one corpse like this and share it for every unit that do not need corpse.
7
Released Mods / Re: [COMPILATION] Final Mod Pack (FMP)
« on: August 05, 2022, 03:20:27 pm »
it could be bug in map generation, it it was true it will stay in your save. Next mission on same map type will not have this bug again.
8
Help / Re: Bad color remap [submodding problemo]
« on: August 04, 2022, 06:33:55 pm »
there no `extraScripts` in OXCE, did you mean `extraSprites`?
9
OpenXcom Extended / Re: [Suggestion] Hit side on weapon
« on: August 04, 2022, 06:21:15 pm »
Yes, as I said if weapon do not use ammo then weapon itself is checked for this hook.
Rule of thumb is "item that defined damage type that is used to damage unit".
Rule of thumb is "item that defined damage type that is used to damage unit".
10
OpenXcom Extended / Re: [Suggestion] Default Terrain
« on: August 04, 2022, 12:05:03 pm »
Is this really solution? Modders need update all mapscripts to have it. Probably simpler would be fixing spawn of mission to be correct than fixing all scripts.
I think better would be some global config that is used for cases for lack of texture as it will need lest work from modder and more correct.
As far I understand lack of texture happens when mission is spawned on ocean, this mean outside of any polygon making land.
Because of this we could embrace it and add global `oceanTexture:` that will be used for this case, current value will be "mars" but modder could add different one.
I think better would be some global config that is used for cases for lack of texture as it will need lest work from modder and more correct.
As far I understand lack of texture happens when mission is spawned on ocean, this mean outside of any polygon making land.
Because of this we could embrace it and add global `oceanTexture:` that will be used for this case, current value will be "mars" but modder could add different one.
11
Help / Re: Bad color remap [submodding problemo]
« on: August 03, 2022, 10:33:07 pm »
Its possible that you use different palette do raw your graphic and game use different.
As far I know XPZ use custom palette that have a bit shifted colors.
As far I know XPZ use custom palette that have a bit shifted colors.
12
OpenXcom Extended / Re: [Suggestion] Hit side on weapon
« on: August 03, 2022, 09:23:15 pm »
New hooks: `hitUnitAmmo` and `damageUnitAmmo`
Work exactly same as old ones but are defined on ammo (or weapon if it do not use ammo).
Work exactly same as old ones but are defined on ammo (or weapon if it do not use ammo).
13
OpenXcom Extended / Re: Difference in throwing accuracy for vanilla 2-handed weapons, compared to OXC.
« on: August 02, 2022, 08:21:29 pm »
Probably one of my refactors go to far and apply 2h penalty for this action too.
From my perspective it still have sense as is harder to throw big object using only one hand than using both hands.
Is up to Meridian if he like to restore original cost in this case.
From my perspective it still have sense as is harder to throw big object using only one hand than using both hands.
Is up to Meridian if he like to restore original cost in this case.
14
OpenXcom Extended / Re: [Suggestion] Game Startup Cache
« on: August 02, 2022, 07:56:15 pm »Just in case you are seriously considering changing the yaml parser.I would prefer changing parser than adding brand new serialized/deserializer.
It is probably a good idea to keep an eye on the following bug: https://github.com/biojppm/rapidyaml/issues/289
That one might not play well with flow-style yaml ("{ element1, element2, element3 }").
but yes, when we would switch it, we need check if it work better than old one.
and there could be some current use cases that will be hard to recreate in new parser.
Another problem is new dependency that could be not available in all systems.
Exactly. What if compiling a script needs data that isn't available yet? Even if it's not a problem right now, it could be in the future.I simply try avoid cases like this, because delaying it only make mess in code,
because you need propagate partial results though couple of program layers.
Doable but need lot work to look good and work good.
I like it, but Meridian won't haha... because there's 900 places in the code that would have to be changed to use the faster library. And it would probably have to be done in OXC as well.Yes, but this change is less fundamental than trying adding cache, some of 900 lines could be solved by global regex.
I would start all this by adding `OXCE_YAML` a namespace that replace `YAML` and re-implement all API we use there.
Implementation of it will be simple as forward to yaml-cpp, when its is done then I will put everything in big `#if` and add `#else`
that use different lib as yaml backend. This could be more complex as some features could be lacking in new lib (probably `as<std::vector<int>>()` will be problem) but nothing that could be solved in couple of days.
15
OpenXcom Extended / Re: [Suggestion] Game Startup Cache
« on: August 02, 2022, 06:00:56 pm »
https://github.com/biojppm/rapidyaml
This page clam that load is 70 time faster than yaml-cpp, this mean you will have 70% reduced to 1%.
This page clam that load is 70 time faster than yaml-cpp, this mean you will have 70% reduced to 1%.