[OLD] Old OXCE discussion thread

[clownagent]

Doable, but it will need wait because my queue is full right now.

No problem, I will do it with the method Solarius suggested.

[HelmetHair]

Yankes,

would you be willing to share your feature queue? I'm having a shit week and need something to smile at.

-HH

[clownagent]

Not sure if it helps, but you can design a 1 bullet weapon which disappears after shooting and give it arcing shot... That's how many weapons work in Piratez. Then you can have custom fireSound.

EDIT: I forgot, but you'll probably have to add max range too.

Good idea.
Is the maxrange always a fixed value, or can I define it as strength dependent?
Something like:
maxRange: 0.5* strength

[Yankes]

Yankes,

would you be willing to share your feature queue? I'm having a shit week and need something to smile at.

-HH

This week releasing version 3.3 with:
new lighting (next week will I will probably spend on optimization of this based of people feedback)
scripted visibility
option for reserving more space for mod in common sets like HandOb

I had plans to add some other small features but because other take me too much time to finish, I push it to next release.
This was global throw properties and directional lights/flashlights.
In 3.4 I plan add scripts that will be able directly change state of unit (it will be call at end of each turn or when unit get hit).
After that in 3.5 I would like to merge with nightly and cherry pick commits some from Meridian branch.

Hard to say when 3.4 and 3.5 will be ready, usually my prediction miss a lot.

Good idea.
Is the maxrange always a fixed value, or can I define it as strength dependent?
Something like:
maxRange: 0.5* strength

Right now its fixed value.

[Solarius Scorch]

Great news, Yankes!

Will 3.3 include newer nightlies?

Is the maxrange always a fixed value, or can I define it as strength dependent?

AFAIK it's not possible yet. Unless Yankes could write a script or something.

[Yankes]

Great news, Yankes!

Will 3.3 include newer nightlies?

AFAIK it's not possible yet. Unless Yankes could write a script or something.

After that in 3.5 I would like to merge with nightly and cherry pick commits some from Meridian branch.

This mean that 3.3 will still based on old nightly.

[Solarius Scorch]

This mean that 3.3 will still based on old nightly.

Right, I thought it could be something half-way. But nevermind, thanks!

[Meridian]

After that in 3.5 I would like to merge with nightly and cherry pick commits some from Meridian branch.

I'd like to ask for some time (cca 1-2 months) between updating OXCE to latest nightlies (3.5) and picking stuff from my branch (maybe 3.6?).

I'd like to review all my commits, make a new branch and prepare new commits worthy picking and maybe even going to vanilla.
The cleanup would include:
- full translation support
- full interface support (i.e. separate ruleset for colors and similar stuff on new GUIs)
- full TFTD suppport
- merged multiple commits together (like original commits + its bugfixes)
- reorder commits a bit for easier cherry-picking
- split some commits (into OXC-compatible part and OXCE-extension)
- etc.

Basically I'd like to make a branch, which wouldn't be called "prototype" anymore... but I need OXCE 3.5 (with latest nightlies) for this work... for which I am waiting patiently, no rush.

[Yankes]

I'd like to ask for some time (cca 1-2 months) between updating OXCE to latest nightlies (3.5) and picking stuff from my branch (maybe 3.6?).

I'd like to review all my commits, make a new branch and prepare new commits worthy picking and maybe even going to vanilla.
The cleanup would include:
- full translation support
- full interface support (i.e. separate ruleset for colors and similar stuff on new GUIs)
- full TFTD suppport
- merged multiple commits together (like original commits + its bugfixes)
- reorder commits a bit for easier cherry-picking
- split some commits (into OXC-compatible part and OXCE-extension)
- etc.

Basically I'd like to make a branch, which wouldn't be called "prototype" anymore... but I need OXCE 3.5 (with latest nightlies) for this work... for which I am waiting patiently, no rush.

Ok, no problem. I think if you wait for 3.5 I will skip thing I want do in 3.4 and start right now with 3.5 (I could use 3.4 number for that but I prefer "round" version number for that milestone ).

[Yankes]

Ok new version 3.3 is ready:

New light system.
Option for reserving more space for mod in common surface/sound sets.
Visibility scripts that determine visibility of targets.


