OpenXcom Forum
Modding => OpenXcom Extended => OXCE Suggestions DONE => Topic started by: Meridian on August 09, 2016, 10:43:48 am
-
Hi,
made for the alpha chryssalid idea, https://openxcom.org/forum/index.php/topic,4788.0.html (totally not a randomfuck), but maybe useful for others as well.
Maybe alternative invisibility mechanics for Catgirls?
You can now define attribute "activeCamouflage" on enemy armor, which will make them less visible.
Examples:
Positive numbers:
"activeCamouflage: 7" makes the enemy visible from distance of 7 tiles or less.
Negative numbers:
"activeCamouflage: -10" makes the enemy visible from distance, which is 10 tiles less than usual (for given time of day and given attacker's armor)
There is also a mechanic to counter this effect.
You can define an attribute "predatorVision" on friendly armor, which will make camouflaged enemies more visible.
Example:
"activeCamouflage: -5" and "predatorVision: 5" will cancel each other.
Active camouflage cannot decrease the visibility below 1 tile and predator vision cannot increase the visibility beyond normal range (it is only supposed to counter the camouflage effect).
M.
PS: activeCamouflage doesn't work on units under Xcom control (incl. mind-controlled enemies)... I don't want people to cripple AI even more... enemies and neutrals have unimpaired vision.
EDIT: Since 2016-11-05
"activeCamouflage" is replaced by "camouflageAtDay" and "camouflageAtDark"
"predatorVision" is replaced by "antiCamouflageAtDay" and"antiCamouflageAtDark"
the AtDay and AtDark variants are applied together with "visibilityAtDay" and "visibilityAtDark" respectively
-
This is jaw-droppingly awesome.
No, really. There are many excellent additions in OXCE+, but this one is something I just didn't expect to happen in a foreseeable future. This will revolutionize stealth.
You can now define attribute "activeCamouflage" on enemy armor, which will make them less visible.
Examples:
Positive numbers:
"activeCamouflage: 7" makes the enemy visible from distance of 7 tiles or less.
I understand it depends on darkness, yes? So if I put "activeCamouflage: 25", I won't be seeing any further at night?
Also another question: if you fire at a unit you can't see because it's too far (and it's stealthy), can you hit them? Because you can't hit them in the old system.
Negative numbers:
"activeCamouflage: -10" makes the enemy visible from distance, which is 10 tiles less than usual (for given time of day and given attacker's armor)
Cool.
There is also a mechanic to counter this effect.
You can define an attribute "predatorVision" on friendly armor, which will make camouflaged enemies more visible.
Example:
"activeCamouflage: -5" and "predatorVision: 5" will cancel each other.
Active camouflage cannot decrease the visibility below 1 tile and predator vision cannot increase the visibility beyond normal range (it is only supposed to counter the camouflage effect).
Clear and sensible.
PS: activeCamouflage doesn't work on units under Xcom control (incl. mind-controlled enemies)... I don't want people to cripple AI even more... enemies and neutrals have unimpaired vision.
I totally understand, but wouldn't it be enough to leave it to the modder to decide?
-
This is jaw-droppingly awesome.
No, really. There are many excellent additions in OXCE+, but this one is something I just didn't expect to happen in a foreseeable future. This will revolutionize stealth.
Depends on what Yankes implements in OXCE. If he does something better (which he probably will), this feature becomes obsolete.
I understand it depends on darkness, yes? So if I put "activeCamouflage: 25", I won't be seeing any further at night?
At the end, both camouflage and anti-camouflage cannot increase your vision beyond the usual maximum defined by time of the day and armor properties (visibilityAtDay and visibilityAtDark).
The whole algorithm is here: https://github.com/MeridianOXC/OpenXcom/commit/eb72c965cece512ea4acda07bceccf614cca9a6a#diff-a19679ce5a8ec8fcb81157507368cd4eR2816
Should be readable also to non-devs.
Also another question: if you fire at a unit you can't see because it's too far (and it's stealthy), can you hit them? Because you can't hit them in the old system.
Which old system? I am not aware of this.
If you fire and hit them by chance, they will be hit... I love random hits, one of the best features in the game :)
I totally understand, but wouldn't it be enough to leave it to the modder to decide?
No problem to change this, let's wait if anyone starts using it and how...
-
Wow, you actually did it! Amazing man, very much appreciated.
EDIT: Is it possible to include the predator vision property on non-armour items? I had in mind an idea for an advanced Ayephone/auspex (https://warhammer40k.wikia.com/wiki/Auspex) item.
-
Which old system? I am not aware of this.
I meant the system currently used in Piratez, with special loftemps (no central voxel).
No problem to change this, let's wait if anyone starts using it and how...
Oh yeah, I need to test it myself.
-
EDIT: Is it possible to include the predator vision property on non-armour items? I had in mind an idea for an advanced Ayephone/auspex (https://warhammer40k.wikia.com/wiki/Auspex) item.
Yes, Solarius also wanted night vision goggles... but it's not that easy.
Maybe Yankes will add it later.
-
Yes, Solarius also wanted night vision goggles... but it's not that easy.
Maybe Yankes will add it later.
Solarius wanted stat-changing equipment in general... You know, belts of giant strength or shoulder-mounted force shield generators. :)
-
Solarius wanted stat-changing equipment in general... You know, belts of giant strength or shoulder-mounted force shield generators. :)
<cough>, DotA, <cough> ;)
(https://www.vespenegas.com/dota/images/item_bgst.gif)
-
Really cool, this feature was badly needed for some enemies. It shouldn't cripple the game to have scouts with 3 or 4 camouflage and no additional armor, after all you have such advantage in night missions and that does not make them trivial.
This remind me of UFO Aftershock and its excellent detection system (among the not-so-excellent features of this game). In this game you can also detect enemies through walls with sound, psy or heat signature (marked with a question mark until you can see it), depending of the enemy, and a good soldier with noise dampener could crawl towards targets for either snipers or his own shotgun.
-
Yeah, alternate vision modes are another thing. I'm actually in the process of putting together a basic concept for it.
A very good sound system was introduced in UNIMOD, for UFO: Extraterrestrials. While the game as such is pretty shitty for many reasons, the UNIMOD transforms it into a really cool game with lots of exciting features. I can try conceptualize it too.
-
PS: activeCamouflage doesn't work on units under Xcom control (incl. mind-controlled enemies)... I don't want people to cripple AI even more... enemies and neutrals have unimpaired vision.
Shouldn't this work for specialized armours like the Ghost Armour though?
-
Shouldn't this work for specialized armours like the Ghost Armour though?
Probably... I haven't researched ghost armor yet, so no idea what it is supposed to do... as I said, can be changed easily if asked for (and justified).
-
Ghost Armour grants Ethereal style invisibility.
-
Ghost Armour grants Ethereal style invisibility.
* catgirl style invisibility. Only visible on the oblique.
Edit: I stand corrected. It is indeed Ethereal as well as the Catgirl style.
loftempsSet: [ 85 ]
-
Depends on what Yankes implements in OXCE. If he does something better (which he probably will), this feature becomes obsolete.
I will probably build my system on top of yours (or be more accurate it will respect your rulesets). It will take couple of weeks before I will start working on my version and it would be pain in a** to change mods when my version will be released or wait for me to finish it.
Overall my goal for changing visibility it will be exposing calculation of visibility of unit to scripts. You will get all basic data like both units, light, distance and smoke density.
From that you could do any calculations to determine if unit is visible or not. This mean that you can ignore smoke or make smoke more potent. Like wise I plan adding fire density too, it will be ignored by default calculations but mod can use it to recreate heatvison (smoke and light is ignored and fire work like smoke).
-
I will probably build my system on top of yours (or be more accurate it will respect your rulesets). It will take couple of weeks before I will start working on my version and it would be pain in a** to change mods when my version will be released or wait for me to finish it.
Overall my goal for changing visibility it will be exposing calculation of visibility of unit to scripts. You will get all basic data like both units, light, distance and smoke density.
From that you could do any calculations to determine if unit is visible or not. This mean that you can ignore smoke or make smoke more potent. Like wise I plan adding fire density too, it will be ignored by default calculations but mod can use it to recreate heatvison (smoke and light is ignored and fire work like smoke).
A bit of a tangent, but would it be possible to add support for different smoke types ala Apocalypse? Would be especially good if their properties were modular (damage type, damage amount, smoke density, etc); that way you could make a variety of different gasses (poison, acid, stun, etc).
-
A bit of a tangent, but would it be possible to add support for different smoke types ala Apocalypse? Would be especially good if their properties were modular (damage type, damage amount, smoke density, etc); that way you could make a variety of different gasses (poison, acid, stun, etc).
Right now its out the scope, I was thinking about this but it will need lot of work. Is some far future when I finish other things I will do something with that.
-
It would be cool if Xcom could have seperate armor items, allowing you to mix and match helmets (For NVGs, gas masks, ect) That would mean some pretty heavy changes to the engine however.
-
It would be cool if Xcom could have seperate armor items, allowing you to mix and match helmets (For NVGs, gas masks, ect) That would mean some pretty heavy changes to the engine however.
Seconded.
Also a function of an object which limit its functionality to a particular location on the body; for example a helmet only works when worn on the head, not in the backpack.
-
PS: activeCamouflage doesn't work on units under Xcom control (incl. mind-controlled enemies)... I don't want people to cripple AI even more... enemies and neutrals have unimpaired vision.
Should not Thieving Gear and Guerilla Armor also impair the enemies vision by a small amount?
-
Should not Thieving Gear and Guerilla Armor also impair the enemies vision by a small amount?
I have allowed it in today's release. Do your worst :)
-
Woot bollocks visibility hacks begone. Missing voxels is a shitty way to do stealth since it messed with both projectiles and melee in different ways. Also finiky as all hell. No more watching projectiles hit from one way but not 7 others despite passing through the same square. No more catgirls being immune to everything when facing sideways a half tile higher.
-
How does Alien vision work anyway? Is there an article on it? Or is it that simple that if an alien sees one of your soldiers, each alien gets to know that soldier's exact location for the number of turns denoted by their Intelligence stat?
-
How does Alien vision work anyway? Is there an article on it? Or is it that simple that if an alien sees one of your soldiers, each alien gets to know that soldier's exact location for the number of turns denoted by their Intelligence stat?
Yup, thats pretty much it. :)
-
Woot bollocks visibility hacks begone. Missing voxels is a shitty way to do stealth since it messed with both projectiles and melee in different ways. Also finiky as all hell. No more watching projectiles hit from one way but not 7 others despite passing through the same square. No more catgirls being immune to everything when facing sideways a half tile higher.
Well, I'm not quite sure how to manage that, to be honest. I've used the active camo and predator vision to increase variety/reinforce roles of some enemies and armors, yes, but did not change the catgirls and star gods (and ghost armor) yet. While the hack is ugly as hell, this type of camo will simplify any engagement with star gods or catgirls to "smoke a lot, use scouts, kill them from afar". No need to assume a damage-tanking, spread-out formation anymore. No need to use baits. No real need for scanners, as their range is too small to matter.
If the predator vision allowed to see through smoke, the player would be at least forced to use cover.
As for the Ghost armor, it can actually work, but the Ghost Beam needs to be re-thought as it'd allow a Ghost to kill stuff with complete impunity.
-
Well, I'm not quite sure how to manage that, to be honest. I've used the active camo and predator vision to increase variety/reinforce roles of some enemies and armors, yes, but did not change the catgirls and star gods (and ghost armor) yet. While the hack is ugly as hell, this type of camo will simplify any engagement with star gods or catgirls to "smoke a lot, use scouts, kill them from afar".
As opposed to what? Spam the map with explosives? Works pretty well and it's not too far from my standard MO anyways. I go full IDF/Vimy Ridge on these motherfuckers.
Also, you could make the active camo require getting damned close, like 1-3 tiles close and it would be about the same experience as what exists now.
-
Spamming the map with explosives works on everything, so, once you can afford this 'tactic', you will roll over pretty much any enemy, regardless of their stats or invisibility.
-
Spamming the map with explosives works on everything, so, once you can afford this 'tactic', you will roll over pretty much any enemy, regardless of their stats or invisibility.
Yeah but the Star Gods basically mandate it; it's either that or welcome to casualty land, home of the trial and error.
-
Well, I'm open to suggestions how to handle this invisibility un-hacking. At least the basterds will be hittable in melee, which immunity was a major pain. I still think that there should be vision mode that allows some enemies to see through smoke, else it's all too easy. Also, scanners... Detecting invisibles was their main boon. Unless I will make some truly ethereal enemies which are fully unhittable, except by explosives, and need to be first relieved of their ethereal status by a well-placed explosion...
-
Unless I will make some truly ethereal enemies which are fully unhittable, except by explosives, and need to be first relieved of their ethereal status by a well-placed explosion...
Are you referring to the so-called Phased Ones?
[LORE INTENSIFYING]
-
Well, I'm open to suggestions how to handle this invisibility un-hacking. At least the basterds will be hittable in melee, which immunity was a major pain. I still think that there should be vision mode that allows some enemies to see through smoke, else it's all too easy. Also, scanners... Detecting invisibles was their main boon. Unless I will make some truly ethereal enemies which are fully unhittable, except by explosives, and need to be first relieved of their ethereal status by a well-placed explosion...
I'd be cool with a 'psi-o-vision' or whatever which ignores typical LoS obstacles, but depends on both Psi Mastery of the spotter (or Psi Strength if no Skill), and the Psi Strength of those that would be spotted to determine detection range: those stronger with the force can be detected further away; it also adds at least a small upside to using soldiers that have weaker Psi vs Celatids and Star Gods, whereas you'd be straight up pants on head retarded to do so normally in the latter case.
Like I said, you could give Ethereals a detection range of 1 to 3 (this would allow for range extending items/armours) and the gameplay would be about the same except without the ridiculousness of the current hack.
-
I'd be cool with a 'psi-o-vision'
That's pretty much what I wrote on the Solar's Wishlist:
Psionic Sense: Used by certain alien races (some of them only use this vision mode, like Celatids). Has a separate, definable radius (generally much smaller than normal vision). Works through walls and such. Does not pick up mechanical units, or units which are defined not to show up on the psi vision. Does not reveal terrain.
Do you think this is fine?
Like I said, you could give Ethereals a detection range of 1 to 3 (this would allow for range extending items/armours) and the gameplay would be about the same except without the ridiculousness of the current hack.
I wonder if you could give them a detection range of 0.
-
I don't like these idea... as I wrote in Solar's thread already.
Furthermore, FOV calculation is expensive and called very often. Please keep that in mind when designing new crazy ways of detection (like can see through 2 thin walls, 1 thick wall, 1 car, 3 phone booths, but can't see through trees, rocks and hot-blood humanoids).
If you want it SO MUCH, I can probably do two flags:
- canSeeThroughSmoke (i.e. simple heat-vision)
- canSeeThroughEverything (i.e. simple psi-vision, maybe with max distance)
...but anything else is beyond my pain threshold.
-
Yeah, I understand and respect this. My job is to pop ideas, yours is to... uh... keep them reality relevant. :)
What I think is the ore here is to break the uniform sight system a bit. It doesn't really matter how, as long as there is some variation.
Your ideas are good examples and I think they're good enough. One thing I can suggest in addition is differentiating between types of vision when it comes to camouflage, so for example a unit can be visible normally with eyes and only from 5 tiles or less with psi. If we have this, I think we have everything.
-
I don't like these idea... as I wrote in Solar's thread already.
Furthermore, FOV calculation is expensive and called very often. Please keep that in mind when designing new crazy ways of detection (like can see through 2 thin walls, 1 thick wall, 1 car, 3 phone booths, but can't see through trees, rocks and hot-blood humanoids).
If you want it SO MUCH, I can probably do two flags:
- canSeeThroughSmoke (i.e. simple heat-vision)
- canSeeThroughEverything (i.e. simple psi-vision, maybe with max distance)
...but anything else is beyond my pain threshold.
I plan do it after I finish new lighting. Overall I don't plan change how tracking part (that is expensive) work but how final calculation work.
Instead of intruding multiple new properties scripts will handle it. Otherwise would be huge mess, probably 20 would be needed if you would want support most of proposed functionality. Not mentioning mess in code that will need to handle all this cases.
Visibility scripts are superior because from code perspective it only one function call and all complexity will be in rulesets. And this lot less complex because you will not need handle all possible use cases, only what you will use.
Probably grate example is new corpse graphic by ivandogovich and probably he don't use even 10% of capabilities of it (animations, and handling more conditions).
-
Probably grate example is new corpse graphic by ivandogovich and probably he don't use even 10% of capabilities of it (animations, and handling more conditions).
Yeah, but I wouldn't mind doing some animations. ;) ... make some of those Zzs wiggle, etc, I just don't know how. </OffTopic>
-
Yeah, but I wouldn't mind doing some animations. ;) ... make some of those Zzs wiggle, etc, I just don't know how. </OffTopic>
Sleeping Catgirls will be cute.
-
Yeah, but I wouldn't mind doing some animations. ;) ... make some of those Zzs wiggle, etc, I just don't know how. </OffTopic>
If you don't mind copy all corpses 2x then you can use `anim_frame` value in floor item script to toggle between two versions.
Similar to how parrot mod work.
Probably this isn't good solution but is doable. I plan in future to allow drawing multiple surfaces at once. With this you will only need add dead/alive corpse and Zzz +++ will be from separate surface.
-
Might be a good idea to have the camouflage effect work differently for other vision types, like the Guerilla suit lowering normal vision but not psi or heat, anything with active reactors being MORE visible to heat, maybe even through walls if that ends up not being too hard to set up, psi blocking outfits working on psi but not on the others, Mud helping against heat vision. heh, naked and covered in mud would be a funny way to beat some enemies, too bad the Star Gods wouldn't be among those.
If we can get the items that provide benefits, we could even avoid having to create new outfits, or at least not as many.
-
Might be a good idea to have the camouflage effect work differently for other vision types, like the Guerilla suit lowering normal vision but not psi or heat, anything with active reactors being MORE visible to heat, maybe even through walls if that ends up not being too hard to set up, psi blocking outfits working on psi but not on the others, Mud helping against heat vision. heh, naked and covered in mud would be a funny way to beat some enemies, too bad the Star Gods wouldn't be among those.
If we can get the items that provide benefits, we could even avoid having to create new outfits, or at least not as many.
For sure; I definitely think that camo/detection modifiers both pro and con should be specific to vision types if possible.
-
I plan do it after I finish new lighting. Overall I don't plan change how tracking part (that is expensive) work but how final calculation work.
Instead of intruding multiple new properties scripts will handle it. Otherwise would be huge mess, probably 20 would be needed if you would want support most of proposed functionality. Not mentioning mess in code that will need to handle all this cases.
Visibility scripts are superior because from code perspective it only one function call and all complexity will be in rulesets. And this lot less complex because you will not need handle all possible use cases, only what you will use.
Probably grate example is new corpse graphic by ivandogovich and probably he don't use even 10% of capabilities of it (animations, and handling more conditions).
I think I can do the simple heat and psi vision with just 2 armor attributes and less than 20 lines of code in FOV calc function.
I agree that scripts will be superior and we can remove my attributes and replace them with scripts once done. My ramshackle attributes could be used for experimentation and balancing until you are ready with the scripts.
That being said, I'd like to say more about my feelings towards your scripts:
- compared to let's say mapScript or missionScript, your scripts are much more advanced... slowly approaching the status of programming language, not just script
- they give enormous power... but I am afraid that currently you are the only one who can write them
- in my professional life, I have also created (or at least helped create) two such scripting engines for our customers, because their requirements were to be as flexible as possible and change for example some calculations on the fly without having to upgrade our software... at the end, both cases are a disaster... even though there are IT people there, nobody (and I mean nobody!) has learned the scripting language and writing of scripts ended up being our responsibility... the same may happen to you, just saying; also from time to time some individuals give it a try and most likely break it... and then they blame us that our software doesn't work... without telling us that they have changed the scripts of course.
You say that new corpse graphic by Ivan is a great example... but as far as I know, you have actually written the script for Ivan, not Ivan himself. Anyone who can write that script, can also change the source code to do the same functionality, even with less code than in the script (I guess I could do the alt corpses with less than 20 lines of C++ code).
Personally, I am adding new functions only if I am convinced that they will be used by someone... that's why I mostly add stuff requested by Dioxine and Solar... because I know they would use it... and mostly ignore stuff from fantasies of other people (like Surrealistic for example... btw. I am still waiting for that alpha chryssalid mod, if you're reading this). And writing a cool scripting engine, which nobody will be able or willing to use, is a scary thought for me. And I speak from real experience.
I definitely didn't want to discourage you from any of the work you are doing now... just warning you what might happen... be prepared for it. I hope somebody will use it, it will be a huge success and I will be proven wrong.
-
Personally, I am adding new functions only if I am convinced that they will be used by someone... that's why I mostly add stuff requested by Dioxine and Solar... because I know they would use it... and mostly ignore stuff from fantasies of other people (like Surrealistic for example... btw. I am still waiting for that alpha chryssalid mod, if you're reading this).
Having item (not exclusively armour) based counters to the concealment was an important part of the concept. Beyond that Dioxine has found uses for the mechanic, so regardless of whether or not I specifically make the Chryssalid (which Dioxine has said he'll create and add anyways), why come at me bro? I appreciate the work, it's seeing use, and I look forward both to its imminent official implementation into Piratez.
-
Having item (not exclusively armour) based counters to the concealment was an important part of the concept. Beyond that Dioxine has found uses for the mechanic, so regardless of whether or not I specifically make the Chryssalid (which Dioxine has said he'll create and add anyways), why come at me bro? I appreciate the work, it's seeing use, and I look forward both to its imminent official implementation into Piratez.
Just one question: if I implement item (not armor) based counter, will you implement the mod?
And sorry that I used you as example (you just came to mind first, because it was the most recent case). Didn't want to "come at you"... although reading my previous post, I really did :( I should always read my post again before posting.
-
Sure. Keep in mind that I'm totally new to this modding business; where would I go to create such a thing? How would I draft it into the game such that it's in addition to the aliens that exist rather than replacing one, like the existing Chryssalid, wholesale?
And it's fine; it just seemed like there were residual hard feelings from when we clashed before.
-
Sure. Keep in mind that I'm totally new to this modding business; where would I go to create such a thing? How would I draft it into the game such that it's in addition to the aliens that exist rather than replacing one, like the existing Chryssalid, wholesale?
And it's fine; it just seemed like there were residual hard feelings from when we clashed before.
I guess the best would be to study a few existing small mods.
The basic idea is:
- mod adds new stuff or rewrites existing stuff
- base game is loaded first and then all mods in order defined by the user (if mod B is loaded after mod A, it can rewrite A's stuff if they add/modify the same stuff)
Technically:
- put a mod in a separate directory in mods folder (never mod anything by editing base game files!)
- find the definition of chryssalid in base game
- find the definition of its armor
- copy and rename that armor... then add the new attributes
- copy and rename the old chryssalid... then change its armor to new armor
- lastly, add that new chryssalid into some of the alien deployments... so that we can actually meet it in combat
If you want to start with small steps:
- just find the chryssalid, its armor and change that armor (without making a copy)... then balance the stats as you wish
-
- compared to let's say mapScript or missionScript, your scripts are much more advanced... slowly approaching the status of programming language, not just script
Well, to be honest, these scripts seem harder than average programming language :) In part this is due to lack of any thorough documentation whatsoever.
An example of language that allows scripting yet is easy to handle is RPGmaker. If OXCom had such a language...
-
Well, to be honest, these scripts seem harder than average programming language :) In part this is due to lack of any thorough documentation whatsoever.
This.
I don't think it would eliminate the problem that Meridian described, but at least we could try.
And yes, scripting can be ignored in favour of changing the source code, but at least it doesn't involve compilation.
-
And yes, scripting can be ignored in favour of changing the source code, but at least it doesn't involve compilation.
That alone makes it quite a lot more shareable too. Needing people to download source code and compile it means most people won't be able to access your stuff unless you compile it for them: as shown by OXCE and OXCE+. However, "Put this mod in your mod folder" is something that the majority of people can manage. So scripts are really player friendly, but maybe not modder friendly.
It all depends on how Yankes wants to support it now. A big honking readme/man page would be a start, and a collection of all scripts used to date could be something that modders do to share experience (and hopefully Yankes can hang out and help there too).
-
A big honking readme/man page would be a start, and a collection of all scripts used to date could be something that modders do to share experience (and hopefully Yankes can hang out and help there too).
Hmm.. thats a good point.
I have two mods with three scripts published so far (AltCorpse and FlappyParrot), and yup, Yankes basically had to build them for me.
Looking at the scripts I can sort of follow the logic, but as just a modder I don't have the background to know what default values are in the code behind them... so, when I think about how to change or create a script, I can see configurable values, but not necessarily know how they should be configured. The troubleshooting behind getting the corpses to work, made me unsure of whether some of the problems were just in how the scripts were written or if the problems were in the backend of the engine. I know Yankes published a couple bug fix versions I think in that process.... So yeah, right now, I'm going to lean on Yankes for help with those scripts most likely, and even if I dream something up on my own, I'm probably going to run it by Yankes first to see if it passes the sanity check.
That said, its still very early and getting good documentation published may help smart tech guys be able to under stand the scripting language and be able to implement their own scripts. I do see the point behind Meridian's caution however, and that real life experience is nice to have as a background understanding in this.
-
That being said, I'd like to say more about my feelings towards your scripts:
- compared to let's say mapScript or missionScript, your scripts are much more advanced... slowly approaching the status of programming language, not just script
- they give enormous power... but I am afraid that currently you are the only one who can write them
- in my professional life, I have also created (or at least helped create) two such scripting engines for our customers, because their requirements were to be as flexible as possible and change for example some calculations on the fly without having to upgrade our software... at the end, both cases are a disaster... even though there are IT people there, nobody (and I mean nobody!) has learned the scripting language and writing of scripts ended up being our responsibility... the same may happen to you, just saying; also from time to time some individuals give it a try and most likely break it... and then they blame us that our software doesn't work... without telling us that they have changed the scripts of course.
Scripts are programing languages :) And right now I heavy limit that what scripts are capable of and when they can do it. I primary do this to made harder break everything with script misuses.
You say that new corpse graphic by Ivan is a great example... but as far as I know, you have actually written the script for Ivan, not Ivan himself. Anyone who can write that script, can also change the source code to do the same functionality, even with less code than in the script (I guess I could do the alt corpses with less than 20 lines of C++ code).
Yes, I write most of this script for him.
Before 3.0 where was build in version of alt corpse, and I deliberate remove it and replace it by scripts.
Even if only I will write new scripts I would still do it. Is more flexible and allow injecting custom logic even if is harder to use than code.
Personally, I am adding new functions only if I am convinced that they will be used by someone... that's why I mostly add stuff requested by Dioxine and Solar... because I know they would use it... and mostly ignore stuff from fantasies of other people (like Surrealistic for example... btw. I am still waiting for that alpha chryssalid mod, if you're reading this). And writing a cool scripting engine, which nobody will be able or willing to use, is a scary thought for me. And I speak from real experience.
I definitely didn't want to discourage you from any of the work you are doing now... just warning you what might happen... be prepared for it. I hope somebody will use it, it will be a huge success and I will be proven wrong.
Primary reason for scripts is to fulfill people fantasies and keep this crap far from source code :D
Something like multiple vision modes, you dislike it and don't want implements all possible versions, I fully agree. I would dislike too implementing it in source code, but as scripts? Why not? Even if results is broken and hacky from source code perspective it look same as normal functionality.
This.
I don't think it would eliminate the problem that Meridian described, but at least we could try.
And yes, scripting can be ignored in favour of changing the source code, but at least it doesn't involve compilation.
Some basics are in https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/Extended.txt
List of available things is in log file with debug on. This is not close to documentation but probably enough to do some simple things.
Best would be if you say what you would want know now. Because writing full documentation will take some time to do it and I think would be better to focus on things needed right now.
-
Well, I'm open to suggestions how to handle this invisibility un-hacking. At least the basterds will be hittable in melee, which immunity was a major pain. I still think that there should be vision mode that allows some enemies to see through smoke, else it's all too easy. Also, scanners... Detecting invisibles was their main boon. Unless I will make some truly ethereal enemies which are fully unhittable, except by explosives, and need to be first relieved of their ethereal status by a well-placed explosion...
What would be out of balance with a stargod that's visible at 1 tile? Yes you can fire from a distance once it's found but you still need to walk a gal up to it's face tanking reaction fire to do it. At present we walk around with the scanners at 7-9 tiles plotting location then saturation bomb. If anything super short-range visibility would raise casualties in exchange for reliability of killing/capture.
I don't take particularly higher casualties vs stargods compared to anything else unless I am attempting captures. All the hacked visibility does is make me use more expensive ordnance. I do lose more gals that do get shot but that's because of ghost beam power not if I can see what reaction fired or not.
A cat girl with visibility 2-3 would still be a similar threat to its present form. As is they tend to get reactioned down unless the player makes an error. And unless squadsight works on reaction fire defensive fire is actually pretty light if you need to be inside 2-3 squares. Either the gal getting charged defends herself or she dies.
In either case I only see an increase in understanding of mechanics for the player.
And if I understand the implementation correctly one could set visibility to effective 0 for a true invisible unit(barring predator vision) by setting camo to negative max view range.
-
@legion: Exactly. That's essentially what I said.
-
And if I understand the implementation correctly one could set visibility to effective 0 for a true invisible unit(barring predator vision) by setting camo to negative max view range.
Minimum is 1.
https://github.com/MeridianOXC/OpenXcom/blob/oxce3.0-plus-proto/src/Savegame/BattleUnit.cpp#L2810
Would there be a need for true invisible unit?
-
1 is sufficient to my tastes. Unless one is creating a spatialy phased unit but that better stimulated with damage resistance.
-
I've already implemented these changes yesterday. Catgirls and Star Gods are visible from 5 tiles now (more with Assassin or Ghost armor, also hired Mercenaries can spot them better than you). No visibility hacks anymore, unless for fully phased-out units (which do not exist in-game yet).
-
Color me surprised then 5 is much more lenient then what I thought was fair and reasonable.
-
Color me surprised then 5 is much more lenient then what I thought was fair and reasonable.
I haven't met star gods yet, so can't judge on that... but for catgirls my idea would be 3-5 tiles.
Still, 5 is a good starting point, it can be adjusted after some actual game experience if needed.
-
Yeah, hard to say without actual experience. From my point of view, 5 tiles is much harder than LoS hack, except when breaching/fighting in buildings. With spread out formations I was able to snipe most of the Star Gods and Catgirls from a much longer range (there usually was someone situated at the right angle). Can this 5 tiles be abused by using suicide scouts? We'll see from experience.
-
Fired up practice battles for some tests. And 5 is actually decent on one aspect, it keeps things sane in regards to z levels. Not much in naturally occurring terrain that encourages significant high z levels. Explosives are still a very effective choice because arcs limit squad exposure. Ghost beams are still terrifyingly accurate. Getting blasted from your own smokescreen happening rather more often now. Not catching the AI doing the spin shuffle thing makes defense a little more tense. But on the whole it feels like better game play, less adapting to bollocks.
-
What legion said; our predictions were spot on.
-
Fired up practice battles for some tests. And 5 is actually decent on one aspect, it keeps things sane in regards to z levels.
Btw. Z levels are ignored for all such calculations.
-
Would be cool if stealth were shut down or reduced for ignited units (friendlies and enemies).
-
Would be cool if stealth were shut down or reduced for ignited units (friendlies and enemies).
Good point.
"Everybody can see you if you are on fire."
-
Good point.
"Everybody can see you if you are on fire."
Or maybe they just see the fire, not you? :)
-
Or maybe they just see the fire, not you? :)
Yeah, but enough to open fire at you, I guess.
-
Or maybe they just see the fire, not you? :)
"See that giant moving flame hewing roughly to the contours of a man?"
"Yeah."
"Shoot it dead."
-
"Sir, there's a fire blob moving erratically in the distance, should I check it out?"
"No, just let 'em burn."
"You're evil!"
PS: target on fire is always checked against day visibility rules (even during the night). I'll see what I can do about camo.
-
"Sir, there's a fire blob moving erratically in the distance, should I check it out?"
"No, just let 'em burn."
"You're evil!"
Generally the case yes, but Star Gods need to eat lead/plasma/other projectile constituent ASAP.
-
Fire should block thermal vision... but maybe it's just too much work.
Also, being on fire should override (disable) active camo. If it's an AI's invisible unit, the player can see the fire anyway.
-
Fire should block thermal vision... but maybe it's just too much work.
Can be done (easily), but 1 hour after I do it, somebody will mod a "Smoke&Fire Grenade" and we're back at the beginning.
-
Aren't smoke and fire mutually exclusive? But still, yeah, I guess your logic is unassailable.
-
Aren't smoke and fire mutually exclusive? But still, yeah, I guess your logic is unassailable.
In many (maybe all?) cases terrain fire creates smoke as well. Not sure.
In many cases, if there is fire, smoke is ignored, but not everywhere.
-
Smoke grenades appear to snuff out fire (smoke is so dense it suffocates the fire?).
Fire does normally generate smoke in the same tile though.
-
Smoke grenades appear to snuff out fire (smoke is so dense it suffocates the fire?).
Fire does normally generate smoke in the same tile though.
True in general, but don't let the looks fool you (both of your statements don't always apply).
There is a big discrepancy between what is "actually on a tile", "rendered on the map" and "considered during calculations".
Reason: vanilla.
-
"Sir, there's a fire blob moving erratically in the distance, should I check it out?"
"No, just let 'em burn."
"You're evil!"
PS: target on fire is always checked against day visibility rules (even during the night). I'll see what I can do about camo.
An enemy on fire should also lighten the environment, which it is not doing at the moment (see screenshot).
-
Strange, it used to... At least when I was testing 0.99A.1??? Wtf?
-
Its very unlikely with latest Meridian OXCE+ or my OXCE.
-
Since v2016-11-05:
"activeCamouflage" is replaced by "camouflageAtDay" and "camouflageAtDark"
"predatorVision" is replaced by "antiCamouflageAtDay" and"antiCamouflageAtDark"
the AtDay and AtDark variants are applied together with "visibilityAtDay" and "visibilityAtDark" respectively
Please help with testing.
-
Actually I found something I'm not sure if is right.
Here's a screenshot:
(https://openxcom.org/forum/index.php?action=dlattach;topic=4822.0;attach=24677;image)
The enemy below has the following armour flags:
- type: ZSRR_RED_OPS_MALE_ARMOR
camouflageAtDay: 30
camouflageAtDark: -2
visibilityAtDark: 14
Which means that in darkness, he should be visible from 2 tiles less than the enemy's normal vision. (Dioxine told me so. :P ) But he seems to be visible at the edge of the field of vision. What am I missing?
For reference, the X-Com agent on the hill has the following armour flags:
- type: STR_JUMPSUIT_GREEN_UC
camouflageAtDay: 30
camouflageAtDark: -2
visibilityAtDark: 9
Also a save attached, for X-Com Files (Quick Battle).
-
Camo works fine.
The visibility=9 is decreased by camo=-2 to effective visibility of 7 tiles (resp. 7*16=112 voxels).
The distance between the units though is calculated as 96 voxels... which seems wrong (not 100% sure).
I haven't made any changes in this particular part of the engine (calculating lines and distances)... so we may need help of Warboy, Yankes, Stiansel, karadoc or whoever made any changes there and/or understands what is going on there.
EDIT: the distance=96 is actually not a real mathematical distance... it is a number of voxels between the units (in discrete space)... and these voxels can be either 1 or sqrt(2) or sqrt(3) distance units apart from each other (depending if we move straight or diagonally)... the real mathematical distance check was unfortunately removed by Yankes in OXCE 3.3 because of the visibility scripts: https://github.com/Yankes/OpenXcom/commit/eaf67137a2cc4a3a8c598f40bd612d439e29839d#diff-8817a4e728e82fd5808cc76936f5488eR978
-
Alright, thanks for the answer!
I don't think it's a problem.
-
Camo works fine.
The visibility=9 is decreased by camo=-2 to effective visibility of 7 tiles (resp. 7*16=112 voxels).
The distance between the units though is calculated as 96 voxels... which seems wrong (not 100% sure).
I haven't made any changes in this particular part of the engine (calculating lines and distances)... so we may need help of Warboy, Yankes, Stiansel, karadoc or whoever made any changes there and/or understands what is going on there.
EDIT: the distance=96 is actually not a real mathematical distance... it is a number of voxels between the units (in discrete space)... and these voxels can be either 1 or sqrt(2) or sqrt(3) distance units apart from each other (depending if we move straight or diagonally)... the real mathematical distance check was unfortunately removed by Yankes in OXCE 3.3 because of the visibility scripts: https://github.com/Yankes/OpenXcom/commit/eaf67137a2cc4a3a8c598f40bd612d439e29839d#diff-8817a4e728e82fd5808cc76936f5488eR978
One correction, this is not discrete but https://en.wikipedia.org/wiki/Taxicab_geometry :)
I will think about some solution for this.
-
One correction, this is not discrete but https://en.wikipedia.org/wiki/Taxicab_geometry :)
I will think about some solution for this.
Two corrections :)
1/ This is not taxicab geometry. Taxicab geometry has 2D diagonal distance = 2, Euklidian = sqrt(2), but our geometry here has 2D diagonal distance = 1.
The distance on Solar's example screenshot would be:
a/ Taxicab: 12 tiles (6+6)
b/ Euklidian: 8.5 tiles (sqrt(6*6+6*6))
c/ our geometry: 6 tiles (6 * 2D diagonal distance = 6 * 1)
2/ This is indeed discrete... although I wasn't referring to geometry but rather to space itself (which can be described/measured by different geometries)... 1 tile has exactly 16x16x24 voxels and there is nothing between those voxels... thus discrete space. But that's irrelevant to our discussion here anyway, point 1/ is the important one.
PS: I made a small fix/workaround... which may be also a permanent fix... depending on your vision of script's power... the scripts already cannot override the global maximum distance, so maybe they shouldn't be able to override also the "global" maximum distance at dark... but I'll leave that up to you
-
Two corrections :)
1/ This is not taxicab geometry. Taxicab geometry has 2D diagonal distance = 2, Euklidian = sqrt(2), but our geometry here has 2D diagonal distance = 1.
The distance on Solar's example screenshot would be:
a/ Taxicab: 12 tiles (6+6)
b/ Euklidian: 8.5 tiles (sqrt(6*6+6*6))
c/ our geometry: 6 tiles (6 * 2D diagonal distance = 6 * 1)
2/ This is indeed discrete... although I wasn't referring to geometry but rather to space itself (which can be described/measured by different geometries)... 1 tile has exactly 16x16x24 voxels and there is nothing between those voxels... thus discrete space. But that's irrelevant to our discussion here anyway, point 1/ is the important one.
PS: I made a small fix/workaround... which may be also a permanent fix... depending on your vision of script's power... the scripts already cannot override the global maximum distance, so maybe they shouldn't be able to override also the "global" maximum distance at dark... but I'll leave that up to you
If I understand code correctly `calculateLine` with `doVoxelCheck` count steps for "forward" move and for "drift" move ("a" metric).
Tile line count only for "forward" move ("c" metric).
-
I don't see much into that to be honest.
What I think is the core issue, is that the variable "visibleDistanceVoxels" probably doesn't contain a distance at all... it contains "a number of voxels along the line of sight" (a size of the trajectory vector)... which for me is a completely different thing.
The number of voxels could be for example 96 as we see in this example, where as the real distance is 135 or so.
But again, I might be wrong.
There is definitely a bug somewhere tho, instead of seeing in a circle around a soldier, we now see in a square.
-
I don't see much into that to be honest.
What I think is the core issue, is that the variable "visibleDistanceVoxels" probably doesn't contain a distance at all... it contains "a number of voxels along the line of sight" (a size of the trajectory vector)... which for me is a completely different thing.
The number of voxels could be for example 96 as we see in this example, where as the real distance is 135 or so.
But again, I might be wrong.
There is definitely a bug somewhere tho, instead of seeing in a circle around a soldier, we now see in a square.
I agree there is bug that need be fixed, I only disagree on small side detail :) Case "a" or "c" do not change fact that it wrong and it should be something approximal to "b".
-
Maybe instead of using the size of the trajectory vector... you could just take the first and the last voxel from that vector and calculate the distance between those two voxels the good old way?
EDIT: only for real distances of course... the smoke obstruction calculation should still use this funky method to be compatible with vanilla
EDIT2: the more I look at it, the more my workaround actually looks like a proper fix... can't help it
-
Maybe instead of using the size of the trajectory vector... you could just take the first and the last voxel from that vector and calculate the distance between those two voxels the good old way?
EDIT: only for real distances of course... the smoke obstruction calculation should still use this funky method to be compatible with vanilla
EDIT2: the more I look at it, the more my workaround actually looks like a proper fix... can't help it
For way to fix it I think this can be fixed by reducing "weight" of "drift" voxels. This would require replacing call to `calculateLine` by `calculateLineHitHelper`.
This will expose all needed information to handle it properly. Another benefic will be drop of `_trajectory` that cause lot of useless allocations.
I will start working on it when I finish merge with nightly (3/4 done already).
-
Hi.
Sorry, but surely I´m extremely dumb, and I don´t think I´m understanding well all the invisibility, camouflage, and predator vision stuff (neither the thermal part), even after reading the thread.
First, some clarification (Better say, please correct me if this is totally wrong.)
Invisibility is positive values in camoAtX (Where X is day or night)
Camouflage is negative values in camoAtX
antiCamouflageAtDay is the ability to negate camouflage (But not invisibility?)
Let´s have some examples to see if I´m getting this well. (I´m excluding the night-day stuff.)
A.
I have a soldier with the next armor.
vision: 15
And an enemy with this armor.
vision: 20
camo: -3
Then. My soldier could see the enemy in 15-3 = 12 titles. The enemy can see me in 20 titles.
B.
Soldier.
Vision: 12
Camo: -8
Enemy:
Vision: 20
camo: -3
Soldier see enemy in 12-3 = 9 titles
Enemy see soldier in 20 - 8 = 12 titles.
If vision - camo <= 1 them seeStuff is =1
Them, the biggest the negative number (Camo), the better.
C.
Soldier
Vision 20
camo = +8
Enemy:
Vision: 20
camo = +5
Them
Soldier can see enemy at 5 titles
Enemy can see soldier at 8 titles.
D.
Soldier
Vision 20
camo = +8
antiCamo = 20
Enemy:
Vision: 20
camo = +5
antiCamo = 10
Them
Soldier can see enemy at 5 titles
Enemy can see soldier at 8 titles.
The result is the same as the other option? In this case, A lower number is a better one?
Please correct my wrong understanding.
On another relationated aspect. How do you determine visibility in smoke?. How the heatVision works? I´m asking too much question in the incorrect thread?.
Thanks!
-
Invisibility is a fixed distance at which you will seen. Ghost armor as an example is seen at 5 tiles.
Camo reduces the distance at which a unit is seen by subtracting from vision range of enemy. Predator vision counters camo by reducing the camo value by a given amount. Example: Vision - (Camo - Predator)=Final spotting range. Camo cannot be reduced below 0 by predator vision.
Thermal ignores a stated % of smoke thereby reducing smokes impact on vision. Each tile of smoke a unit tries to spot through is stacking penalty to vision range. IF i recall correctly 4 tiles of smoke negates normal vision completely. The more thermal a unit has the more thickness of smoke is needed to reduce vision to zero. Note that smoke only starts subtracting from vision within or past the smoke.
Example: A unit with 40 vision is 15 tiles from the edge of a cloud. The first tile costs 5 extra for an effective distance of 21. The next tile is another 5 for an effective 27. 3rd tile 33. 4th 39. 5th tile 45.
Now i don't actually know what the penalty is i just used 5 for illustration. There is also multiple densities of smoke with different penalties. The 4 tiles i mentioned above for blocking vision is for "full" smoke.
I may be wrong about some of this as i learned some of it a very long time ago.
-
Invisibility is positive values in camoAtX (Where X is day or night)
Camouflage is negative values in camoAtX
antiCamouflageAtDay is the ability to negate camouflage (But not invisibility?)
antiCamo negates also "invisibility".
Exact algorithm here: https://github.com/MeridianOXC/OpenXcom/blob/oxce3.5-plus-proto/src/Savegame/BattleUnit.cpp#L3137
Examples A, B and C are correct.
Example D is not correct.
On another relationated aspect. How do you determine visibility in smoke?. How the heatVision works? I´m asking too much question in the incorrect thread?.
Normal smoke effects are roughly described here: https://www.ufopaedia.org/index.php/Smoke_Grenade#Visual_range
There is no easy answer how far you can see through smoke, the algorithm is relatively complicated and very hard to describe in words!
Heat vision (or thermal vision) affects the normal algorithm by reducing the thickness of the smoke by a given percentage.
So for example if:
- heat vision = 0%, smoke density = 16 everywhere... you can see let's say through 4 tiles of smoke (depending on various factors)
- heat vision = 25%, smoke density = 16 * (1 - 0.25) = 12 everywhere... you can see probably through 6-8 tiles of smoke (depending on various factors)
Sorry for not having an exact answer for you, but smoke calculation algorithm is really not human-friendly.
What you need to remember is:
- "heat vision reduces the thickness of smoke (for the unit with heat vision only)"
- setting heat vision above 60% or so gives you practically full vision in many cases... so don't set it too high... 25-35% is already enough to make a big difference
-
Thanks Meridian and Legionof1. Now I understand.