[OLD] Old OXCE discussion thread

[Meridian]

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.

So, this is what I had to revert to get a clean merge:
- camouflage and anti-camouflage
- heat and psi vision
- night vision by Stoddard
- LoF fix by karadoc

I'll try to add them on the merged version again, but I may need some help from Stoddard and karadoc on their commits... we'll see.

[Yankes]

So, this is what I had to revert to get a clean merge:
- camouflage and anti-camouflage
- heat and psi vision
- night vision by Stoddard
- LoF fix by karadoc

I'll try to add them on the merged version again, but I may need some help from Stoddard and karadoc on their commits... we'll see.

I will look on this too. In my case half work is done because I write part of it.

btw did you play with my new lighting? Do you have any feedback about how it work or its performance?

[Stoddard]

So, this is what I had to revert to get a clean merge:
- camouflage and anti-camouflage
- heat and psi vision
- night vision by Stoddard
- LoF fix by karadoc

I'll try to add them on the merged version again, but I may need some help from Stoddard and karadoc on their commits... we'll see.

Push a branch to github, I'll merge and do pull requests as needed. There wasn't anything complicated in the night vision though, I think I got off with int shade parameter in reShade().

[Yankes]

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

1) Maybe
2) This probably will cause lot of problems when you reach limit after mission. Without special UI it will not work and I prefer not change UI.
3) Again this is UI change that I avoid.
4) Maybe
5) This could be useful
6) Probably too complex for small grain, difference to current behavior will be probably not visible for player.

[Meridian]

btw did you play with my new lighting? Do you have any feedback about how it work or its performance?

Not yet. I'm not at home, I'll try over the weekend.

Push a branch to github, I'll merge and do pull requests as needed. There wasn't anything complicated in the night vision though, I think I got off with int shade parameter in reShade().

I've seen the playmix3.3 branch.
I guess that was done in a hurry. The night vision shading method code is duplicated in two almost identical methods and the conflicting changes from Yankes were semi-reverted/semi-duplicated.
I'd like to avoid that and use the change from Yankes rather than going around it.
I'll give it a try myself first this week, and if it doesn't work, I'll push what I have and ask for help.

[Stoddard]

I've seen the playmix3.3 branch.
I guess that was done in a hurry. The night vision shading method code is duplicated in two almost identical methods and the conflicting changes from Yankes were semi-reverted/semi-duplicated.
I'd like to avoid that and use the change from Yankes rather than going around it.
I'll give it a try myself first this week, and if it doesn't work, I'll push what I have and ask for help.

Yes, it was a rush job, just to take a look. It didn't randomly crash and that was enough. Of course it should be redone properly. I'll be redoing all my branches after this merge anyway, I'm doing them wrong right now.

[Meridian]

I'll be redoing all my branches after this merge anyway, I'm doing them wrong right now.

I'm planning that too, sigh. It's a mess by now.
I guess it's a curse of being a fork of a fork... or a fork of a fork of a fork in your case

[Meridian]

@Yankes: There has been a change in map rendering from 3.2 to 3.3, which I don't fully understand... can you explain why did it change?

Or, at least, where should I put the night vision re-shade functionality within the getWallShade() method... on individual components (if so, which ones exactly) or at the end on the return value?

Comparison attached. Hopefully understandable enough.

PS: there are together 4 such places with the new getWallShade() method.

[Yankes]

This was added to allow light "bleed" through doors. Without this you will never see doors if you approach them from behind.

[Meridian]

OK, I have finished merging yesterday.
Looks quite good.

I tried doing some performance measurements, but doing it properly would take many different scenarios and a lot of time.

Just as example, I measured:
1. the drawTerrain() method
2. and a walking animation using full TUs

Results were in average about 10% worse on v3.3 compared to v3.2.

drawTerrain(): 10 measurements
- v3.2: times between 2900 and 4000 micro seconds... averaged ~3350 micro seconds
- v3.3: times between 3300 and 5800 micro seconds... averaged ~3700 micro seconds

