[Suggestion] Sell/Buy prices (Y-script)

[Yankes]

<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.

I would prefer code form people who know what they do, this mean beginning programmer only with help of ChatGPT. Mainlining long term projects like require lot of work and half-baked features only increase this cost (like long debugging session with questions like "what should happens when X? Should be Y or Z?").
For personal fork this will work fine as all burden is on owner of this fork not on OXCE or OXC
(it look we start having healthy community of forks, at least 4 major, but still some time to Doom community).

On another hand "I'm not programmer" is not avoidable even if any feature like this will be added as only possibility I see is to add y-scripts hooks for it.
Tweaking some costs by new flags cost more than its worth IMHO, scripts on other hand are lot harder to implement and use but have infinity more uses and power than any new flag in item. In long run could fundamental change how whole sell/buy work form gameplay perspective.

[Juku121]

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.

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.

[Yankes]

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?

True, y-script is bit niche but to know basics you can read one page of wiki.

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.

Biggest grain is that we do not maintain code/features that we think is "bad", scripts can be abused in many ways and as long
they are keep in some range engine is fine. Example is `damageUnit` script can arbitrary kill any unit. Engine is fine with it because its
already need handle common case when health gets to zero.
Someone could add script "insta kill anything by player", same weapon in alien hands can't do that. I would never add
flag to ruleset that could allow similar behavior because this is stupid, but as script, your game your business.

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?

Performance is good, first in all, first use of scrips was recolor of each pixel on units and this need be FAST other wise framerate will tank.
(Probably recoloring every tile on screen will be bit too much for it)
Overall couple of small tests show that my script engine should be around 5x slower than C++ and this is lot better than average Python.
Of corse this is only possible because my script engine is brain-dead and it directly use C++ pointers without overhead (not counting obligatory null checks).

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.

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.

Yes, there is already couple of threads where examples like this, effective whole `OXCE Support Y-scripts` was created for this.

[WarStalkeR]

I would prefere code form people who know what they do, this mean beginning programmer only with help of ChatGPT. Mainlining long term projects like require lot of work and half-baked features only increase this cost (like long debuging session with questions like "what should happens when X? Should be Y or Z?").
For personal fork this will work fine as all burden is on owner of this fork not on OXCE or OXC
(it look we start having healthy community of forks, at least 4 major, but still some time to Doom community).

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.

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.

On another hand "I'm not programmer" is not avoidable even if any feature like this will be added as only possibility I see is to add y-scripts hooks for it.
Tweaking some costs by new flags cost more than its worth IMHO, scripts on other hand are lot harder to implement and use but have infinity more uses and power than any new flag in item. In long run could fundamental change how whole sell/buy work form gameplay perspective.

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).

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.

[Yankes]

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.

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.

Yes, longer you work with code base then better your code is.
"atomic commits" (aka "single commit = single feature") is must have in project as our.

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 probably most "not assembly" operations now is `if` and `loop` as they are decomposed to multiple smaller operations.

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.
Next step would be add script `buyItem` and `sellItem` that could even allow some "economy".

[WarStalkeR]

Yes, longer you work with code base then better your code is.
"atomic commits" (aka "single commit = single feature") is must have in project as our.

Frankly, I liked that approach very much. I have dedicated repository for testing, where I create temporary commits. And then, when everything is ready, I squash these commits into atomic commits in my release repository. Keeps everything clean and organized.

Yes, it was nearly literary assembly like language before I start push it further.
Now probably most "not assembly" operations now is `if` and `loop` as they are decomposed to multiple smaller operations.

Thanks to these most "not assembly" operations Y-Script is quite easy to handle, compared to real ASM 80/86.

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.
Next step would be add script `buyItem` and `sellItem` that could even allow some "economy".

The question is what will you be using as a hook for it? As this change only needs to happen, when you open purchase/sell screen, no?

[Yankes]

Yes, when you open screen then it will calculate price of buy/sell, there is always performance considerations, but if someone do not try load all possible researches then script in hook should run fast.
As this will be read-only hooks, then it could be possible to cache results too if performance will be concern, and make updates once per day or some thing like this.

[Meridian]

Extracted into a separate thread.