I mostly interested in how my new light system is performing on peoples machines.

[Meridian]

FYI, I got many conflicts in rather sensitive functionality, so OXCE+ will be updated a bit later (2-3 weeks depending on my time allowance).

I will need to revert, reimplement an retest night vision, heat vision and psi vision.

On the bright side, I have cherry-picked the option to increase modOffset for mods, so at least that can be implemented in XFiles/XPiratez and tested.

[Yankes]

FYI, I got many conflicts in rather sensitive functionality, so OXCE+ will be updated a bit later (2-3 weeks depending on my time allowance).

I will need to revert, reimplement an retest night vision, heat vision and psi vision.

On the bright side, I have cherry-picked the option to increase modOffset for mods, so at least that can be implemented in XFiles/XPiratez and tested.

Right, I probably need cheery pick your visibility changes as promised that my will be compatible with yours.
Any thing else was conflicted?

[Meridian]

Right, I probably need cheery pick your visibility changes as promised that my will be compatible with yours.
Any thing else was conflicted?

There was something around calculate line/trajectory, I didn't check it in detail, it might conflict with Karadoc's bow fix... to be confirmed.
Other than that it looks fine.

[Yankes]

Small recap what is possible with new visibility scripts:
a) Some unit can be visible only to some other units, something like A can see B, C can see D but A cant see D and C cant see B.
b) Items in hands can affect visibility of units, you can add NV googles that need be held in hands to allow see in darkens or masking device that will cloaking you.
c) Effectiveness of visibility is stored as integer value. Greater than zero mean that other unit is visible. This allow gun scope that add value to that number increasing effective sight radius of unit. Alternative you can subtract to recreate some camouflage. As IR visibility should not be affected by scopes or normal camouflage, I added option for distinguish between different visibility modes. Normal visibility (in visible light lengths) is defined by empty value `null` other types can be defined by new tag in `BattleUnitVisibility`.
d) You have access to raw data of smoke and fire density, this allow you to change how smoke affect visibility or allow fire to prevent use of IR.
e) You can add penalty for NV googles if target is in bright spot, or simply add bonus/penates based on relative lighting level of tiles where units stand (current and target) to simulate that you can't see thing in shadow.
f) All units stats can contribute to visibility. You can made cloaking device that will fall or reduce it effectiveness when unit lose hp (or current TU).

Things I would like to add in some future:
a) Visibility that ignore walls.
b) 360 degree visibility (right now it sill use old FOV cone).
c) Drawing of unit will get info how other units see it, e.g. "Is this unit normally visible?", "I can see it only using IR or Psi?".

[bladum]

Yankes, please consider below features:

1) object like crafts or bases displayed on geoscape can have custom sprite, also size other then 5x5 pixels. Also different one in case hyperwave decoder is used (unknown ship / known ship), maybe even different sprite based on current ship status.
2) crafts can have optional weight limit, that could limit how much items weight can carry. This is opossite to number of items in original game. This could lilmit items that can be take for battle but also items salvaged from battle (like elerium).
3) damage inflicted to unit can be displayed as number on the top of the unit (like in many RTS games)
4) base defence buildings have N shots not just one. This could be used for cannons that fire many Times with minimal hit Chance.
5) damage taken to alien craft durig base assult should define number of aliens that will die in turn 1 of the battle.
6) alien intelligence can be splitted into two variables:

Alien will remember any soldier he spots in his field off view for N turns where N = intelligence, other aliens are not aware of these soldiers
Alien will make other aliens remember any soldier he spots in his field of view for K turns where K = group intelligence (new alien stat)
Alien will pass his memory of soldiers to any other alien that is with his field of view for M turns, where M = telepathy (new alien stat, optional, very complex to implement but could be helpfull to create chain of memory strategy for aliens, so xcom can pass grenades and aliens could pass positions of xcom soldiers that way)

So IQ =  5 and Group IQ = 1, means that alien will remember spotted soldier for 5 turns + he will make other aliens remember them for additional 1 turn

Using this engine we could implement standard behavior from X-COM but also bring much more for mods.

More here https://github.com/Bladum/OpenXcom/commits/master

Thanks
Tom