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.

Messages - Delian

Pages: [1] 2 3 ... 14
Added two new global ruleset settings aimMultipliers and armorMultipliers, which function the same as the existing aimAndArmorMultipliers, but for each own difficulty feature. These two new settings have priority over aimAndArmorMultipliers, so if all three are set, then aimAndArmorMultipliers has no effect.

Code: [Select]
aimAndArmorMultipliers: [0.75, 1.0, 1.0, 1.0, 1.33]
aimMultipliers: [0.75, 1.0, 1.0, 1.0, 1.33]
armorMultipliers: [0.75, 1.0, 1.0, 1.0, 1.33]

OpenXcom Extended / Re: [DONE][Suggestion] Monthly purchase limit
« on: August 13, 2022, 12:18:34 am »
Thanks a lot for implementing this.

it makes the item’s amount every month utterly predictable.

Predictability = Boring + No mystery + No fun

You do realise that... by default all items have no purchase limits. Which is predictable. So you're saying that the game and all the mods are already boring + no mystery + no fun? Why are you here if you hate this boring no-fun game so much lol

X amount that can be in between 0 and ten.

For such a feature to be practical, you'd need UI with sliders, like the one xcomapoc has. It would be too much work trying to replicate that UI. Also, that UI would only work well if ALL the items had their limits and market info set. So it would also be incompatible with all the existing mods.

XPiratez / Re: Stuff I'd love to see in XPiratez!
« on: August 09, 2022, 07:49:18 pm »
I'd like it if a change was made to CHOKING and BIO damage weapon/ammo.
The change would be:
- halve ToStun value
- set RandomStun to false

The reasoning is that, there should be less randomness with stun damage on these weapons. When you're breathing air, there is no random chance whether you'll breathe the air into your lungs or not. You always will (otherwise everyone would asphyxiate eventually due to a bad rng roll lol). So when you're choking, it makes no sense that sometimes you'd get stunned, and sometimes you wouldn't. I think that's quite unrealistic.

Similarly with BIO (poison) weapons. Either the poison is effective on the target, or it's not. There should be no stun randomness from one shot to the next. Consider the following scenario:
You shoot a guy, and he's like, "Haha, you did nothing, I'm immune to your poison!". And then you shoot him again, "Oh no, this poison is very effective, I'm passing out!".
The first shot and the second shot used the same poison, so obviously the above makes no sense. When you take a drug, you expect it to always work, and it's the same with poison.

I think that if the stun damage RNG on these weapons was removed (and stun damage halved, so that the average remains the same), it would make the mod feel more realistic, and it would make the game experience better due to better consistency.

The items I suggest changing are:
Fire Extinguisher
Foam Grenade
Universal Refresher
Auto-Harpoon Clip/Poison
Blowpipe Poison Darts
Sleep Dart Clip (might also rename to Poison Dart Clip, because Tranq Dart Clip is already for sleep)
Poisoned Arrows
Scourge Clip/BIO
Cobra Staff (aimed shot)
Poisoned Dagger
Plague Bug

XPiratez / Re: A thread for little questions
« on: August 09, 2022, 04:19:59 pm »
They could be infinite, if they were configured like that. But they're not. In N1, the few missions that have them only spawn reinforcements 1-2 times.

XPiratez / Re: [MAIN] XPiratez - N1 29-Apr-2022 Every Day Is Caturday
« on: August 07, 2022, 02:00:41 am »
You produce "Recruit: Outlaw Catgirl" to turn the captive into an Outlaw Catgirl

XPiratez / Re: Bugs & Crash Reports
« on: August 06, 2022, 03:55:23 pm »
PARTY DRESS /CAT has Bare Hands instead of Nekomimi claws. Is this intended?


XPiratez / Re: [MAIN] XPiratez - N1 29-Apr-2022 Every Day Is Caturday
« on: August 04, 2022, 09:24:15 pm »
if it makes some other thing redundant
My opinion is that, as things stand, "Gals Are Superior" and "We Need Male Touch" are redundant because Peasant Revolution perks are too strong, while its downsides are easily mitigated (ubers and slave soldiers are easy to come by). I'll pick this path even when I'm not peasant enjoyer, because it provides for the strongest early and mid-game bonuses.

But why would ubers not be able to use the Harvester? On what ground?
I'm sure you can think of some sort of lore that would make it possible. For instance, "This craft is a flagship of revolution, so it goes against our principles for other races to use it." or simply "The engineering design of this craft prevents non-peasants from operating it."

XPiratez / Re: [MAIN] XPiratez - N1 29-Apr-2022 Every Day Is Caturday
« on: August 04, 2022, 09:04:11 pm »
you can easily cheat on peasant path by not using peasants

First time I hear that that would be considered cheating. For all players know, it's intended behavior that they can put whatever they want on that craft.
Besides, even if we ignore the HARVESTER, Peasant Revolution is already the best path because Revolution HQ is also OP~

You know, if you wanted to, you could easily request a feature that would prevent players from adding non-peasants to the HARVESTER. Where was it... ah, here. Basically, add a "allowedSoldierTypes" property to crafts that would allow you to specify such limitations. But you could also simply prevent players from recruiting any ubers and other OP soldiers when on that path.

