1
OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread
« on: April 26, 2024, 04:33:48 pm »
There is global limit for max light radius for units, it could be possible by default be around 20.
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.
Added. The OP is now officially full.cannibale your next post for rest of list :>
Hmm, should I make a new thread, or is there some moderator/administrator ability to reorder posts (probably not)?
Let me rephrase the famous quote: this is one small commit for a developer, one giant push for the community. I started literally from hating C++ and especially C++ pointers with passion, I was only moved by how awesome XPZ was and that I wanted to add some features, because I felt that they were missing.Yes, longer you work with code base then better your code is.
In my fork, my commit history and repository looked like a nightmare, as my code changes. All stupid questions like "what std::vector<int> does?" were forwarded to ChatGPT. You've pointed out my mistakes, just as Meridian done. And the more I looked at the original code and how organized it, the more I tried to follow the suit. I've seen how documented code is via comments - so I tried to document all my code changes just as well.
Then you pointed out about my repository and I started to google how to operate it in more precise manner in order to reorganize it and eventually I reorganized it into "single commit = single feature" approach, so it will be easy to see what exact code changes are related to that feature. And thanks to the vehicles/soldiers capacity commit as modifiable stats that Meridian rewrote - I've better understood the correct way to code on C++ and what mistakes I've done.
It all started with small steps for me with a nearly zero C++ coding experience (I avoided it due to the pointers). And now I frown at C# references, because in C++ you clearly can define if something is an object or a pointer to the object.
It all depends whether people are willing to learn, or will they whine at somebody else that "lots of OXCE features are underdeveloped" - I chose the former and rewrote some features a couple of times already and I don't regret it in the slightest. If anything, I'm thankful that I had chance to learn from code written by people with experience.
Then there were Y-Scripts, which I discovered quite late. It took some time to understand how to use it, but later I found that very many things can be handled via Y-Scripts. By the way, it does remind me a simplified version of assembly (the 'command/function var1 var2' part) that doesn't use CPU instructions sets and instead uses rather precise variables and functions (that are exposed to Y-Script).Yes, it was nearly literary assembly like language before I start push it further.
Now the on topic question itself. Since you're saying that it is possible to tweak costs of the items via Y-Script - what hook should I use for it (which one you'd use)? Because I already have a couple ideas, such as better connections to the merchants/country/service that reduce items cost.It not possible now, this is possible feature I consider. Plan would be adding `buyItemPrice` and `sellItemPrice`, at first it would have only access to item rule object and save game but next could be added current base too.
Don't scripts have the same 'beginning programmer only with help of ChatGPT' problem, except without ChatGPT since y-scripts are a language perhaps two dozen people in the world have some proficiency with, if that?
I can see that adding something like a thousand variables to an item, with bespoke code for each, is madness from a maintenance/debugging POV at the very least, and you do need to discourage that path.
OTOH, offloading that to (mostly) amateurs writing their own code doesn't seem to be terribly better.
Hmm, is there a performance cost for using y-scripts, as there usually is with higher-level languages?
One solution I can think of would be to offer a library (thread?) of sample scripts to showcase their use. And if a feature request is deemed to be too much for too little gain for regular OXCE development, but scripts look like a passable replacement, add a script snippet to the library. So those who want the feature can get started - since, if an OXCE dev thinks something is better doable with y-scripts, he must also have a rough idea how to begin implementing it.Yes, there is already couple of threads where examples like this, effective whole `OXCE Support Y-scripts` was created for this.
Currently, scripts kinda work like that, but with far less organisation. They propagate in mod files, which are scattered in many places, and are sometimes copied over without too much thought given to what exactly it is that they're meant to do.
<snip> And yet, here I am, implemented whole pack of features for my own submod (and some of the have made their way into official branch/release). I actually had fun writing C++ code for OXCE. And for dumb C++ question you can use ChatGPT to answer them, just like I do.