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] 4 5 ... 16
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.

OXCE Suggestions Rejected / 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.

OXCE Suggestions Rejected / 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.

OXCE Suggestions Rejected / 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%!

OXCE Suggestions Rejected / 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?

OXCE Suggestions Rejected / 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.

OXCE Suggestions Rejected / [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).

OXCE Suggestions DONE / Re: [Suggestion] Compact save file formatting
« on: July 31, 2022, 11:44:50 pm »
Ok, here's a video. Am I doing something wrong? Is Clean Solution and then Build Solution not a full rebuild?

My best guess is that it builds so fast because i7-10700 has 16 core threads, and cpu usage is 100% during building, so 16x the speed. However, that doesn't explain why running the debug build of the game takes so long - that's a single-thread operation.

OXCE Suggestions DONE / Re: [Suggestion] Compact save file formatting
« on: July 31, 2022, 01:39:46 pm »
After installing a few things... my timings are:
0:07 to start XPZ normally
1:17 to compile in VS2019
2:41 to run debug build game (XPZ)
0:15 to load game (1.5MB sav in battlescape)
It's not some state-of-the-art machine. Just a 2yr old Win10 / 10700 / 16GB DDR4 / 512GB SSD. Under 500€ in total today.
I've read that there are some ways to improve C++ debug build performance in VS, but I'm sure you already know more about that than me. /ZI is already /Zi. /O1 didn't make a difference. /MD fails to compile. /RTC1 didn't make a difference. So, the only thing I can suggest is to upgrade your machine.

Considering how slow debugging is for you, you should be trying to avoid using it to debug common problems people have. In the example you provided, one of the points I was trying to make is that, the problem could've been diagnosed without ever running a debug build.

OXCE Suggestions DONE / Re: [Suggestion] Compact save file formatting
« on: July 31, 2022, 12:49:59 am »
It looks like I've proven myself to be an ignorant fool yet again.

I apologize, I wasn't trying to downplay your hard work. Please forget I said that.

Your debug process is quite... time-consuming to say the least. There are two off-topic questions which I'd like to ask.
How long does it take for you to start oxce+xpz normally, and how long with debugging enabled? What factor are you seeing in game performance decrease between the two?

OXCE Suggestions DONE / Re: [Suggestion] Compact save file formatting
« on: July 30, 2022, 11:13:06 pm »
total time spent: 85+ minutes

That's quite a... pessimistic set of events. Sorry but, I find it too unrealistic.
Ok, so someone says a weapon doesn't work. What does that mean?
Maybe you can't attack? You trigger a weapon and it does attack.
Maybe you can't hit anything? You attack a hostile unit, and hits just fine.
Maybe you can't kill an enemy. You notice that your attacks do 0 damage (you don't need debug mode for that). So that's likely the problem.
So the first thing you'd check is what the damage is based on (arguing that your mind is blank and you don't know what you're looking for is really not the case here). You check the weapon and see the damage is based on psiSkill. For this you usually wouldn't even need to check the save file, but you'd know that what you'd be looking for. So you look at unit's stats and you don't find the psiSkill attribute, which tells you that its value is default, thus 0. Case solved.

But, let me think a bit about what could be a good example. When we don't see an attribute, we don't assume that it doesn't exist, but simply that it has a default value. Because we're smart. Well, because we know that C++ objects aren't javascript objects with dynamic properties. Heh, fuck javascript. Anyway, the problem would have to be with a default value, but at the same time in a case where we wouldn't know which property we're looking for. I... can't think of a realistic case like that. But let's assume that such a case exists. So we're looking through the object properties and don't notice anything unusual. What now? Well, if I was debugging, and I'd notice that the problem isn't in any non-default value, then through the process of elimination, I'd assume that the problem must lie in one of the default values. Great, problem solved. Of course not. The problem wouldn't be solved, and even if I could turn on display of default values here (or if they were already shown), it wouldn't help me, because seeing all the properties and their default values wouldn't easily tell me which one is the culprit. Still, if I know that the problem likes in a default value, it means that I now am "thinking about what I don't see".

Btw, I never proposed that unit stats should be hidden if default. They're a rare case where you'd want to show an attribute despite it having a default value, because I think they're very commonly searched-for attributes.

Btw², does turning on debug mode really make your game take 20min to start?

I make some improvements

Thanks a lot~

OXCE Suggestions DONE / Re: [Suggestion] Compact save file formatting
« on: July 30, 2022, 03:26:30 pm »
a missing attribute simply makes it harder for me to spot the cause of an issue.
I don't quite understand this argument.
1. Based on my personal experience, showing all the values usually makes it much more difficult to debug and spot any issues because issues usually arise from values that were modified - the non-default values. So by hiding default values, you're able to easily see only the ones that are interesting.
2. Debug mode. If you want to debug in a way that shows all the values and not just the non-default ones, then that should happen when a certain debug setting is turned on. Like in the pedia article details, you have a "defaults" button to show default attributes. It's good that the button exists, because sometimes checking out the default values is useful, but usually it's more useful to filter out the non-modified attributes.

2/ Single lines sometimes help readability, sometimes they hurt readability. We'll be changing those that help us (us = Yankes + Meridian). We won't change the ones that hurt; or the ones we don't care about too much.
Well, when you're deciding on which ones help the readability, a simple guideline that I'd suggest would be:
- if you format an object/array to a single line, and in the majority of times this line doesn't exceed n characters (what n is is debatable; for programmers, most common is 80, sometimes 120), then readability of this object/array would be improved.

For instance
Code: [Select]
    - 10
    - 20
    - 0
Code: [Select]
  position: [10, 20, 0]In this case, the readability is improved in the 2nd case because formatting the array into a single line will never exceed 80 characters.

Please don't "compact" anything, it serves literally no purpose (you're not going to miss a few MB).
I think you misread the topic title. It's not about reducing sav file size (tho that's a byproduct), as it is about making it more readable.

OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread
« on: July 28, 2022, 02:30:22 pm »
Works now ::)

OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread
« on: July 28, 2022, 02:01:51 pm »
A fatal error has occurred: Interface articleTextImage not found

Pages: 1 2 [3] 4 5 ... 16