XPiratez / Re: [MAIN] XPiratez - N1 29-Apr-2022 Every Day Is Caturday
« on: August 04, 2022, 12:11:56 am »
Hello. Today I would like to complain about how overpowered HARVESTER is.
Firstly, 20 crew would be fine if they were all peasants, but peasants aren't what people put on that craft. They put ubers, armored cars, lokk'naars, everything except peasants lol. Other than some late game transports, nothing comes close. Well, there's CONVOY, but that one's way slower and more dangerous to do missions in.
Secondly, camping in this craft is too easy because no windows.
And lastly, you can block lifts so melee enemies can never reach you.

OpenXcom Extended / Re: [Suggestion] Game Startup Cache
« on: August 03, 2022, 10:02:23 am »
Actually I like your solution better than mine. I think the decrease in saving/loading time is a sticking point. But I also think it would be the hardest to implement, because most of the API is different. It's definitely too much for me.

OpenXcom Extended / Re: [Suggestion] Game Startup Cache
« on: August 02, 2022, 07:27:30 pm »
`afterLoad` was added only because some data is not available when you load one file and you can't link objects to each other.
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.

And this could have another benefit of improved speed of saving/loading.
This will be very invasive change but if gain will be reduction of 70% to 10%?
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.

OpenXcom Extended / Re: [Suggestion] Game Startup Cache
« on: August 02, 2022, 05:26:01 pm »
And versioning? I could create cache, then install new version of OXCE and then what? it will load incompatible byte data?
You're right. OXCE exe file info would also need to be included in the hash. So if any Rule object changes, the exe file changes, hash changes, and it invalidates the cache.

Beside I still hold my stance that if you do not refactor whole loading process you will not archive your goal.
For start I can say you do not success as one thing you would need serialize script code that can have embedded pointers.
Have fun reinterpreting byte array for search of them.
Hmm, that does sound like a problem. I guess the solution for that would be to postpone script compiling until after the Rule objects are loaded. So what would be serialized instead would the script text.
You know, after checking the code, the pointers might be less of a problem than I thought, because all the linking (pointer setting) is already happening in the afterLoad() functions of the objects. But yeah, a little bit of refactoring would be necessary to move script compilation from load() to afterLoad(). I might need your help with that!
For instance, in the RuleStatBonus::load(), first the script text is generated, and then _container.load(parentName, script, parser); is called to compile the script. How would I change this function so that script text is saved, so that I'm able to compile the script code later?

Btw, I think it's a bug that script compilation is already happening in load() instead of afterLoad()... the load() function was supposed to only extract data from YAML.

What exactly take most of time during load?

Inside the loadMods(), 70% of the CPU time is consumed by YAML::load() - just YAML parsing, and 30% by Rule generation. At least in large mods. So a much easier solution would be to de/serialize the parsed YAML::Node objects instead of the Rule objects. But then the end result would be only a 70% reduction of loading time...

I have personal experience of helping implementing and using a serializer/deserializer commercially at work
So do I, but that was a different language, different format, and much smaller in scale.

If the change is not too invasive, it can be considered.
If we'd need to "rewrite" all the Rule* classes, then it's a no go.
That doesn't sound very reassuring.

I think this would be a far better and saner approach.
But but... only 70%!

OpenXcom Extended / Re: [Suggestion] Game Startup Cache
« on: August 02, 2022, 12:09:27 pm »
My C++ experience is rather poor, so it may take a while.

If it works as intended, you'd accept this feature?

Also, do you have any other comments or tips for implementation? Anything to watch out for?

OpenXcom Extended / Re: [Suggestion] Game Startup Cache
« on: August 02, 2022, 11:36:24 am »
How you plan cache pointers?
A two-pass algorithm that uses an object-ID map.

Or deep nested structures?
You write a schema. It's all flat in the memory. Unless you're talking about pointers.

And how exactly fast is this deserialization? This will not be simply `memcpy` from file
as game use strings that could have arbitrary length.
It's very fast~
Strings are just arrays/vectors of bytes. Either you store the string length, or it's null-terminated.

I see this near impossible without rewriting every rule object from scratch to to be easy serializable.
It's neither impossible, nor is it dramatic that it would require full rewrite. Writing schemas can take a while tho.

OpenXcom Extended / [Suggestion] Game Startup Cache
« on: August 02, 2022, 12:22:04 am »
If the YAML files don't change, why parse them every time you run the game?

Currently, when you start up the game, the majority of loading time comes from loading the YAML files and from using that data to produce Rule objects.

I suggest this be optimized using a simple cache. Here's the preliminary idea's process:

1. Start up the game
2. Produce a hash from the YAML files that the game intends to load. The hash is created from the YAML file names, file sizes, and modification dates, plus from the exe file
3. Compare the hash to the cache hash
4a. If the hashes don't match (YAML files changed):
- Clear the cache
- Start up the game normally. Parse the YAML files and load the Rule object
- Create a new cache. Serialize all the Rule objects into a binary format cache file, and save the hash as a new cache hash
4b. If the hashes match (YAML files didn't change):
- Deserialize all the Rule objects from the cache file

For de/serialization, I suggest using FlatBuffers due to its deserialization speed.

Depending on the mods used, this approach could reduce the game startup time by up to 90% (+5% if a similar cache is used for the language files).

Pages: [1] 2 3 ... 14