But given the big spread, it might also be just a measurement error

walking animation: 5 measurements, with much smaller spread, so probably a good/reliable test
- v3.2: times between 2000 and 2200 milli seconds... averaged ~2125 milli seconds
- v3.3: times between 2350 and 2650 milli seconds... averaged ~2475 milli seconds

This was a much more consistent test, so I guess I can safely say that on this particular scene (see attachment) with these particular settings on this particular PC (high end from 2016)... v3.3 is about 10% slower overall.
I don't know how much of the whole walking animation can be credited to FOV-related stuff. If most of it, then the degradation of 10% is probably acceptable; if only a fraction of it, then the FOV-related stuff might have a much bigger degradation, which would not be desirable... but I don't know how to effectively measure only FOV-related part.

Finally, the test should be done on slower PCs; on several different (complicated) scenes and with several different video settings too I guess.
I however don't have time for it... so I'll try to play real campaign with v3.3 and if I see something slower than usual, I'll make a save and try the same with v3.2 to see if there's any noticeable difference.

[Yankes]

`drawTerrain` is not bottleneck, biggest offender should be `calculateLighting`. I attach save on with I test performance degradation.
Opening and closing doors need recompiling shadows for every layer. Adding lot of fire that is independent light source made it even slower.

[Meridian]

Yeah, I did drawTerrain() test mostly because of night vision... which also seems OK.

I'll try your save later too... and I have a quite nice save from Siberia Mission in PirateZ too (with lots of doors and tons of fire), I'll try that too.

[bladum]

Yankes, another ideas

1) if country is leaving x-com due to pact it may lose ability to research / purchase / manufacture items or disable specific missions
2) item may have option to be fully 2 handed, which means no other item can be even put into another hand, not just some limitation to use items. Therefore you cannot use flare and 2handed heavy weapons at the same time.
3) can we limit items to be put into specific inventory slot ? for example item helmet can be put only into helmet type inventory slot.
4) time to kneel depends on armour type. I cannot imagine no armour cost 4 points and power armour too to kneel.
5) ability to rescue country from under alien pact somehow. If alien pact creates alien base in country, then destroying this base could bring country to x-com again. How exactly this could be done its up to you, either by script or by flag to mission (global effect on geoscape after battle is won).
6) limit max level of stat for soldier based on their initial stats. Now all soldiers have random initial stats (20-40) but common max stat (60). Would be nice to have either max stat level (60) or max stat change (+20) from their initial level.
7) ability to set intelligence for soldiers that would define their own speed of gaining experience on the top of global parameter. This does not have to be shown on the UI but could be also randomized just like any other stat. Some soldier types could have 80-120% but others 200% or 50% of base rate.
define how many slots specific craft takes during interception. At the moment there are max 4 crafts at the same time, would be nice to set this value to N and then define weight for each craft. Some smaller crafts could take 0.5 space when others could take 2 etc...Also max number of crafts could be based on UFO size.

PS: new lightning system works fine for me regarding performance. I haven't noticed any perfo issues.

Regards
Tom

[Solarius Scorch]

1) if country is leaving x-com due to pact it may lose ability to research / purchase / manufacture items or disable specific missions

That's a highly personalized request, but I can imagine it being useful to someone.

2) item may have option to be fully 2 handed, which means no other item can be even put into another hand, not just some limitation to use items. Therefore you cannot use flare and 2handed heavy weapons at the same time.

Nah... What would you have to hold in your hands to prevent you from using one hand to pick up something? A concrete mixer?

3) can we limit items to be put into specific inventory slot ? for example item helmet can be put only into helmet type inventory slot.

Yes, that would be useful in a million ways, but I imagine it would be difficult to code.

4) time to kneel depends on armour type. I cannot imagine no armour cost 4 points and power armour too to kneel.

And also separate TUs per tile, separate aiming times... This is going nowhere. We can limit their TUs by armour already, this translates to kneeling as kneeling always has the same TU cost.

