Messages

1

Help / Re: AI unit immune to zombification?

« on: April 24, 2024, 02:13:38 am »

Not immune, more "zombifaction do not apply". If alien try apply this effect on another alien effect is canceled.
Any other combination should work, player vs alien, civilian vs alien, player vs civilian.
If this behavior is not wanted, scripts can always override it (`to_transform`)  or even replace by custom logic (`unit.setSpawnUnit`).

2

OXCE Bugs / Re: Zigzag?

« on: April 21, 2024, 05:33:46 pm »

I too do not see point in crippling pathfidning, beside as I previously said for short paths game try keep straight paths.
If you want have more control move units in short steps.

3

40k / Re: ROSIGMA 40k failed to load

« on: April 18, 2024, 11:37:56 am »

This is mod issue as log clearly say

[ps]

best post it in ROSIGMA dedicated error thread

4

OXCE Bugs / Re: Zigzag?

« on: April 12, 2024, 05:19:29 pm »

This is only bug if cost moving in straight line is smaller, if cost is bigger then this is feature as allows unit do more after reaching destination (more TU left to shoot or kneel).

5

OXCE Bugs / Re: Zigzag?

« on: April 12, 2024, 02:04:28 pm »

Short paths do not use complex pathfinding, if there is direct move then game use linear path even if is not optimal.
Long paths try find best move that have minimal cost to reach destination. As we see on screenshot there are objects (grass) on paths that
unit try move. If this grass affect move cost then pathfinding try avoid it as max as possible.

6

OXCE Support / Re: I can't start OXCE/Brutal-OXCE

« on: April 09, 2024, 09:22:40 pm »

And what is in log exactly?

7

OXCE Support / Re: I can't start OXCE/Brutal-OXCE

« on: April 09, 2024, 06:06:24 pm »

your log show bug that happes in one version of `7.12`, you need have lasterst version at least `7.12.4`
(backup server with win builds is http://108.61.157.159/versions/win/ )

could you post logs from nevest version?

8

OXCE Support / Re: I can't start OXCE/Brutal-OXCE

« on: April 09, 2024, 03:26:55 pm »

Install new version, in one recent version was bug that spam logs with useless messsages

9

The X-Com Files / Re: [submod]Submod list for XCF

« on: April 08, 2024, 01:16:22 am »

Added. The OP is now officially full.


Hmm, should I make a new thread, or is there some moderator/administrator ability to reorder posts (probably not)?

cannibale your next post for rest of list :>

10

OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread

« on: April 05, 2024, 11:16:39 pm »

Small change to craft equip screen, in OXCE 7.12.4 items too can use `customItemPreviewIndex: [21]` like vehicles did.

Example of this working:

[ps]
until lxnt.wtf is down I make backup server: http://108.61.157.159/versions/win/ (soon new version should be ready)

11

OXCE Suggestions Y-script / Re: [Suggestion] Sell/Buy prices (Y-script)

« on: April 01, 2024, 04:06:09 pm »

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.

12

OXCE Suggestions Y-script / Re: [Suggestion] Sell/Buy prices (Y-script)

« on: April 01, 2024, 01:03:16 pm »

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

13

OXCE Suggestions Y-script / Re: [Suggestion] Sell/Buy prices (Y-script)

« on: April 01, 2024, 01:55:17 am »

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.

14

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

« on: April 01, 2024, 12:02:16 am »

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

15

Suggestions / Re: "Know Thy Enemy" from UFO Extender

« on: March 30, 2024, 12:21:14 pm »

Technically "Know Thy Enemy" feature can be made by any other user? (based on current OXCE build)
Or even if someone wants to make it by himself today - then he have to wait some time for upgrade OXCE power?

I do not understand what you try to say here, without code change no "user" can add features like this.
Change like this will not be added deliberate (like Meridian said) only possibility it happens is as side effect of other changes.

And in this case this should be already possible, y-script have access to research and to aliens units, combining both you could allow
more damage for aliens that was already researched.