5) ability to rescue country from under alien pact somehow. If alien pact creates alien base in country, then destroying this base could bring country to x-com again. How exactly this could be done its up to you, either by script or by flag to mission (global effect on geoscape after battle is won).

This has been discussed to death over the years and ultimately always rejected, so...

6) limit max level of stat for soldier based on their initial stats. Now all soldiers have random initial stats (20-40) but common max stat (60). Would be nice to have either max stat level (60) or max stat change (+20) from their initial level.

That would lead to sorting your soldiers into categories such as "useless", "disappointing" and "perfect" (the latter encompassing maybe 1% of your people) and sacking most of them on straight away, because they aren't very promising. This would be dull and to be honest also quite unrealistic. Sorry, it's just bad design.

7) ability to set intelligence for soldiers that would define their own speed of gaining experience on the top of global parameter. This does not have to be shown on the UI but could be also randomized just like any other stat. Some soldier types could have 80-120% but others 200% or 50% of base rate.

Why? What's the point?
It's a new complex mechanic, but I have no idea what it is trying to represent, or how to make the game better.

define how many slots specific craft takes during interception. At the moment there are max 4 crafts at the same time, would be nice to set this value to N and then define weight for each craft. Some smaller crafts could take 0.5 space when others could take 2 etc...Also max number of crafts could be based on UFO size.

And you can't send more than 2 big ships because the sky is too small or what?
No, seriously, this is one of the proposed features that make me go "wait, what"?.

PS: new lightning system works fine for me regarding performance. I haven't noticed any perfo issues.

Same here. I love it!

[Yankes]

Solarius Scorch have in 97% same answer as me

Yankes, another ideas

1) if country is leaving x-com due to pact it may lose ability to research / purchase / manufacture items or disable specific missions
[...]
5) ability to rescue country from under alien pact somehow. If alien pact creates alien base in country, then destroying this base could bring country to x-com again. How exactly this could be done its up to you, either by script or by flag to mission (global effect on geoscape after battle is won).

This could be done as part of bigger functionality added is some future. This is similar to overriding game over conditions, as standalone feature is not useful or even bad for game but as part off bigger system I could shine. Image you start only with one country and need conquer/convince other to join you cause.
End game then could be that all countries join XCOM

This would need wait until I finish adding scripts to battlescape, after that I could work on geoscape.

2) item may have option to be fully 2 handed, which means no other item can be even put into another hand, not just some limitation to use items. Therefore you cannot use flare and 2handed heavy weapons at the same time.

Right now you can made that weapon need empty second hand to shoot and I think this is best way to model that behavior. Name one real weapon that need both hands to use but can't be hold in one hand (not shoot!).

3) can we limit items to be put into specific inventory slot ? for example item helmet can be put only into helmet type inventory slot.

At some point I could add something like that.

4) time to kneel depends on armour type. I cannot imagine no armour cost 4 points and power armour too to kneel.
[...]
6) limit max level of stat for soldier based on their initial stats. Now all soldiers have random initial stats (20-40) but common max stat (60). Would be nice to have either max stat level (60) or max stat change (+20) from their initial level.

This more like tweaking that new gameplay mechanic.

7) ability to set intelligence for soldiers that would define their own speed of gaining experience on the top of global parameter. This does not have to be shown on the UI but could be also randomized just like any other stat. Some soldier types could have 80-120% but others 200% or 50% of base rate.

This wound not have good impact on gameplay. Only thing that players will do is to dump all solders that have less than 100%. Without UI it would be even worser because you don't know who to sell.

define how many slots specific craft takes during interception. At the moment there are max 4 crafts at the same time, would be nice to set this value to N and then define weight for each craft. Some smaller crafts could take 0.5 space when others could take 2 etc...Also max number of crafts could be based on UFO size.

This will not work, game only support 4 craft interception windows and changing this is outside of OXCE scope.