Wouldn't the bookwork be reduced if the non-personal shields only affected projectiles that detonate within it's range, rather than trying to tie in an interception system?
Correct me if I'm wrong but as I see it it'd be less check calls (impact vs all shields passed though), although it'd reduce the logic's flexibility. QUICK_EDIT
Yes, that would reduce checking shields to once for all technos down from checking all every frame. Yet the system and the code is still the same, just moved to a different place. But this is indeed vastly faster, by a factor of the number of frames the projectile is travelling.
The question is how useful this would be. It wouldn't allow shields to force-detonate projectiles as if the bullet hit a solid shield, because it's already inside. Detonating there would be the same as having no shield, because if you don't catch it, it would detonate there anyhow.
Also, it might (this is a guess) be more difficult to deflect the projectile, because it hit the ground and changing its X or Y directions wouldn't stop it from hitting the ground the very next frame again.
What still would work is absorbing the damage. That is instead of detonating, removing the projectile and dealing damage to the shield, in form of hitpoints or number of hits. It would look like unit X is hit, but unit Y's shield is taking the damage. _________________ QUICK_EDIT
@Alex: That's a whole lot of fancy blabla, but it skirts the issue: What is the goddamn difference between "personal" shields and "mystery" shields?
You have said a lot about potential implementation issues of hypothetical features with cloudy definitions, but you have yet to come out and say how you envision your "personal" shields, what you position as their opposites, and how you define those as opposed to "personal" shields.
Because we're obviously not moving forward on this, and because I have a very strong feeling round three of trying to explain that would not be any more successful than your previous attempts, let's cut this short: The reason I am asking is because all the vague shit I've heard about "personal shields" so far sounds like nothing but a health bar for Iron Curtains.
A graphical representation of the remaining Iron Curtain duration.
And if, in your mind, it truly is a question of "Should I take damage or am I shielded off this very damage?", then I don't see what you're thinking up all your fancy implementation problems up for. There are already two mechanisms in the game to deal with exactly that on/off invulnerability: Iron Curtains and YR shields. You already created ways for weapons to modify the IC duration, so just add an option to have multiple IC types (like armor types), let people define through which IC types any given projectile can pass through, add an IC health bar, and be done with it.
If you're trying to reduce it to Iron Curtain III, just modify the Iron Curtain and be done with it. Don't try redefine the request only to end up reimplementing what's already in the game twice. It's a waste of discussion time, implementation time, modding/management time, runtime resources and a whole lot of other shit.
If you want to have a liberal Iron Curtain, liberate the Iron Curtain. If you want more than an Iron Curtain, stop trying to reduce the request to an Iron Curtain.
As for the implementation details of a hypothetical Star Trek-esque bubble shield:
How do projectiles determine they should crash into Firestorm Walls?
How do projectiles determine they should crash into regular walls?
How do projectiles determine they should crash into cliffs?
How do projectiles determine they should crash into Ares's solid buildings?
How does the Sensors/SensorsSight system manage the "something enters an aura effect" problem?
How does the DetectDisguise system manage the "something enters an aura effect" problem?
How does the CloakGenerator system manage the "something enters an aura effect" problem?
How does the PsychicDetectionRadius system manage the "something enters an aura effect" problem?
And, last but not least: Since terrain has a number of effects on units and their properties, from sinking of units teleported onto water, over destruction of units beamed onto cliffs or rocks, to damage of units on Tiberium or Veins, can't you just off-load the issue to terrain?
There must already be code to deal with aura effects from TechnoTypes for shit like sight, radial indicators, lights, etc., etc.
Mark all cells in the shield radius as shielded, and in whatever check a projectile already does to see if it needs to interact with the terrain in some way, add an if(cell->shielded) { ... } and pretend there's a Firestorm Wall on that cell (or a cliff, or pretend it ran out of fuel, or whatever).
That takes care of the projectile.
Then get into the same loop on the TechnoType side, the one used to check whether Tiberium Damage should apply, or whether the unit should sink because it got chrono'd on water, explode because it got chrono'd on a cliff, etc., add another if(cell->shielded) { ... } and Iron Curtain/Shield the unit.
And then you have it.
The area update/sync is taken care of through the pre-existing loop that takes care of CloakGenerator, LightIntensity or whatever area logic you choose.
The projectile destruction is taken care of through the pre-existing loop that checks whether the projectile is affected by the terrain (e.g. cliffs) and the the pre-existing handling of projectiles impacting with Firestorm Walls, Walls, Cliffs, or Solid Buildings.
The damage protection is taken care of through the pre-existing loop that checks how the unit is affected by the terrain in terms of speed, damage from overlays, autodestruction, etc. and the pre-existing conditional invulnerability functions.
Even the ztyping graphical mid-air shield effect should be possible, since the Firestorm Wall has one.
So yeah. Instead of trying to reinvent Iron Curtains and thinking up needlessly complicated worst case scenarios, can't you just combine a few pre-existing game parts for a goddamn shield?
As for your snark: If you could actually define what you're talking about instead of losing yourself in meaningless phrases like "Personal shields are thus the opposite of intercepting shields"¹, I wouldn't have to resort to magic as an explanation.
¹ "Personal" shields prevent the damage from reaching the unit. They intercept the damage. So they are most certainly not the opposite of intercepting shields. Conversely, if I have a shield that intercepts projectiles, it's still my personal shield, independent of how it works. There's no ztyping opposition there. _________________ #renproj:renegadeprojects.com via Matrix - direct link QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun Nov 23, 2014 7:08 pm Post subject:
Your logic has one problem - the already-existing loop of the Firestorm Wall lags. Like crazy. That's why it got disabled if there's no active firestorm. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
The only differences between a personal and bubble shield are thus:
● The number of units the shield absorbs damage for and
● Graphics
Otherwise a single shielded unit and a unit shielding multiple units are functionally identical, hence my suggestion of only triggering on impact. Only problem is it's not easy to shoe-horn into an interceptor system (projectiles would fly through the radius unaffected) and the graphics might not work like some would expect. QUICK_EDIT
Renegade, I tried my best to explain why I think this is the way to go -- sometimes mixing wordings from the blueprints or bugs, or previous posts. I was sucessful with explaining that; at least for me things got clearer. I don't know about you, though. You heard "vague shit" about that personal shield "crap". I'm not sure whether explaining this a third time will make it any better. I know you know English, better than me, so I guess you are not using Google Translate to translate my posts from English to Tourette. I'll try again, because the questions you ask show thoughts.
Last post I wrote that personal shields are implemented in step D. Thus, personal shields is the set of features that can be implemented there. Without touching any projectile or any other unit, and only affecting the one unit bearing the shield. What features that are exactly doesn't matter to me, as I'm not the one proposing them. I'm proposing to do whatever is possible in step D first, before looking at the more complicated parts.
Intercepting means catching something while it is travelling somewhere. Incoming damage is there already, because the projectile travelled where it wanted to go. Technically, the damage reached the unit, and it is now a matter of deciding how much to apply to the unit and how much to the shield. A bullet proof vest does not make projectiles disappear. It handles the ones that hit it and prevents the application of damage. Even if the bullet does not even reach it, and it's just splinters, rubble or particles causing the damage. What's personal about your shield if it catches projectiles not meant for the unit carrying the shield?
You associate Projectiles with Damage, which is never happening at the same time. A projectile does not damage anything. It's two stages: Projectile travels and then causes damage when detonating. But damage can be caused without projectile. Your model cannot catch this, and you ignore this issue. At least there's no statement from you about this problem. You propose the Iron Curtain, and I'm interpreting this as an implicit answer, which is about the same answer as my personal shields. The damage-preventing effect is implemented at the same place I would have added the personal shields (actually right before). And this part of IC logic would work exactly the same as a personal shield that absorbs all damage and does not alter the shield.
The Iron Curtain works differently, though. It has a duration, not a hitpoints counter. It also affects several other logics, from crushing to targeting. Bending it to be a shield would require lots of more changes, otherwise a unit with a shield would not even be considered a threat by the AI. You could defeat it with a bunch of Jeeps, and it won't even try to defend against them or to retaliate.
How do projectiles determine they should crash into Firestorm Walls?
In Ares (which slows down the game): A path of cells is checked for FSWs. The first encountered will be set as the new target. This is O(n) and caused a slowdown already. This happens during targeting to prevent units stupidly shooting into FSWs directly, as well as every frame, iirc.
In TS: A bullet is flying, travelling to some target. Each frame, it checks whether the cell it is currently on contains a building, and if, whether it's a Firestorm Wall that is enabled. If all this is true, destroy the bullet, spawn an animation. O(1). TS also checks the full path once, when the projectile is fired.
How do projectiles determine they should crash into regular walls?
About the same as the FSW. This is O(1) again, as it only has to check one cell for a single wall segment. It doesn't check all overlay.
How do projectiles determine they should crash into cliffs?
I think this was done during firing. The same function that checks for FSWs then just assigns the cliff as the new target, thus no further checks needed each frame. Cliffs don't move, thus the result can't change.
How do projectiles determine they should crash into Ares's solid buildings?
Same as the FSW in TS, that is a single check each frame for a building, comparing the height.
How does the Sensors/SensorsSight system manage the "something enters an aura effect" problem? How does the DetectDisguise system manage the "something enters an aura effect" problem? How does the CloakGenerator system manage the "something enters an aura effect" problem?
By trading off setup/teardown performance for constant time checks. Each cell contains either bitfields or counters for all houses for each of these logics. If you build a sensor, all cells in range are determined once and then the counters are incremented. Losing the building decrements the counters, but for the bitfields the game has to clear them all and iterate all buildings to re-add the ones that stayed. This sounds awful, but buildings don't move, so this doesn't happen too often, usually once per building built. The question whether a unit is under a cloak gen (which is asked many times per frame for each unit) then becomes O(1). This does not apply if the cloak gen could move. Also, this implementation loses information about the "who". You know there's a sensor, but you don't know who it is. Thus you have to iterate the technos anyhow to find out who will handle the damage (or whose set of tags to use to find out what to do, for that matter).
These systems would need to be recreated. One can't just hook into them, because they only store numbers. There have to be new fields for each cell, that store the shield count/pointer values, otherwise one couldn't distinguish them.
How does the PsychicDetectionRadius system manage the "something enters an aura effect" problem?
This is different from the three above. No bits set. Each house keeps a list of all buildings with PsychicDetectionRadius. I know from the Nuke PsyWarn that it iterates them once for each animation generated, ie. once for each fired nuke. I don't know all the places this is used.
This is how I implemented Academies. Each house has a list of academies it owns. Also can't be reused and requires own vectors. This is how I thought about reducing "iterate all technos" to "iterate all technos that potentially have shields".
Offloading to terrain
That information is all on the cell. A cell's land type, rock overlay, veins to tiberium contents and all that is stored on the cells along with the sensor/cloak data from above. It is responsible for simple O(1) checks.
If shielded objects are moving (and units do), you are just trading fast lookup speed for each individual projectile to slow updating speed for all technos, which happens even if there are no projectiles on the map most of the time.
Also, many places have to be hooked to support this, like SensorSight. If a unit moves, the old cells are decremented, then the new cells are incremented. Not even Westwood found all places, and sometimes sensors stay on after a unit died. Because it's only a number on each cell, it's difficult to find out what went wrong. Not undoable, but nobody did it yet. Well, important point is: many hooks, prone to errors.
Pre-emptive non-argument: Creating a list of all units shielding a cell for each cell wouldn't be a good solution to fix the "who" issue from above, though. It would be 250.000 vectors with pointers that needed to update constantly, and be notified for every techno pointer that's announced as invalid.
------
I consider it way more elegant to have the personal shields on the unit, because that already solves (in a single spot) several problems you are trying to solve by bending different logics to do what they weren't supposed to do.
It is completely independent of intercepting projectiles, and even meaningful without it. A separate, small logic, which should be only a few lines of code. What's the advantage of having it unified? Maintainability? I don't think so. If I can fit personal shields code on one screen, I consider this far superior even if it's recoding stuff that's already there over a mix of different features that aren't related.
What you're effectively saying is turn a Cat into a Car. It's only the change from t to r, the rest is similar. It's totally different, with all the side effects. If shields are considered IC, then AI wouldn't attack them, even though the shield can be damaged sucessfully. It's not the same.
You can see that it would be more difficult by making the Iron Curtain versatile by allowing two modes. You suddenly have to hook all places IC is checked to untangle side-effects again. You suddenly have to support two or more ICs on the same unit at the same time. If you say "I don't want to support that", that would be ok, but you still had to add code everywhere to support even that, so one logic wouldn't overwrite the other, and one would take precedence. And you'd end with an Iron Curtain with duration and a shield logic without but with hitpoints instead. You need fields for both. Like a watch that can be used as a hammer; a combination of things that is almost never useful, though their separate forms are.
My implementation proposal does not solve projectile interception, which is important, but it isolates it completely. Personal shields are agnostic to projectiles. Thus it can still be implemented later, and no implementational detail is set. It's modular. I said it could reuse parts of the personal shield, but it doesn't have to as it isn't mandatory. It could do something similar like the FSW, but it doesn't have to. Same for Sensors, or iterating all technos. It defers the decision without restricting it.
Renegade wrote:
Even the ztyping graphical mid-air shield effect should be possible, since the Firestorm Wall has one.
That's turning things around. The difficult thing is not to create an animation. The difficult thing is to efficiently detect when an animation should be created. You're taking the hard part for granted.
You're saying "needlessly complicated worst case scenario". I didn't propose personal shields because all intercepting implementations I could come up with are ugly -- I could come up with bad implementations all day to create reasons not to code it. I proposed it because personal shields are simple and elegant on their own.
One feature in the game you forgot: Targeting. Auto-targeting does it like shield intercepting projectiles would work in my mind, and I think this is the best approach. Depending on the set of features, it would be O(n²) maybe even O(n³) in the worst case. Yes, I'm concentrating on the worst case scenario here, because players don't get aggravated over non-slowdowns in the best case. My last post was a bit longer, but I shortened it down. It contained a paragraph about the average complexity, which is reduced by the fact the number of projectiles usually is low and the number of interceptable projectile types is limited by the maximum size of a tag in rulesmd.ini.
------
Graion Dilach: Yes, and I consider this a really dirty hack, because the moment you enable your Firestorm, you just get the same problem with all the slowdowns again. The room was a mess, and I just turned out the light to make it go away.
Black Temple Gaurdian: Graphics are independent, too. Drawing a graphic over a shielded unit is most likely trivial, and creating an animation that burns a projectile is easy once it it intercepted.
Also, no: single unit shield is trivial, but shielding other units from damage as well is the nightmare for performance.
4StarGeneral: This is again adding more to reduce complexity. I want less. Not a blob of different features. Just a bunch of small features that work well together. _________________ QUICK_EDIT
Before I answer in full, would you mind clarifying the bit about how the Sensors/SensorsSight and DetectDisguise systems manage the "something enters an aura effect" problem?
Because DetectDisguise is what dogs use to find spies, and Sensors is used on Subs, Squids, Destroyers, etc.
So the explanation This sounds awful, but buildings don't move, so this doesn't happen too often, usually once per building built doesn't quite apply.
It uses the same logic, essentially, just with a small difference:
Cloak Gens use a single DWORD, each bit corresponding to a house. Sensors and DisguiseSensors use arrays of int as counters, each element corresponding to a house.
The int counters are incremented for all cells in range when a unit is added to a map, decremented when it is removed. If a unit moves, it is removed from the old position, updates its position, then is added back to the new position. If you need to know whether a unit is under a Cloak Gen or in Sensors range, either the bit or the int is checked for whether it's set or greater than 1 respectively. I'm not sure why there is a difference. Maybe WW updated/added the latter but not the Cloak Gens because YR doesn't have those. Or maybe it was just different coders at different times.
DetectDisguiseRange only works on buildings. SensorArrays on buildings and SensorsSight on units use the same counters, that is ints and not bits per house, thus when updating, only the affected cells' counters need to be touched by using two nested loops from -range to +range each as x and y coordinates. All of this is only done for units having such a range set. This isn't done in all cases, though: JumpJets, BalloonHovers and Aircraft don't update any of them, iirc.
If you just had a copy of any of those two logics, you would know quickly whether there is a shield. Though, not that quickly, because you now have to decide what to do: A single counter that says "This cell has any shield on it" or one int per house, in which case you have to iterate all houses, because any enemy's shield would affect a bullet. The game doesn't have this problem as only a single player's house is checked.
In any case, you only have information about the "whether or not", as this is enough to decide all of the questions for the game logics. For shields, other settings also matter (only if a shield is/mght be hit). What to do with the projectile, who to damage, .... You are right that this reduces the checking problem to the times a projectile is actually in any shield range.
I still don't consider it comparable, for the following reasons (let's assume it makes checking O(1) indeed): Most of the time there aren't any projectiles on the map, but updating the counters would still happen. This would just move the O(n) to some other spot. Also, only projectiles need to know about shields, and they only need this information in one place - detect, act. Sensors and friends are used in a variety of places, among them are functions called with high frequency, like announcing pointers that became invalid, auto-targeting for each object for each eligible target, updating unit cloak, getting the fire error for a unit (i.e. for what reason can't X fire at Y, also used for targeting, waiting for ammo reload, ...), drawing each object. Sensors are checked dozens, sometimes hundreds of times per frame, even when nothing is happening.
The point I wanted to make is that the personal shields need nothing of that, and that a large chunk of features can be implemented first using some very simple code, which can then be built upon later. The implementation I favor is adding a check for all Technos on bullets, so it only runs when there are projectiles, and trying to make it as efficient as possible.
I really should write shorter answers... _________________ QUICK_EDIT
The point is that it works. Dogs have been detecting spies and naval units have been detecting submarines since the game was released in 2000.
All of this complexity is talk is nice and nerdy and all, but the fact of the matter is: Red Alert 2 required a 266 MHz single-core CPU. And they still had those features.
I'm inclined to believe today's multi-GHz, multi-core CPUs can take it.
Basically, it's like arguing that supermarkets shouldn't sell sliced bread: Adding the sliced requirement, the complexity increases dramatically: You suddenly need a bread knife, personnel or machines to cut the bread, and bags to put the slices into.
With unsliced bread, you just put the loaf on the shelf and you're good to go.
Clearly we should only sell unsliced bread.
Just because something is more complex doesn't mean it's too complex and it doesn't mean the additional complexity isn't worth it.
The question is not how much more complex it is. The question is whether that complexity makes a noticeable difference at runtime. And since the game apparently already does similar updates in a number of cases, it doesn't seem that big of a deal.
As for the problem of needing more information: I'm certain you can fit a pointer to the particular shield instance that is active on that cell in the same space the game would otherwise use for your boolean or bitfield.
If the pointer ain't NULL, dereference it to see what shield you're supposed to interact with.
If you have a back-reference to the Owner on the shield instance or point to the generator instead of the shield, you also solve the House problem, because you can just check which house the shield belongs to. (Multiple shields per cell don't make sense, imo - the shield that was there first should block other shields.)
The statement that only projectiles need to know about shields is also entirely dependent on how you want the shields to interact with the rest of the world. Should hostile units be free to move into the shield? Should aircraft fly over the shield rather than through it? Should Paratroopers be dropable into a shielded zone? Should the Chronosphere be able to teleport units into a shielded zone? Should there be lights, animations, overlays?
--
As for your previous post:
AlexB wrote:
Thus, personal shields is the set of features that can be implemented there. Without touching any projectile or any other unit, and only affecting the one unit bearing the shield. What features that are exactly doesn't matter to me, as I'm not the one proposing them.
Then "personal shields" is deeply flawed terminology, because the phrase means nothing of what it implies. You are using feature names to refer to implementation points. That's like calling the Windows API "railgun system". It makes no sense. You are actually admitting that in the very same paragraph: What features are actually implemented there make no difference to you.
How can that implementation point be "personal shields", if there is no guarantee and no necessity that what gets implemented actually has any shield functionality?
You can't call it "personal shields" and have no requirements that what you're talking about is personal or provides shields.
Implementation points are not features.
AlexB wrote:
Intercepting means catching something while it is travelling somewhere. Incoming damage is there already, because the projectile travelled where it wanted to go. Technically, the damage reached the unit, and it is now a matter of deciding how much to apply to the unit and how much to the shield.
You are working with game logic where none is required. It's not about the game, it's about basic English terminology. The enemy is sending damage, the ally is supposed to receive it, but the shield intercepts it.
Whether the game actually implements it that way or just simulates it doesn't matter.
If a player builds a shield, he builds that shield to protect his unit from damage. He doesn't give jack shit about the engine distinction between "damage" and "projectile". He wants his unit to go unharmed from enemy shots, period.
AlexB wrote:
What's personal about your shield if it catches projectiles not meant for the unit carrying the shield?
Merriam-Webster wrote:
per·son·al adjective \ˈpərs-nəl, ˈpər-sə-nəl\
: belonging or relating to a particular person
: made or designed to be used by one person
...it is personal because it is mine. It is my personal shield. Not yours, not his, not ours, theirs. Mine. It belongs to me. It is my personal property.
AlexB wrote:
You associate Projectiles with Damage, which is never happening at the same time. A projectile does not damage anything. It's two stages: Projectile travels and then causes damage when detonating.
I have implemented stuff like Trenches and KillDriver, which both deal with damage redirection. I am aware of the game's segmented approach, thank you.
You will find that my example approach intercepted the projectile and protected from damage through two different mechanisms.
AlexB wrote:
Your model cannot catch this, and you ignore this issue. At least there's no statement from you about this problem.
Why would there be? For one, it's an implementation detail of a request that hasn't even been greenlit yet, and for two, if you assume the shielding to be a bubble of energy, it is entirely acceptable that damage that didn't attempt to penetrate the shield isn't blocked.
Nevertheless, if one went with the terrain marking method, projectile-less impacts could easily check whether they are exploding on a shielded cell.
AlexB wrote:
You propose the Iron Curtain, and I'm interpreting this as an implicit answer, which is about the same answer as my personal shields. The damage-preventing effect is implemented at the same place I would have added the personal shields (actually right before). And this part of IC logic would work exactly the same as a personal shield that absorbs all damage and does not alter the shield.
For one, Iron Curtain was an example logic within that particular larger example. It was about showing that a combination of pre-existing features with slight modifications could be used to implement the very shields you pretend are all but impossible.
For two, the fact that your proposal and Iron Curtains are almost identical is exactly what I pointed out in a previous post.
All of what you said amounts to Iron Curtain III, which is a waste of your time. If you want something Iron Curtain-esque, make the Iron Curtain more versatile.
AlexB wrote:
The Iron Curtain works differently, though. It has a duration, not a hitpoints counter.
Said the man who implemented weapons that can reduce the Iron Curtain counter.
AlexB wrote:
It also affects several other logics, from crushing to targeting. Bending it to be a shield would require lots of more changes, otherwise a unit with a shield would not even be considered a threat by the AI.
For one, the Iron Curtain is a shield - see Iron Curtain II, the Allied shield. It's just a very boring, very tiny, very Westwood-y implementation of a shield.
For two, what you said is true for any shield implementation, including your own. So it can hardly work for or against any implementation.
AlexB wrote:
If shielded objects are moving (and units do), you are just trading fast lookup speed for each individual projectile to slow updating speed for all technos, which happens even if there are no projectiles on the map most of the time.
For one, see the top of the post: Dogs and ships do it, so I do think "slow" is relative here.
Secondly, again, it depends entirely on your requirements to shield: If hostile units cannot drive through shields, then the shielded areas must be marked even if no projectile is on the map.
Thirdly, I'm not entirely sure your argument even makes sense: If I checked whether the target is shielded, and, if so, re-assigned the projectile target to the edge of the shield, then obviously I could do it without marking shielded cells - but I'd also allow projectiles to happily fly through shielded cells when they're not firing upon shielded units.
By marking the terrain and having the projectile treat shields like cliffs or FSWs, the shields block passing projectiles, no matter who they're aimed at.
AlexB wrote:
I consider it way more elegant to have the personal shields on the unit, because that already solves (in a single spot) several problems you are trying to solve by bending different logics to do what they weren't supposed to do.
No. Your approach doesn't have these problems because it doesn't try to do anything. It just absorbs damage directly on the target unit, exactly like the Iron Curtain has for 14 years.
If I settled for the feature doing nothing, I'd have no problems to solve, either.
AlexB wrote:
[...] If I can fit personal shields code on one screen [...]
Sure you can. All you have to do is
Parse HasIronCurtain=yes on the unit
Programmatically activate Iron Curtain on the unit
Draw Iron Curtain duration as a second health bar below the old one
which is cute, but not much more.
I have already wasted my spare time for tonight, so I'm going to end this here. I am sure you can extrapolate my other answers. No proofreading, either. _________________ #renproj:renegadeprojects.com via Matrix - direct link QUICK_EDIT
As for the problem of needing more information: I'm certain you can fit a pointer to the particular shield instance that is active on that cell in the same space the game would otherwise use for your boolean or bitfield.
Yes, space is not the problem. But then complexity comes back at you.
There can be more than one shield active in a cell. They even might intercept different types, thus adding the wrong shield data pointer would nullify the effect of the other shield. Adding a shield against missiles and then one against fire will make fire come through again. On the neighbour cell, it might be -- for no obvious reason -- the other way around.
Also, how do you then update the shield in a cell? Add a missile shield: Done. Add a fire shield of another unit that moved closer: No way, slot already blocked. First unit dies or moves away: remove the shield from cell. Cell has no shield, but should have fire shield.
Thus, there would have to be a list of shields for each cell, or you would have to have the same mechanic as the cloak gens, which needs to clear and update everything once any shield is removed. If you only allow one shield per cell, you are changing the rules to make your implementation look more appropriate.
Renegade wrote:
The statement that only projectiles need to know about shields is also entirely dependent on how you want the shields to interact with the rest of the world.
None of these questions were ever raised until now.
Renegade wrote:
Then "personal shields" is deeply flawed terminology.
I never said it's a good term (it somehow became a word by using it), but a meta-discussion will not change the facts. Let's call it Bort for that matter, with the same properties as it has now. Bort implements the features mentioned here in this topic that can be implemented at the place I mentioned. Like the natural numbers: You don't need to mention them all to define them; they still got distinct properties.
Renegade wrote:
If a player builds a shield, he builds that shield to protect his unit from damage. He doesn't give jack shit about the engine distinction between "damage" and "projectile". He wants his unit to go unharmed from enemy shots, period.
That period sounds final... I agree to all these premises, but consider your conclusion wrong. Intercepting projectiles doesn't catch all damage, but personal shields do. Your proposed implementation by design just cannot handle damage from a CellSpread=4 warhead to a Shield.Range=2 unit, if no projectile is ever in shield range. Thus damage is dealt despite the shield.
Regarding Merriam-Webster: I think it is clear from my previous posts and the bullet-proof vest metapher that I'm using the "relates to" part for defining personal usage. It only protects the unit bearing the shield, i.e. a "it's mine and only mine" ownership.
Regarding KillDriver and Trenches: Right, but both were implemented using the same definition of personal I use, just in a different spot (before the projectile detonates). Both only work from projectiles, and only for the one unit or structure targeted. They cannot affect any bystanders, and they could only do so by iterating all potential targets either manually or by moving the code into the same spot where my personal shields would go while having the game use ordinary CellSpread rules.
Renegade wrote:
Why would there be? For one, it's an implementation detail of a request that hasn't even been greenlit yet, and for two, if you assume the shielding to be a bubble of energy, it is entirely acceptable that damage that didn't attempt to penetrate the shield isn't blocked.
One: that's not an answer, that's just evading an inconvenient question. Two: the way I understand shields is that they should catch all damage no matter the source and act like regenerating extra health. The second mode I see is the projectile interception, and that should indeed only intercept if the projectile is in range. I'm not sure if I got you right, because you say damage here. For projectiles I would agree.
Renegade wrote:
For one, Iron Curtain was an example logic within that particular larger example. It was about showing that a combination of pre-existing features with slight modifications could be used to implement the very shields you pretend are all but impossible.
For two, the fact that your proposal and Iron Curtains are almost identical is exactly what I pointed out in a previous post.
All of what you said amounts to Iron Curtain III, which is a waste of your time. If you want something Iron Curtain-esque, make the Iron Curtain more versatile.
I know it's an example, but you are mixing the full IC with the part of IC that absorbs the damage. You say slight modifications, I call it different, with similarities. It's only sharing the damage absorbing aspect. All other parts of IC are not needed. Also, when did I say impossible? I said personal shields are bloody trivial.
Renegade wrote:
AlexB wrote:
The Iron Curtain works differently, though. It has a duration, not a hitpoints counter.
Said the man who implemented weapons that can reduce the Iron Curtain counter.
It's not like Damage= is just converted into frames (though that could work). Editing something but keeping the semantics is way easier than changing the way it works fundamentally. If these variables are to be reused, then using IC on a unit would turn off the shield. When IC subsides, the shield would be gone or reset to full again, because previous state would be lost. If regenerating, the IC duration would be prolonged, if there's no code that stops regenerating if true IC is on.
You would be using a timer class to store a hitpoint value, and expect all timer functions to support this. GetTimeLeft() or Pause() wouldn't have much meaning in such a counter. Thus you need to fix up all the places these are called on this special timer. That doesn't sound convenient. Do you consider this a clean solution?
Also, either all locations that call IsIronCurtained() would need to be hooked to ignore shields (otherwise the AI targeting issues arise), or IsIronCurtained() would need to be hooked to return false for shields even though the internal state indicates enabled-ness. In the latter case, you would have to hook into the application of damage, so damage is absorbed anyhow even though IsIronCurtained() returns false for shields, incidentally hooking into the same place I proposed for adding personal shields.
Renegade wrote:
For one, the Iron Curtain is a shield - see Iron Curtain II, the Allied shield. It's just a very boring, very tiny, very Westwood-y implementation of a shield.
For two, what you said is true for any shield implementation, including your own. So it can hardly work for or against any implementation.
That's not the case. If I re-use IC, I get all the IC, with the targeting that already exist (there is special code that ignores units under IC, it doesn't follow directly from having an invulnerability timer counting down). On the other hand, if I add new shields, I don't have those problems if I don't also add code handling this new shield in targeting. Thus, the AI would still try to fire at a shielded unit normally, which is correct behavior.
Renegade wrote:
For one, see the top of the post: Dogs and ships do it, so I do think "slow" is relative here.
Secondly, again, it depends entirely on your requirements to shield: If hostile units cannot drive through shields, then the shielded areas must be marked even if no projectile is on the map.
Thirdly, I'm not entirely sure your argument even makes sense: If I checked whether the target is shielded, and, if so, re-assigned the projectile target to the edge of the shield, then obviously I could do it without marking shielded cells - but I'd also allow projectiles to happily fly through shielded cells when they're not firing upon shielded units.
By marking the terrain and having the projectile treat shields like cliffs or FSWs, the shields block passing projectiles, no matter who they're aimed at.
- Yes, but it's a different thing, if more than one shield per cell is allowed.
- Yeah, most likely then this would have to be done, but that has not been proposed yet. I don't know if that ever would be implemented, with all the pathfinding issues, collisions with enemy units standing while the shield unit approaches them (it can't push the enemy away) and all that. I think a simple implementation now is still better than coding complicated stuff for hypothetical feature requests.
- True, it would.
Renegade wrote:
Your approach doesn't have these problems because it doesn't try to do anything. It just absorbs damage directly on the target unit, exactly like the Iron Curtain has for 14 years.
If I settled for the feature doing nothing, I'd have no problems to solve, either.
A self-regenerating shield absorbing damage, maybe only partially while applying the rest, depending on the set of features finally chosen with customizable Armor, with ROF or cooldown phase. That's not nothing. That's half the solution, and already way more than IC can do.
Renegade wrote:
Sure you can. All you have to do is [...]
That's not my proposal. It's your straw man. And that's not cute.
I mean the features mentioned above. Ignoring code for regenerating and parsing the tags (which would be common to all implementations anyhow), I can add a system parallel to IC in most likely one hook. Without the side effects of IC. _________________ QUICK_EDIT
Yes, space is not the problem. But then complexity comes back at you.
There can be more than one shield active in a cell. [...]
Oh really? Since when?
AlexB wrote:
If you only allow one shield per cell, you are changing the rules to make your implementation look more appropriate.
How is going by the only thing discussed so far "changing the rules"?
If there's anything happening here, it's you raising the goalpost.
AlexB wrote:
None of these questions were ever raised until now.
...said the guy who randomly invents a multiple shields per cell requirement.
I can play that game, too, though.
New Bort requirement: Shields must transfer to parent objects. If a Bort-shielded tank goes into a Tank Bunker, its shield should extend to protect the Tank Bunker as well. Same for Landing Crafts. But not for Carryalls, because the tank wouldn't actually be inside the Carryall.
It should protect the Carryall from shots from below, though, because the projectiles would obviously hit the shield.
AlexB wrote:
I never said it's a good term (it somehow became a word by using it), but a meta-discussion will not change the facts. Let's call it Bort for that matter, with the same properties as it has now. Bort implements the features mentioned here in this topic that can be implemented at the place I mentioned. Like the natural numbers: You don't need to mention them all to define them; they still got distinct properties.
Bort is still flawed terminology, though. You are still equating an implementation point with an implementation.
It's like saying a transport rule is an e-mail, just because a transport rule could, potentially, send an e-mail.
AlexB wrote:
That period sounds final... I agree to all these premises, but consider your conclusion wrong. Intercepting projectiles doesn't catch all damage, but personal shields do. Your proposed implementation by design just cannot handle damage from a CellSpread=4 warhead to a Shield.Range=2 unit, if no projectile is ever in shield range. Thus damage is dealt despite the shield.
The fact that Bort stops damage from reaching the encompassed unit does not automatically mean that the unit is immobile (otherwise all shielded units would be stationary).
It must also be touchable, otherwise personnel could not enter transports, for example.
Therefore, there is no logical reason why a DirectRocker weapon should be blocked by Bort.
...so how does Bort react to one?
Or to a suicide weapon, for that matter?
Or an insta-kill, like getting run over by a train?
Or healing weapons?
AlexB wrote:
Regarding Merriam-Webster: I think it is clear from my previous posts and the bullet-proof vest metapher that I'm using the "relates to" part for defining personal usage. It only protects the unit bearing the shield, i.e. a "it's mine and only mine" ownership.
Yes. That was the ztyping point. You were using a distinction that was equally true for the thing you wanted to distinguish from. Flawed terminology.
AlexB wrote:
Regarding KillDriver and Trenches: Right, but both were implemented using the same definition of personal I use, just in a different spot (before the projectile detonates). Both only work from projectiles, and only for the one unit or structure targeted. They cannot affect any bystanders, and they could only do so by iterating all potential targets either manually or by moving the code into the same spot where my personal shields would go while having the game use ordinary CellSpread rules.
That was not the point at all and is entirely irrelevant to what I said.
AlexB wrote:
One: that's not an answer, that's just evading an inconvenient question.
No, that is a cheap attempt to disregard a perfectly valid answer.
All I have talked about are Star Trek-esque bubble shields. Those form a barrier of energy. There is absolutely no logical reason why damage would magically disappear if it didn't hit that barrier.
AlexB wrote:
Two: the way I understand shields is that they should catch all damage no matter the source and act like regenerating extra health. The second mode I see is the projectile interception, and that should indeed only intercept if the projectile is in range. I'm not sure if I got you right, because you say damage here. For projectiles I would agree.
Yes, I said damage. Because you yourself brought up but damage can be caused without projectile. Direct quote. That was the context, and that was what I was talking about.
What's the point in talking to you if my answers don't register anyway?
AlexB wrote:
I know it's an example, but you are mixing the full IC with the part of IC that absorbs the damage. You say slight modifications, I call it different, with similarities. It's only sharing the damage absorbing aspect. All other parts of IC are not needed.
So a shielded unit reacts differently than an Iron Curtain to attempts of getting crushed? Or chronosphered?
Hell, even the "ignore me as a target" part might be partially relevant, if the unit isn't equipped to damage the shield.
AlexB wrote:
Also, when did I say impossible? I said personal shields are bloody trivial.
I am talking about non-Bort, ffs. I didn't create an example for Iron Curtain III, so that cannot possibly have been my context.
AlexB wrote:
It's not like Damage= is just converted into frames (though that could work). Editing something but keeping the semantics is way easier than changing the way it works fundamentally. If these variables are to be reused, then using IC on a unit would turn off the shield. When IC subsides, the shield would be gone or reset to full again, because previous state would be lost. If regenerating, the IC duration would be prolonged, if there's no code that stops regenerating if true IC is on.
You would be using a timer class to store a hitpoint value, and expect all timer functions to support this. GetTimeLeft() or Pause() wouldn't have much meaning in such a counter. Thus you need to fix up all the places these are called on this special timer. That doesn't sound convenient. Do you consider this a clean solution?
It's inconvenient and unclean because you violently try to come up with the ugliest solution you can find. Doesn't change that all of that comes from you, not me. I am against castrating these requests and putting people off with Iron Curtain III, so I'm not going to waste my time discussing your implementation details.
What I do find unclean is not using existing application logic for an almost-identical use case.
AlexB wrote:
Also, either all locations that call IsIronCurtained() would need to be hooked to ignore shields (otherwise the AI targeting issues arise), or IsIronCurtained() would need to be hooked to return false for shields even though the internal state indicates enabled-ness. In the latter case, you would have to hook into the application of damage, so damage is absorbed anyhow even though IsIronCurtained() returns false for shields, incidentally hooking into the same place I proposed for adding personal shields.
Some weapons can reduce the shield strength.
Beyond these select weapons, how must Bort be treated differently from an Iron Curtain?
AlexB wrote:
That's not the case. If I re-use IC, I get all the IC, with the targeting that already exist (there is special code that ignores units under IC, it doesn't follow directly from having an invulnerability timer counting down). On the other hand, if I add new shields, I don't have those problems if I don't also add code handling this new shield in targeting. Thus, the AI would still try to fire at a shielded unit normally, which is correct behavior.
See above, twice.
AlexB wrote:
- Yes, but it's a different thing, if more than one shield per cell is allowed.
If, yes. If Bort needs the ability to transform into a pigeon on deploy, you also need a different approach.
AlexB wrote:
- Yeah, most likely then this would have to be done, but that has not been proposed yet.
Just like multiple shields per cell. Funny how that works.
AlexB wrote:
A self-regenerating shield absorbing damage, maybe only partially while applying the rest, depending on the set of features finally chosen with customizable Armor, with ROF or cooldown phase. That's not nothing. That's half the solution, and already way more than IC can do.
AlexB wrote:
A separate, small logic, which should be only a few lines of code.
Go ahead. Do all that in a few lines of code.
AlexB wrote:
That's not my proposal. It's your straw man. And that's not cute.
AlexB wrote:
For this very request to work, both systems need to be in place, which is why I consider this more complex to just have personal IC-style shields first.
AlexB wrote:
The absorbing part of a shield with a range is about the same as for IC-style shields.
Evidently.
AlexB wrote:
I mean the features mentioned above. Ignoring code for regenerating and parsing the tags (which would be common to all implementations anyhow), I can add a system parallel to IC in most likely one hook. Without the side effects of IC.
Your constant waffling is almost hilarious.
When we're talking about features, your proposal is not just a cheap Iron Curtain knock-off, because it contains all these extra features, like regeneration. But when we're talking about implementation complexity, we should disregard all the extra features - like regeneration.
What I'm seeing is complexity caused by trying to merge Interception and Shielding. A Shield blocks stuff that enters it's radius, period. No need to differentiate between fire or bullets, both are blocked.
The only time you'd get shields that protect from various things is if the "shield" is just the name given to the logic and it's actually being used as, say, an anti-missile interception system. QUICK_EDIT
The way I see it is there are two types: StarCraft style which is basically a second health bar with regeneration that takes all damage until it is depleted and the interception style. Both would be interesting for different reasons. QUICK_EDIT
I think the issue here is that Renegade simply doesn't like those StarCraft-like shields, and thus interceptor shields have to be implemented, because it already covers what people want (and he's supposed to know what people want better than them).
Even after AlexB already explained it to him several times, both from theoretical and practical point of view, all the differences, performance issues, and how they would interact, he still says the same things as if he didn't read any of that. Last edited by mevitar on Wed Nov 26, 2014 9:47 pm; edited 5 times in total QUICK_EDIT
Joined: 10 Dec 2012 Location: I'm too busy conquering the world!
Posted: Fri Nov 28, 2014 4:23 am Post subject:
kenosis wrote:
This should not be called as a shield but the usage of warhead that affects projectiles, which can deflect/disable/kill projectiles.
You must get special warhead effects working on animations to make such.
AE, I believes requires two units to interact with each other. Correct me if I am wrong. But the shield itself should be independent from other unit that provide buff to the selected unit. _________________ Mod Leader and founder of World Domination
What kenosis is saying is that an effect like shields could be implemented if special warhead effects (like EMP, AttachEffect) could be given from animation warheads, which is currently not possible. There is more at play than I can really see here, but it seems like Gear Zero implemented such a feature. And, AE buffs do not require a second unit. QUICK_EDIT
I'm not following the shields discussion but I'd like to give a +1 to kenosis' projectile manipulation, split the thread if neccessary.
- units which can destroy projectiles around them thanks to a passive ability
- units which can cast projectile-destroying shields on other units
- units which can turn other units into projectile magnets
- units which can become projectile magnets themselves, on deploy or passively
Something from this would be great, already enhances the gameplay a bit. SC2 shields not so much. _________________ mentalomega.com QUICK_EDIT
Also Known As: ZivDero Joined: 23 Jul 2013 Location: Russia
Posted: Fri Nov 28, 2014 5:59 pm Post subject:
Quote:
Monsieur, c'est parfait!
Brilliant! _________________
DarkVen9109 wrote:
What in the name of insanity is this? I FRICKING LOVE THIS LOGICCCC!!!!!!!!!!!!OOOOOOOOHEEAWWWWWWWWWWWYAAAAAAAAAAAAAAAAAWWWWWW PEW PEW PEW PEW BOOM BOOM BOOM!! Nice I love this!!!! Ferriswheel bomb, Dive bomb. New Logic discovered thanks to Kenosis
No. I just wanted to show attached shields are not THAT complex. If it is the unit itself, you don't even need attacheffect, just give secondary weapon firing animation the warhead.
A small animation cannot show how it performs, sorry. I know how to implement something like this, and it's only a few lines of code. It's not like I haven't thought of the logic before posting, it's just very easy to make the game slower if done wrong.
How does it work with invisible projectiles? Is the projectile-destroying function run once per frame, or once the animation damage is applied? Are all projectiles destoyed or only specific types? Can projectiles slip through unaffected, like having a 10% chance of not being destroyed? Is there a slowdown if two armies of shielded units attack each other, or attacking a base with shields on the buildings?
@Renegade: I have written a very, very long post, not yet fully proof-read. Coming up with answers for the questions which I sometimes don't even see the relevancy for the big picture wore me out. I'll see to post it soon, sorry for the delay. _________________ QUICK_EDIT
Then you won't get the "shield" to regenerate until the unit regenerates to full "regular" health, which isn't how it is supposed to work. Apollo already mentioned it earlier (in regards to making "shields" using unit-to-unit transformations): shield should regenerate even if the unit is low on health. If making the unit twice as tough would be the issue here, there would be no request in the first place.
If it is going to be added (again, IF) then it should be made do at least what it was requested to do, or not be added at all.
And if you then add extra tags to control if/how objects regenerate that extra health, then you just implemented Protoss shield anyway, but tied them to the unit's health instead of making it a separate value. In the end, no practical difference, only how the modder defines which is regular health and which is shield. So if it's the same, why not make it simple and just make it an integer value in the first place? QUICK_EDIT
Joined: 19 Aug 2009 Location: Moscow State University
Posted: Fri Nov 28, 2014 11:40 pm Post subject:
some of the "shield" requested here are purly a part of projectile killer warheads.gz can set max number of projectiles to kill and a success rate.
repairing is just a warhead that i forget to delete. dlnt see how that matters, it ruins the purity of shield or what?
anyway. i dont see much potential of this feature thus i will forget about this thread.
Joined: 10 Dec 2012 Location: I'm too busy conquering the world!
Posted: Sat Nov 29, 2014 12:45 am Post subject:
kenosis wrote:
some of the "shield" requested here are purly a part of projectile killer warheads.
anyway. i dont see much potential of this feature thus i will forget about this thread.
But what you demonstrated is that the shield repairs the unit, restoring the unit health back. It definitely shouldn't be how the shield works. The shield have it own value, heck strength=life and the ability to regenerate it own after a duration of no combat. You also demonstrated an AE that suppressed the projectiles, while the unit regain life and not taking any damage. That makes it pretty overpowered.
Quote:
system: kenosis leaved this thread
System: Kenosis has left this thread. Fixed that for ya. _________________ Mod Leader and founder of World Domination
Joined: 19 Aug 2009 Location: Moscow State University
Posted: Sat Nov 29, 2014 9:04 pm Post subject:
Would this put the endless argue to an end?
Draw something would be easier to understand.
Well. I got a little confused reading all your definitions.
There are three models I concluded:
And I see a lot about algorithms?
sorry I aint programmer.
What I did with GZ is the third model. Maybe also what Ren wanted.
3.jpg
Description:
it dares to look for projectiles. well, it doesnt look into warheads. Ignores where it should detonate,which cells would be included in explosion.
If combined with 2, would be complex. What GZ has done.
Filesize:
79.36 KB
Viewed:
4939 Time(s)
2.jpg
Description:
it only consider warhead explosion position and cellspread, is there any cell inside shield affected? Is the warhead type allowed to pass through? if yes, it absorbs it all or part or constant, shield takes some damage
What is overpowered, and what isn't, is for the modders to decide. So if you think something is OP, you can adjust it. That's the point of modding.
kenosis wrote:
i dont see much potential of this feature thus i will forget about this thread.
The thing is, it isn't just one feature that's being discussed here, but multiple ones, and all are being referred to as "shields". That's why AlexB tried to differentiate them in his earlier posts, and he didn't say anything about implementing only one but leaving others out.
kenosis wrote:
Well. I got a little confused reading all your definitions.
There are three models I concluded:
Yes, this is pretty much what is being discussed here.
I myself would like to have all those 3 available, simply because they are all for different uses and purposes. However, whether which, when, and if at all, any of this will be implemented, is not for me to decide. QUICK_EDIT
I haven't join into discussion because it is far too long and self-repeatable all time, but lets say this.
I am with PillBox20 and Atomic_Noodles on this one, personnel shields just as secondary health bars.
Just as kenosis explained in third picture: personnel shield, second health bar, displays some animation if hit, shield amount, armor, regenration rate just like starcraft.
Well, its similar to Scrin shields in C&C3, except Scrin shields cannot regenerate, once destroyed. _________________ PPM Halloween Season 2021 QUICK_EDIT
I think the issue here is that Renegade simply doesn't like those StarCraft-like shields, and thus interceptor shields have to be implemented, because it already covers what people want (and he's supposed to know what people want better than them).
Even after AlexB already explained it to him several times, both from theoretical and practical point of view, all the differences, performance issues, and how they would interact, he still says the same things as if he didn't read any of that.
I like how you (again) didn't read anything I wrote and just made up a fairy tale about my opinions.
Saves me the trouble of having to write a meaningful reply to you.
AlexB wrote:
@Renegade: I have written a very, very long post, not yet fully proof-read. Coming up with answers for the questions which I sometimes don't even see the relevancy for the big picture wore me out. I'll see to post it soon, sorry for the delay.
Partially yes, partially no. To see that I can do a personal shield in a few lines of code, I just did it in a few lines of code. But the point is that it allows for change to not slam a door shut that isn't required to be shut. Which kind of implementation is then later used to find out whether a projectile hit a shield is completely open, and I only got fragments of ideas for it. _________________ QUICK_EDIT
Sorry, Renegade, i did read what you wrote. I even wrote a long reply to everything you wrote, point by point. But why should i bother posting that, if your replies to Alex always revolve around "you're still wrong trying to do it this way, here are dozens of points why, and this is how to do it better", no matter what he writes.
I think this topic served it's purpose very well, and Alex got some things cleared out, also thanks to what you wrote. Perhaps he will get some other things cleared out after he posts his reply, and some other things might get cleared out to you.
But if, despite him explaining to you multiple times, what, and why, is he going to do, and why something isn't viable, you're still trying to push for it being done your way, then is there really anything to add? I don't think so.
PS. I suppose you're trying to say you're not pushing for anything, then? Well, for someone that isn't trying to do it, you wrote an awfully lot in this thread, trying to convince Alex that he is wrong. So much energy put into arguing with and mocking him... QUICK_EDIT
There can be more than one shield active in a cell. [...]
Oh really? Since when?
Renegade wrote:
...said the guy who randomly invents a multiple shields per cell requirement.
I'm speaking about hypothetical shields, yes, but what I say follows from the various requests made here or on LaunchPad. If shields can have large ranges, they can overlap. If infantry can have shields and several infantry units can be on the same cell, it is a direct consequence. I see nothing that even indicates this might not be the case.
If, then I'm raising the goalpost for complex implementations, while lowering the goalpost of upfront design requirements and to allow for new ideas later.
Renegade wrote:
I can play that game, too, though.
New Bort requirement: Shields must transfer to parent objects. If a Bort-shielded tank goes into a Tank Bunker, its shield should extend to protect the Tank Bunker as well. Same for Landing Crafts. But not for Carryalls, because the tank wouldn't actually be inside the Carryall.
It should protect the Carryall from shots from below, though, because the projectiles would obviously hit the shield.
That's not at all complicated (and it does not add complexity as all of this still stays constant time). Actually, it's one if-statement and one assignment for each of these, and a change of just a single line of code to use the shield data of another object. That's the point: Allow for such things. How would you implement that with projectiles and cell ranges, though? Would it be easier?
Granted, Landing Crafts would need a loop, as all passengers need to be checked. I only mention this here, because Bort does not even have to have loops for the most basic features that are already meaningful.
Renegade wrote:
Bort is still flawed terminology, though. You are still equating an implementation point with an implementation.
I'm trying to solve a problem by using a concrete, simple and practical solution that fits like a glove while still being elastic to allow for change. I'm not trying to get a price in literature or philosophy.
Renegade wrote:
Therefore, there is no logical reason why a DirectRocker weapon should be blocked by Bort.
...so how does Bort react to one?
Or to a suicide weapon, for that matter?
Or an insta-kill, like getting run over by a train?
Or healing weapons?
DirectRocker should be blocked, because it's an enemy attack dealing damage. If you consider the shield to be a hull, then this makes no sense that anything taking effect inside would be blocked.
One could resolve this by adding an option, either allowing the warhead to pass like mevitar proposed in his request, or by adding a tag that could distinguish between damage originating from locations farther away than a shield radius and close range attacks inside the shield range (then Bort indeed needs a range, but it still wouldn't deal with projectiles). This is only one or two if-statements more in Bort, in the same place of implementation.
Entering passengers are not dealing damage (also, that's an allied action, not an enemy one, so why block that?). Technically, repair weapons do, but they are treated differently and the Bort shield does not affect them. Suicide weapons of others are by default treated like usual weapon damage, self-suiciding (latin speakers bear with me) can't damage the unit either if DamageSelf=no, but they are removed later along with the shield anyhow.
Trains, Hunter Seeker, C4 and some other logics deal absolute damage, and some of these logics bypass all attempts to protect a unit, which cannot change regardless of any shield implementation, otherwise units of defeated players would be kept alive and the Firestorm wouldn't kill them either. Give up with a unit under IC, and it is destroyed anyhow. It has to be like this.
Renegade wrote:
That was not the point at all and is entirely irrelevant to what I said.
You take the raw damage value from the bullet manually and use the Projectile data to apply the logic, which potentially removes the bullet to disarm it. It has the same shortcomings as non-Bort shields, i.e. this only works for direct hits and has no support for CellSpread, but it is pretty close implementation-wise (one-on-one). Both are nothing like intercepting projectiles (works only on impact), you're not checking bullets destined for others. Changing or removing a projectile is not the problem. It's finding out when to change it.
Renegade wrote:
No, that is a cheap attempt to disregard a perfectly valid answer.
Nice try to turn it around. It was you who suddenly differentiated between green-lit already and not green-lit yet, using it in a discussion to actually green-light it, that is you were providing your own evidence.
I mentioned a possible tag above that could alter behavior for outside or inside of a Bort range. But that is optional behavior and does not reduce the value of a Bort without it.
Renegade wrote:
Yes, I said damage. Because you yourself brought up but damage can be caused without projectile. Direct quote. That was the context, and that was what I was talking about.
Then I got that wrong, sorry. I wasn't thinking of the shield as a hull but as a solid sphere. Hulls would need more treatment, because old and new coords of the projectile now need to be known to check whether the hull was passed, as the hull itself is almost surely not hit directly.
Renegade wrote:
So a shielded unit reacts differently than an Iron Curtain to attempts of getting crushed? Or chronosphered?
Hell, even the "ignore me as a target" part might be partially relevant, if the unit isn't equipped to damage the shield.
That's mixing in completely unrelated features. Shielded units can be crushed, if no feature is added to prevent that (same for any other implementation). Chronoshifting isn't part of this, and even a partially relevant tiny part is better recoded than subscribing to the full set of IC features and then deactivating them again.
Ignoring the target if Armor doesn't fit Verses would be nice to have, but it is again not part of shields. It's an entirely different problem that units can attack others even if they are absolutely unable to hurt it under any circumstances. Temporals have this problem, also Rad Beams have. It can be solved on its own.
Also, actually supporting this only takes hooks in all locations that use the Armor value, like selecting weapons or estimating damage. Not specific to any implementation, and I also don't consider this basic features to start the work -- this can come later.
Renegade wrote:
I am talking about non-Bort, ffs. I didn't create an example for Iron Curtain III, so that cannot possibly have been my context.
I see IC I, IC II and IC III. That's confusing. I never said intercepting is impossible, but implementing an IC which can also protect other units and implementing it at the same place as the original IC would be slow. It was about efficiency: Bort is more efficient.
Renegade wrote:
It's inconvenient and unclean because you violently try to come up with the ugliest solution you can find. Doesn't change that all of that comes from you, not me. I am against castrating these requests and putting people off with Iron Curtain III, so I'm not going to waste my time discussing your implementation details.
What I do find unclean is not using existing application logic for an almost-identical use case.
Am I getting crazy or is it Opposite Day? You were the one who proposed to reuse the IC to make it more versatile. It is only a timer for the duration and a bool for whether it's IC or Force Shield, and you mentioned IC-modifying weapons. What else could that have meant than reusing the IC timer? I was all for having separate handlers with separate variables for shields. Also, I'm not castrating the requests, I'm saying that some can be implemented sooner, some later.
And it's not almost-identical -- only the damage absorbing part is remorely comparable. Shields don't make units flash blue or black as the Force Shield or IC does. Shields don't affect targeting. And they can both be used in parallel. If the essential bits differ, there is no point in forcing equality upon them. A cow is no chair, even if both have four legs. Also, true for the opposite case. At least I wouldn't drink the milk.
Renegade wrote:
Some weapons can reduce the shield strength.
Beyond these select weapons, how must Bort be treated differently from an Iron Curtain?
Bort only affects incoming damage, thus all other features, quirks or special cases of IC would have to be turned off. If you don't want to hijack IC's data, but still use the IC damage handling, this is all of it:
Code:
if(Techno->IsIronCurtained() && allowProtection && !isHealing) {
auto Flags = Techno->ForceShield ? blue : black; // exposition only
FlashbangWarheadAt(2 * Damage, Warhead, Techno->Coords, true, Flags);
Damage = 0;
return DamageState::Unaffected;
}
Damage is a reference parameter, so setting this is required for the caller to see that no damage was dealt.
Adding ROF, Strength, Armor, and friends, then making the Flashbang either customizable or turning it off for non-IC makes this part of code unrecognizable alredy. You would have to set Damage to the actual damage value that was applied to the unit, if the shield doesn't fully absorb it. And even then you also have to change the return value to DamageState::Unchanged, because the unit is affected. If not fully absorbed, you also have to jump back into the game's handler instead of going out.
It's easier to name the stuff that would stay the same: "&& allowProtection && !isHealing".
Renegade wrote:
If, yes. If Bort needs the ability to transform into a pigeon on deploy, you also need a different approach.
Treating basic requirements as optional? For me, it is the fundamental thing that shields just work intuitively and not fail for seemingly random reasons.
Renegade wrote:
Just like multiple shields per cell. Funny how that works.
But as shields aren't even requested on cells but on units, I'm still right. I'm not coding to support all possible futures that at some time could be. I'll support what's at hand, not the plethora of all possible expansions. If I'm wrong, I'll change the implementation later.
Renegade wrote:
Evidently.
I'm not sure what you want to point out here. You tried to give me an inferior proposal as a straw man to run against, and I'm not willing to do that. My hook would go next to the IC handler, but without overwriting it. It would be fast, and it could be the base for any intercepting projectiles because it can be reused.
If you are pointing to "The absorbing part" being the same for ranged and non ranged in the quote, while I also pointed out that they are completely different: That's true. I can clarify this a bit.
The last quote you gave is not regarding the location of a hook. It's about the book keeping of the logic. If you get 50 damage and decrease the shield health, set the ROF timer, play a sound effect and maybe an animation, or whether you get a projectile carrying 90 hitpoints damage and then do the same does not make a difference. The book keeping code is the same. Even if you count the number of individual hits and not the hitpoints: there only has to be one function implementing this, and Bort and interceptors can both use it.
So, if by any means projectiles can be intercepted, they can call the same function that Bort would call to absorb the damage. If Bort is implemented, this code could be called by the projectile interceptors. If interceptors were to be implemented first, they also need to have this code in the background (which is the main piece for shield logic). Bort could then be implemented using about 5 lines of code, without any more tags or variables needed. Thus I came to the conclusion that Bort is the subset of interceptors, because Bort is (except for 5 lines of code) implemented by interceptors.
My goal is: Catch all damage. Thus, if damage cannot be intercepted because there is no projectile, Bort would kick in. It's two logics, sharing a key piece.
Renegade wrote:
When we're talking about features, your proposal is not just a cheap Iron Curtain knock-off, because it contains all these extra features, like regeneration. But when we're talking about implementation complexity, we should disregard all the extra features - like regeneration.
Nice try.
I see no point in concentrating on small details like this. Regeneration would be the common to all implementations, so there's no difference for performance or complexity. Also, regeneration code has to be in a different spot. It's a matter of doing
If you want to question its complexity further, or if you want to claim that this matters for Bort but not for Interceptors even though it would be the same code there, go on.
---
Further answers will be shorter, and I'll ignore discussions about semantic of words, problems that are either common to all implementations or irrelevant for the big picture, as well as meta discussions. _________________ QUICK_EDIT
FYI, DirectRocker/Rocker is not blocked by the default IronCurtain as unit can still tilt to its death unless ARES has changed this at some point...
Speaking of IC, could the damn black light flash when IC'ed units get hit be adjusted somehow?
It frankly lags annoyingly in my experience the more it gets hit as the black light grows larger.
Basing unit shield on IC with that light crap in place would be worst ever or not considering some might want cast IC on top a native shield tank as extra barrier. QUICK_EDIT
I didn't know that about DirectRocker. I don't think Ares ever touched that.
See the code I mentioned in my last post: Damage * 2 is used to create this flash, so it indeed depends on damage. Right now it cannot be adjusted, but that would be a rather simple addition. I could add new tags for IC and FS like the Spotlight DisableXXX tags. And maybe one more to disable the flash alltogether. _________________ QUICK_EDIT
I'm speaking about hypothetical shields, yes, but what I say follows from the various requests made here or on LaunchPad. If shields can have large ranges, they can overlap. If infantry can have shields and several infantry units can be on the same cell, it is a direct consequence. I see nothing that even indicates this might not be the case.
You mean other than the fact that it is perfectly reasonable to deduce from the concept of a protective bubble that keeps enemy shit away from the unit that it should be a protective bubble that keeps enemy shit away from the unit?
Based on what in the request do you argue that enemy shields should be active inside allied ones?
AlexB wrote:
If, then I'm raising the goalpost for complex implementations, while lowering the goalpost of upfront design requirements and to allow for new ideas later.
"lowering the goalpost of upfront design requirements"? What is that even supposed to mean?
If anything, the requirements are the goalpost. And you are doing your best to artificially raise them for any implementation that's not your Iron Curtain III.
AlexB wrote:
That's not at all complicated (and it does not add complexity as all of this still stays constant time). Actually, it's one if-statement and one assignment for each of these, and a change of just a single line of code to use the shield data of another object. That's the point: Allow for such things.
Tall talk. Still, the game stays the same. New requirement: Bort must allow Allied units to combine their shields. i.e. if multiple soldiers act as a squad (AI-programatically or as part of a numbered team or standing on the same cell), their shields should combine and protect each other.
Not all shields, though - there must be an option to have different shield types, so that the plebs don't deplete my precious hero units' shield power.
AlexB wrote:
How would you implement that with projectiles and cell ranges, though? Would it be easier?
No, you're misunderstanding the game. You throw bullshit requirements at me, I throw bullshit requirements at you.
Bort should draw smiley faces when it successfully blocked damage above 150 HP.
AlexB wrote:
Granted, Landing Crafts would need a loop, as all passengers need to be checked. I only mention this here, because Bort does not even have to have loops for the most basic features that are already meaningful.
I am truly curious how the passengers are more complex than the directional protection of the carryall, considering that the carried unit's outline varies depending on the voxel used, and you'd have to parse the SHP's invisible space...but whatever.
AlexB wrote:
I'm trying to solve a problem by using a concrete, simple and practical solution that fits like a glove while still being elastic to allow for change. I'm not trying to get a price in literature or philosophy.
"I don't care that I'm confusing a blueprint with an actual bridge, I just want to help people cross the river."
AlexB wrote:
This is only one or two if-statements more in Bort, in the same place of implementation.
Mmmhmm. Any other implementation is also only one or two if-statements more. The multiplier is the interesting part.
AlexB wrote:
Entering passengers are not dealing damage (also, that's an allied action, not an enemy one, so why block that?).
I'm not sure I even ask that, but the underlying thought is quite reasonable: In order to enter the vehicle, the passenger would have to pass through Bort, so it's interesting to know whether Bort reacts allergic to that or not.
...unless, of course, your shield is a sham and only ever exists under certain circumstances.
...does Bort shield against vehicle thieves?
AlexB wrote:
[...] self-suiciding (latin speakers bear with me) can't damage the unit either if DamageSelf=no, but they are removed later along with the shield anyhow.
So...can a shielded unit kill itself or not?
AlexB wrote:
Trains, Hunter Seeker, C4 and some other logics deal absolute damage, and some of these logics bypass all attempts to protect a unit, which cannot change regardless of any shield implementation, otherwise units of defeated players would be kept alive and the Firestorm wouldn't kill them either. Give up with a unit under IC, and it is destroyed anyhow. It has to be like this.
There is quite a big difference between "the player has ended the world you exist in" and "a train crashed into you".
AlexB wrote:
You take the raw damage value from the bullet manually and use the Projectile data to apply the logic, which potentially removes the bullet to disarm it. It has the same shortcomings as non-Bort shields, i.e. this only works for direct hits and has no support for CellSpread, but it is pretty close implementation-wise (one-on-one). Both are nothing like intercepting projectiles (works only on impact), you're not checking bullets destined for others. Changing or removing a projectile is not the problem. It's finding out when to change it.
Still completely irrelevant to what I said.
AlexB wrote:
Nice try to turn it around. It was you who suddenly differentiated between green-lit already and not green-lit yet, using it in a discussion to actually green-light it, that is you were providing your own evidence.
What would I provide evidence for? The fact that I'm the one actually talking about what was requested, instead of trying to disregard all requests and reimplementing an ersatz-Iron Curtain instead?
The only things I am arguing are
a) Iron Curtain III was not what was requested, and
b) if you must ignore the requests and do it Iron Curtain style, at least re-use existing technologies and liberate the original Iron Curtain instead of building yet another one.
The only reason I provided potential implementation approaches was to counter your blanket claims that everything other than your idea was unendingly complicated and could not possibly be done up front.
It was an example of all the avenues that you refused to even consider, all the questions you refused to discuss, because ALL HAIL IRON CURTAIN III - screw the requests!
I am here to discuss the request that was brought up for discussion. I am doing that. You're the one trying to sneak away by reinterpreting it as yet another Iron Curtain.
As such, my previous point stands: I am not here to provide implementation details for a request that may not even be implemented. I am here to discuss a feature request. One that you have already decided to ignore.
AlexB wrote:
I mentioned a possible tag above that could alter behavior for outside or inside of a Bort range. But that is optional behavior and does not reduce the value of a Bort without it.
Yes. If you ignore the fact that three out of four shield requests explicitly mention range, then range handling is totally optional and we can do Iron Curtains instead.
AlexB wrote:
Then I got that wrong, sorry. I wasn't thinking of the shield as a hull but as a solid sphere. Hulls would need more treatment, because old and new coords of the projectile now need to be known to check whether the hull was passed, as the hull itself is almost surely not hit directly.
wtf is this about hulls now?
AlexB wrote:
That's mixing in completely unrelated features.
Bullshit. These are features that will affect the livelihood and combat effectiveness of my units in the field, and it's damn relevant whether they are actually protected by their shields or not.
Because if I give my soldiers shields to protect them from harm, and the enemy can take them out without wasting a single bullet by running them over with IFVs, then those shields are damn worthless.
And if all my expensive, shielded Apocalypses can potentially be taken away by a Chronosphere, then I damn well need to know that before I park them neatly in a 3x3 formation.
AlexB wrote:
Shielded units can be crushed, if no feature is added to prevent that (same for any other implementation).
No, that's not the same for any other implementation.
Other implementations takes the concept of a shield serious and consider "things that can harm the unit that aren't bullets" part of the scope of the protection they should add.
There is no point to a shield that doesn't shield me.
AlexB wrote:
Chronoshifting isn't part of this, and even a partially relevant tiny part is better recoded than subscribing to the full set of IC features and then deactivating them again.
I'm going to ask yet again: Which parts of the Iron Curtain are not needed?
You keep claiming it's oh so much, but then all you ever do is say "it's better to recode that instead of using the Iron Curtain's".
AlexB wrote:
Ignoring the target if Armor doesn't fit Verses would be nice to have, but it is again not part of shields. It's an entirely different problem that units can attack others even if they are absolutely unable to hurt it under any circumstances. Temporals have this problem, also Rad Beams have. It can be solved on its own.
Yet another attempt to skirt the question.
It's not about armor, it's about shielding.
Can this weapon potentially penetrate the shield or not? If this weapon takes 100000000 shots to collapse the shield, without even damaging the unit inside, but only 3 to kill the unit next to it, is it efficient to attack the shielded unit?
It's not about the question "If the shield were gone, could I possibly hurt the unit?", it's about the question "Does it even make sense to attack the shielded unit?".
As such, it is very much a shield question, and not some Chrono-Desolator problem for later.
AlexB wrote:
Also, actually supporting this only takes hooks in all locations that use the Armor value, like selecting weapons or estimating damage. Not specific to any implementation, and I also don't consider this basic features to start the work -- this can come later.
Let me guess: Just one or two ifs?
Also: The fact that it's not specific to any implementation doesn't change the fact that you left it out, making your implementation artificially look lighter.
AlexB wrote:
I see IC I, IC II and IC III. That's confusing. I never said intercepting is impossible, but implementing an IC which can also protect other units and implementing it at the same place as the original IC would be slow. It was about efficiency: Bort is more efficient.
Bort is not more efficient. Bort takes less code and less calculation because it does less than requested and discussed.
That's like handing a bicycle to a customer who asked for an eco-friendly car.
AlexB wrote:
Am I getting crazy or is it Opposite Day? You were the one who proposed to reuse the IC to make it more versatile.
Yes. Use the already-existing unit-bound, range-less damage-destroyer instead of coding yet another clone of it.
AlexB wrote:
It is only a timer for the duration and a bool for whether it's IC or Force Shield, and you mentioned IC-modifying weapons.
...which already exist. You should know, you created them.
AlexB wrote:
What else could that have meant than reusing the IC timer?
Again with the doublethink shit.
Flip-flop, flip-flop, like a cute little waffle.
Depending on your current needs, the Iron Curtain either has so little features that it's no worth expanding, or it has so many features that it's way too inefficient to use it for such a small use case.
Make up your goddamn mind.
Either it's just a counter, or it's so much more.
It cannot be both.
In any case: I have a hard time believing that everything, no matter what's discussed, is always just one or two ifs for Bort, but setting the Iron Curtain value to the current unit strength at the right point in code is suddenly an impossible task.
AlexB wrote:
I was all for having separate handlers with separate variables for shields. Also, I'm not castrating the requests, I'm saying that some can be implemented sooner, some later.
Sure - it's like you're asked to connect two highways with a bridge, but you build a tunnel instead and say "I focused on the connection part - don't worry, the bridge can always be built later!".
AlexB wrote:
And it's not almost-identical -- only the damage absorbing part is remorely comparable. Shields don't make units flash blue or black as the Force Shield or IC does.
That would be correct, if you were following the original requests, which ask for graphical shield effects at the shield range circle.
Since you're not going to build range, and you're not going to have the Iron Curtain effect indicating a unit is shielded tightly...how is Iron Curtain III going to be visible? Purely through its health bar?
AlexB wrote:
Shields don't affect targeting.
In stock YR, aircraft can't fight each other.
The fancy question ain't the status quo, the fancy question is should it be that way?
The non-castrating approach would be to put the question "should units with shields be treated differently in terms of AI targeting?" up for discussion, potentially coupled with the question of "should there be an option to modify weapon effectiveness against shields or even particular types of shields?".
But hey, cloning the Iron Curtain with no questions asked is so much easier!
AlexB wrote:
And they can both be used in parallel. If the essential bits differ, there is no point in forcing equality upon them. A cow is no chair, even if both have four legs. Also, true for the opposite case. At least I wouldn't drink the milk.
Sure - an energy field surrounding a tank to prevent it from being damaged is as different to an energy field surrounding a tank to prevent it from being damaged as a cow is to a chair.
What drugs are you smoking, and why aren't you sharing?
AlexB wrote:
Bort only affects incoming damage, thus all other features, quirks or special cases of IC would have to be turned off. If you don't want to hijack IC's data, but still use the IC damage handling, this is all of it:
Code:
if(Techno->IsIronCurtained() && allowProtection && !isHealing) {
auto Flags = Techno->ForceShield ? blue : black; // exposition only
FlashbangWarheadAt(2 * Damage, Warhead, Techno->Coords, true, Flags);
Damage = 0;
return DamageState::Unaffected;
}
You are the one who doesn't want all the other Iron Curtain shit.
You have yet to explain how the new energy field that stops the unit from getting damaged is different enough from the old energy field that stops the unit from getting damaged that all the additional handling of the old energy field that stops the unit from getting damaged doesn't apply to the new energy field that stops the unit from getting damaged.
I still say the differences are minuscule.
AlexB wrote:
[...] You would have to set Damage to the actual damage value that was applied to the unit, if the shield doesn't fully absorb it. And even then you also have to change the return value to DamageState::Unchanged, because the unit is affected. If not fully absorbed, you also have to jump back into the game's handler instead of going out.
Is this partially affected stuff part of your "just a few lines" estimate, or is this one of those quantum doublethink cases, where we pretend we didn't read those estimates and believe the feature is just magically going to work?
AlexB wrote:
Treating basic requirements as optional? For me, it is the fundamental thing that shields just work intuitively and not fail for seemingly random reasons.
You mean as intuitively as "if the tank shoots at me, I'm protected, if it runs me over, I die"?
AlexB wrote:
But as shields aren't even requested on cells but on units, I'm still right.
No. You've just castrated your planned implementation enough that it doesn't make a difference anymore.
AlexB wrote:
I'm not coding to support all possible futures that at some time could be. I'll support what's at hand, not the plethora of all possible expansions.
You mean like Range=, which was requested in three out of four requests?
Or getting run over, which is a pretty common occurrence on the YR battlefield?
AlexB wrote:
If I'm wrong, I'll change the implementation later.
Catch phrase of the truly efficient worker - "screw thinking it through, I'll just do it over later".
AlexB wrote:
I'm not sure what you want to point out here. You tried to give me an inferior proposal as a straw man to run against, and I'm not willing to do that. My hook would go next to the IC handler, but without overwriting it. It would be fast, and it could be the base for any intercepting projectiles because it can be reused.
Subtle way to try to twist this in another direction, but the fact remains that you tried to pretend that likening your Bort to an Iron Curtain was some offensive straw man, while you even admit in this very paragraph that Bort would reside right next to it.
AlexB wrote:
If you are pointing to "The absorbing part" being the same for ranged and non ranged in the quote, while I also pointed out that they are completely different: That's true. I can clarify this a bit. [...]
No need. I was talking about your dishonest attempt to paint the similarities between Bort and Iron Curtain as some untrue straw man, when they are, in fact, like brothers.
AlexB wrote:
I see no point in concentrating on small details like this.
Small details like what exactly you're talking about?
Or small details like honesty about the true scope of your plan?
AlexB wrote:
Regeneration would be the common to all implementations, so there's no difference for performance or complexity.
The fact that you would have to do it for all implementations doesn't magically change that you have to do it for Bort as well. So the honest way would be to take it into account when talking about Bort, its size and its complexity.
AlexB wrote:
Also, regeneration code has to be in a different spot. It's a matter of doing
[...]
So basically, you admit full Bort cannot be done in a few lines in one spot, but still go on to pretend that that's perfectly in line with your previous claims that it could be.
AlexB wrote:
If you want to question its complexity further, or if you want to claim that this matters for Bort but not for Interceptors even though it would be the same code there, go on.
I claim that it matters to Bort, and that you tried to obfuscate that to make Bort look better.
AlexB wrote:
Further answers will be shorter, and I'll ignore discussions about semantic of words, problems that are either common to all implementations or irrelevant for the big picture, as well as meta discussions.
So basically, you're going to make up whatever the hell you want, no matter if it violates the dictionary, common sense or the fundamentals of reality itself.
No proofreading. It's three in the morning. If you find spelling mistakes, you can keep them and raise them as your own. _________________ #renproj:renegadeprojects.com via Matrix - direct link QUICK_EDIT
Based on what in the request do you argue that enemy shields should be active inside allied ones?
Shields being active around the owning units is obviously true. Units moving closer to each other can happen. Shields can overlap, and there isn't a single word that this shouldn't be like this.
Renegade wrote:
"lowering the goalpost of upfront design requirements"? What is that even supposed to mean?
If anything, the requirements are the goalpost. And you are doing your best to artificially raise them for any implementation that's not your Iron Curtain III.
It means that I take the naive approach and do not do everything in one go. This does not require lots of thought for every possible feature, because I can separate logics and things then can be changed very easily later on. I don't have to design the entire thing through to start working.
Artificially? I gave detailled explanation about why this is the faster approach in terms of execution speed. If I can do almost half the requested features with one new hook and two old ones, overall not even 100 lines of code, and all this without even the remote chance for lag, I consider this better.
Renegade wrote:
Tall talk. Still, the game stays the same. New requirement: Bort must allow Allied units to combine their shields. i.e. if multiple soldiers act as a squad (AI-programatically or as part of a numbered team or standing on the same cell), their shields should combine and protect each other.
Not all shields, though - there must be an option to have different shield types, so that the plebs don't deplete my precious hero units' shield power.
I'll not think through your irrelevant requests. Can you at least estimate how you would do this differently from me? Does your implementation relieve you from work I would have to do? How would you balance this, if units only have cell-range shields?
Renegade wrote:
I am truly curious how the passengers are more complex than the directional protection of the carryall, considering that the carried unit's outline varies depending on the voxel used, and you'd have to parse the SHP's invisible space...but whatever.
You have to loop all passengers, which is O(n). Carryalls also store the carried unit as passenger, but only as the first. Thus if there is a passenger, you would have the correct one right away. That's O(1). Speed-wise there is no significant difference, as the number of passengers is limited. I just pointed that out because I could do everything else without even having a loop. Not even a single loop.
I'd have to do no fancy size calculations. The carried unit isn't on the battlefield, and it cannot be targeted or damaged; only the Carryall can. And if it is, it would forward the damage directly to the passenger, similar to trenches.
Renegade wrote:
Mmmhmm. Any other implementation is also only one or two if-statements more. The multiplier is the interesting part.
Theoretically it's not, because the number of features to support is hardcoded and thus constant. Practically, even 2 if statements take time, but the significant difference comes in when you have to loop over all units to decide what to do for each single unit.
Renegade wrote:
I'm not sure I even ask that, but the underlying thought is quite reasonable: In order to enter the vehicle, the passenger would have to pass through Bort, so it's interesting to know whether Bort reacts allergic to that or not.
...unless, of course, your shield is a sham and only ever exists under certain circumstances.
...does Bort shield against vehicle thieves?
Agreed, that is useful. Also as a protection against Vehicle Thieves and Terror Drones (which could enter even with Bort and reduce shield from the inside) and the like. Bort cannot support this, and it would need more code to be written.
How would your shield do this? Would you have to write less code to support this? Or would it be the same, maybe because it's the same change that is to be applied and the only thing that differs would be how to infer whether it should be applied?
If you catch projectiles, what do you need to do to prevent enemy units from moving closer? When is a Vehicle Thief a projectile?
Also, if this is about shields not allowing units to pass through them: That was never up for debate. It would be nice to have, just as 2x2 vehicles, but this needs too much work. I did not plan to do something like that.
Renegade wrote:
So...can a shielded unit kill itself or not?
If it has DamageSelf=yes, and it fires a CellSpread weapon close to itself, yes. If it has a suicide weapon, yes. Same as without shields.
Renegade wrote:
There is quite a big difference between "the player has ended the world you exist in" and "a train crashed into you".
Not from the game's perspective. There's only one parameter, which tells the function to ignore protection like IC.
Renegade wrote:
Still completely irrelevant to what I said.
No. You said you know how this works because you implemented this in two ways. I challenge this. What you implemented is closer to Bort than to projectile interception.
Renegade wrote:
What would I provide evidence for? The fact that I'm the one actually talking about what was requested, instead of trying to disregard all requests and reimplementing an ersatz-Iron Curtain instead?
The only things I am arguing are
a) Iron Curtain III was not what was requested, and
b) if you must ignore the requests and do it Iron Curtain style, at least re-use existing technologies and liberate the original Iron Curtain instead of building yet another one.
The only reason I provided potential implementation approaches was to counter your blanket claims that everything other than your idea was unendingly complicated and could not possibly be done up front.
It was an example of all the avenues that you refused to even consider, all the questions you refused to discuss, because ALL HAIL IRON CURTAIN III - screw the requests!
I am here to discuss the request that was brought up for discussion. I am doing that. You're the one trying to sneak away by reinterpreting it as yet another Iron Curtain.
As such, my previous point stands: I am not here to provide implementation details for a request that may not even be implemented. I am here to discuss a feature request. One that you have already decided to ignore.
You are missing a point: I did not say the IC-style Bort shield is the only part to be implemented. It would be the part implemented first, because it is easier and usable on its own. It was never supposed to be the only part to be done, with all the other feature requests being discarded.
You still call it an IC knock-off even though you saw the four lines of code that make up the original IC? A knock-off is either a direct copy or worse, and this certainly isn't. Making those lines of IC customizable is the same as replacing them all (I hope you at least came to the same conclusion about this). So it's a rewrite, and a rewrite is easier if you don't have to support legacy stuff. Thus I still prefer it not expand the IC but to have a new system in parallel.
Renegade wrote:
AlexB wrote:
I mentioned a possible tag above that could alter behavior for outside or inside of a Bort range. But that is optional behavior and does not reduce the value of a Bort without it.
Yes. If you ignore the fact that three out of four shield requests explicitly mention range, then range handling is totally optional and we can do Iron Curtains instead.
Since my very first post here I said that I would like to split implementing this logic, with Range being the partition point. Everything that does not require a range comes first, the rest later. That Range thus is not part of the basic set is neither surprising nor a statement against ranges. You say ignore, implying I don't know or don't want to see; I'm fully aware of these and it was a conscious decision to split.
Renegade wrote:
wtf is this about hulls now?
You were differentiating between damage that originated from farther away from the shield range and damage originating from somewhere in shield range. Bort would protect against them both (which is why I don't need ranges for this).
Renegade wrote:
AlexB wrote:
That's mixing in completely unrelated features.
Bullshit. These are features that will affect the livelihood and combat effectiveness of my units in the field, and it's damn relevant whether they are actually protected by their shields or not.
Because if I give my soldiers shields to protect them from harm, and the enemy can take them out without wasting a single bullet by running them over with IFVs, then those shields are damn worthless.
These all are secondary features, and they are useful. But this has again nothing to do with Bort shields in particular, but with shields in general.
Renegade wrote:
And if all my expensive, shielded Apocalypses can potentially be taken away by a Chronosphere, then I damn well need to know that before I park them neatly in a 3x3 formation.
This again implies only Bort does not protect against this without further changes. It is again common to all shields, no matter how they actually work: The Chronosphere code has to be made aware of shields.
Renegade wrote:
AlexB wrote:
Shielded units can be crushed, if no feature is added to prevent that (same for any other implementation).
No, that's not the same for any other implementation.
Other implementations takes the concept of a shield serious and consider "things that can harm the unit that aren't bullets" part of the scope of the protection they should add.
You detect incoming projectiles and remove them. You do that by remembering the active shield for a cell. Does the pathfinding pick this up automatically? Does it, without any code added, suddenly start to disallow a Battle Fortress to enter a cell?
From my point of view, there always has to be some new code that connects new shield with old logic. If I have a function IsShieldActive() that returns true whenever a unit has an active shield, I would have to call that to see whether X can crush Y. No matter how that method is implemented to find this out. Thus, this is no argument against Bort.
Renegade wrote:
I'm going to ask yet again: Which parts of the Iron Curtain are not needed?
You keep claiming it's oh so much, but then all you ever do is say "it's better to recode that instead of using the Iron Curtain's".
Your proof, your burden to check what's actually needed? I mentioned a few already, like auto-targeting and absorbing the damage. A quick check shows the function that returns whether IC or ForceShield are active is used in 38 places. Ares overrides some, but also adds some more. Among them: Vehicle Thief handling, locomotors, drawing (the tinting, for voxel and shp, more than 12 hooks for this alone), mind control + temporal + crush checks, updating unit positions, bullet detonation, parasites.
What if shielded units should be Chronoshiftable, or stealable? You are replacing one hardcoded set of features with another set of hardcoded features. That's valid, weighting the features differently. But how much work would you need to do to make this optional? Or even change it only a bit: If shielded units should not be chronoshiftable (because of reusing IC), then not even the player owning the units would be able to chronoshift them without code changes. (Same as it is now for IC.)
Renegade wrote:
Yet another attempt to skirt the question.
It's not about armor, it's about shielding.
Can this weapon potentially penetrate the shield or not? If this weapon takes 100000000 shots to collapse the shield, without even damaging the unit inside, but only 3 to kill the unit next to it, is it efficient to attack the shielded unit?
It's not about the question "If the shield were gone, could I possibly hurt the unit?", it's about the question "Does it even make sense to attack the shielded unit?".
As such, it is very much a shield question, and not some Chrono-Desolator problem for later.
What you are asking for for shields is not what the game does now without shields. Desolators keep firing, ignoring other units around them, also Temporals and unwarpable objects. Tanks attack dogs instead of other armored vehicles -- a strategy that worked in no war so far. I'm all for making it smarter, but I'm still against mixing in this stuff in here.
Shields with different Armor is optional, as it is completely independent of basic shields. They might not do what you would like them to do in the basic level, but foundations are no real houses, so no hurry to pick the tapestry. This would be another step.
Renegade wrote:
AlexB wrote:
Also, actually supporting this only takes hooks in all locations that use the Armor value, like selecting weapons or estimating damage. Not specific to any implementation, and I also don't consider this basic features to start the work -- this can come later.
Let me guess: Just one or two ifs?
I would have to call a function on a unit to get its armor if it has no shield and the shield's armor if it has an active shield. So, yes, but I don't know how many new hooks this would take.
Renegade wrote:
Also: The fact that it's not specific to any implementation doesn't change the fact that you left it out, making your implementation artificially look lighter.
Right, I create a basic shield, and leave out these things for later, and by some twist of logic the basic shield then doesn't have the features I left out. My basic implementation is not supposed to "look ligher". It is a proposal for a partial implementation. It is lighter, and it explicitly says it's not complete. It does not say: "I'm efficient and I do everything."
Renegade wrote:
Bort is not more efficient. Bort takes less code and less calculation because it does less than requested and discussed.
No, it's both. It does less than requested, because I opted to split out the slow calculations, and it is as efficient as it can get with the set of features that it can support there. All the other things like Armor can come later, Bort would stay a personal shield.
Renegade wrote:
That's like handing a bicycle to a customer who asked for an eco-friendly car.
The opposite case is creating a super-sonic submarine, while the customer only wants to go either underwater or fast, but not both at the same time.
Renegade wrote:
Yes. Use the already-existing unit-bound, range-less damage-destroyer instead of coding yet another clone of it.
You saw the code. The only thing left would be the check for the two flags I mentioned. Nothing else of it would be left once it is expanded. Nothing. IC absorbs everything, doesn't allow partial damage to get through. It flashes, returns the wrong value.
Renegade wrote:
AlexB wrote:
It is only a timer for the duration and a bool for whether it's IC or Force Shield, and you mentioned IC-modifying weapons.
...which already exist. You should know, you created them.
To support shields and IC, I'd have to either add new fields anyhow, or one would overwrite the other. And then again, the shield could lose energy over time, because the game takes strength as a timer. The shield would need to have code to not regenerate the IC duration, too. It makes no sense, as it is more work to handle that than to write it anew.
Renegade wrote:
AlexB wrote:
What else could that have meant than reusing the IC timer?
Again with the doublethink shit.
Flip-flop, flip-flop, like a cute little waffle.
Depending on your current needs, the Iron Curtain either has so little features that it's no worth expanding, or it has so many features that it's way too inefficient to use it for such a small use case.
Make up your goddamn mind.
Either it's just a counter, or it's so much more.
It cannot be both.
Maybe it can be both, and the double think is consistent. IC manages itself using only a timer and a bool. That's the data. IC is checked in dozens of functions. That's the functions that are used everywhere. The damage absorbing part is contained in the functions, but only a tiny part of it (the four lines).
Renegade wrote:
In any case: I have a hard time believing that everything, no matter what's discussed, is always just one or two ifs for Bort, but setting the Iron Curtain value to the current unit strength at the right point in code is suddenly an impossible task.
It's not impossible, but needlessly complicated to repurpose the IC.
I guess Bort only appears easier because there is some selection bias. All features that just need to know whether a shield is active on a particular unit (to alter damage, to draw an animation, to use another Armor value, to make the Chronosphere ignore a unit, ...) are simple to add once you have a function that tells you whether a shield is active. And if that method is only a simple getter function and the feature at hand is doable in constant time, it's efficient. And these are the features Bort and its future expansions are supposed to solve first, before interception is added.
Renegade wrote:
Sure - it's like you're asked to connect two highways with a bridge, but you build a tunnel instead and say "I focused on the connection part - don't worry, the bridge can always be built later!".
Then you misunderstood what I wrote several times. Bort code can be reused, if needed. It's neither the opposite of all the other features, nor does it stand in their way. It's advantage is that it has a meaning on its own (extra health) and it's simple.
Renegade wrote:
AlexB wrote:
And it's not almost-identical -- only the damage absorbing part is remorely comparable. Shields don't make units flash blue or black as the Force Shield or IC does.
That would be correct, if you were following the original requests, which ask for graphical shield effects at the shield range circle.
Since you're not going to build range, and you're not going to have the Iron Curtain effect indicating a unit is shielded tightly...how is Iron Curtain III going to be visible? Purely through its health bar?
I haven't settled on anything. For testing I changed the health bar, so it's no new one. This doesn't look that nice, because you have to hover over them. Also, the colors are limited to green, yellow, red, and black. I also thought about a pip like the red cross or wrench symbol, but that would be ugly.
I would like to add animations in one of the next steps, like an overlay to the unit, and create another animation whenever the shielded unit is hit about like Firestorm Walls. This is mentioned in one of the requests.
Renegade wrote:
In stock YR, aircraft can't fight each other.
The fancy question ain't the status quo, the fancy question is should it be that way?
For me the question also is about order: What should come first. I'm generally not too keen to touch pathfinding for shields, but Armor and all the others for Bort, as well as intercepting should come not much later than Bort.
Renegade wrote:
The non-castrating approach would be to put the question "should units with shields be treated differently in terms of AI targeting?" up for discussion, potentially coupled with the question of "should there be an option to modify weapon effectiveness against shields or even particular types of shields?".
But hey, cloning the Iron Curtain with no questions asked is so much easier!
Quite the opposite. If Bort was there, then the next steps would be to make this optional. Bort is not final, and I don't think there will be too much discussion. If anybody asks whether shielded units can be made to be ignored when targeting just like IC, this would be a new tag, a new hook and then using a simple function that's there by then already.
Renegade wrote:
Sure - an energy field surrounding a tank to prevent it from being damaged is as different to an energy field surrounding a tank to prevent it from being damaged as a cow is to a chair.
What drugs are you smoking, and why aren't you sharing?
An energy field in O(n) is certainly different from a shield in O(1). No drugs used. I'm just like a chameleon: I can see two different things there.
Renegade wrote:
You are the one who doesn't want all the other Iron Curtain shit.
You have yet to explain how the new energy field that stops the unit from getting damaged is different enough from the old energy field that stops the unit from getting damaged that all the additional handling of the old energy field that stops the unit from getting damaged doesn't apply to the new energy field that stops the unit from getting damaged.
I still say the differences are minuscule.
I explained, many times. I said it's less clear to opt in and to disable unwanted stuff, than not to opt in and enable only the needed stuff. I said why almost all the things need to be changed, without even adding any more features, just to not make the IC an IC. If you cannot even see from four lines of code that it would be all different, I really can't help you. The code was translated faithfully, and it is per se the most objective statement. You should see what it would take to even just add support to only catch some percentage of the damage and let some other percentage pass.
Renegade wrote:
Is this partially affected stuff part of your "just a few lines" estimate, or is this one of those quantum doublethink cases, where we pretend we didn't read those estimates and believe the feature is just magically going to work?
Yes, it is part of it.
Renegade wrote:
You mean as intuitively as "if the tank shoots at me, I'm protected, if it runs me over, I die"?
Yes. This is about shielding off damage with Bort, or intercepting projectiles. And this request is no way near it. It has a place in shields and it is easily doable, but the question was why not intercept projectiles and why to have Bort in the first place.
Renegade wrote:
No. You've just castrated your planned implementation enough that it doesn't make a difference anymore.
Renegade wrote:
You mean like Range=, which was requested in three out of four requests?
Or getting run over, which is a pretty common occurrence on the YR battlefield?
Again, you argue as if the first step (Bort) is the last step (full shields with range).
Renegade wrote:
AlexB wrote:
If I'm wrong, I'll change the implementation later.
Catch phrase of the truly efficient worker - "screw thinking it through, I'll just do it over later".
You are completely disregarding that I'm doing the design work. I'm just designing in a way that it allows for change and to make all separate parts smaller. You're implying that I just do something, without thinking about it, knowing that it's bullshit but doing it anyhow.
Let's say all my assumptions and estimates are completely wrong. Whatever Bort is would then never ever come in touch with any projectile intercepting code that might be coded later. That is: all doors stay open, even for your Sensor-like proposal. Maybe it will just work and I'm wrong. With Bort, nothing in that regard has to be treated as set, though I'm planning that some, in the best case almost all, code can be reused.
Renegade wrote:
Subtle way to try to twist this in another direction, but the fact remains that you tried to pretend that likening your Bort to an Iron Curtain was some offensive straw man, while you even admit in this very paragraph that Bort would reside right next to it.
Proximity does not imply equality, not even equivalence. Otherwise you could eat the plastic packaging of your corn flakes. IC and Bort reside in the same spot, but are different. Next to it are ImmuneToRadiation and Berzerk handling, which are both different in each other, but would you consider them IC-like?
Bort is similar to IC's damage handling, not to the full IC. Similar as in same spot, with comparable purpose. Yet different enough not to reuse the IC code.
Renegade wrote:
No need. I was talking about your dishonest attempt to paint the similarities between Bort and Iron Curtain as some untrue straw man, when they are, in fact, like brothers.
If you don't know where and how often IC-enabledness is checked, how can you come to such a conclusion?
Only few brothers share the same code. For me, they are not similar. There are fewer things to enable manually (using hooks at the logics you want to have) than to enable IC, then disable the code you don't want to have. In other words, you need to undo more than half of the features you opt into.
Renegade wrote:
AlexB wrote:
I see no point in concentrating on small details like this.
Small details like what exactly you're talking about?
Or small details like honesty about the true scope of your plan?
Renegade wrote:
The fact that you would have to do it for all implementations doesn't magically change that you have to do it for Bort as well. So the honest way would be to take it into account when talking about Bort, its size and its complexity.
Details such as reading tags: If there are 10 or 100 doesn't really matter in terms of speed. Code that would be similar for all implementations, so it can neither be an argument for or against some implementation. Code that cannot possibly have a big impact, like checking a timer then adding some value to another.
What is your goal here? One can clearly see that this code example is not doing anything fancy, and it cannot have a performance impact. If you cannot see this, write down how often each line is executed once this hook would fire. Or how much additional memory it needs.
What is the mysterious true scope of my plan? World Domination with three hooks in O(1)?
Renegade wrote:
AlexB wrote:
Also, regeneration code has to be in a different spot. It's a matter of doing
[...]
So basically, you admit full Bort cannot be done in a few lines in one spot, but still go on to pretend that that's perfectly in line with your previous claims that it could be.
The damage handler is a single hook. Init and update are two others, but they are again needed for any kind of shield that regenerates and starts with full shield health. The big chunk of logic where 90% of everything is happening is a single new hook. And this is completely irrelevant to the efficiency of Bort.
Renegade wrote:
AlexB wrote:
If you want to question its complexity further, or if you want to claim that this matters for Bort but not for Interceptors even though it would be the same code there, go on.
I claim that it matters to Bort, and that you tried to obfuscate that to make Bort look better.
You again ignore that I focus on the differences, not on the common parts, when chosing what to do. Comparing equal stuff all day doesn't help make decisions. Regeneration is basically the same for all kinds of shields. And I claim that it will not make a significant difference. Btw:
AlexB, November 26th wrote:
Ignoring code for regenerating and parsing the tags (which would be common to all implementations anyhow), I can add a system parallel to IC in most likely one hook.
Obfuscated in plain English, and I also hid the reason for it in the parentheses. I was wrong about the one hook because I didn't think about the fact that ExtData of non-TypeClasses don't call the initialization functions and I can't access the type data in the constructor, because the type is not available yet as the owner object is still being constructed.
Still, that statement was the best of my knowledge at that point, and the truth was not too far away from it. And why would I make my proposal look better by cheating in regards to something I consider irrelevant?
Renegade wrote:
So basically, you're going to make up whatever the hell you want, no matter if it violates the dictionary, common sense or the fundamentals of reality itself.
That's the negative way to interprete it. The positive way would be that the ad-nauseam arguments will stop. Also, I'm not making things up: I explained in lenghty detail how I would like to proceed and why.
In all these long posts you did not make clear why Bort should not be implemented as I mentioned, even though it is independent of intercepting projectiles. Or (if that is the very reason), why these logics should be combined into one big one, even though that is clearly inefficient. All I'm hearing is that Bort as the first step is so wrong I shouldn't start this way. _________________ QUICK_EDIT
Rest assured, I have plenty to say to that, but given that you imply in at least two places that you've already started implementing, there would be little point to it.
Back in the day, I at least had the decency to openly tell people when I was just gonna do it my way, no matter what they said.
It's not hard, really:
"I don't care that you disagree - I'm the one who's coding it, and I'm gonna do it the way I want to do it, no matter what you or the requester thinks. If you want it done differently, you're free to submit a patch."
At least that way, people know that if you are still talking about a feature, talking about it is worth it, and not just a diversion tactic to keep them occupied. _________________ #renproj:renegadeprojects.com via Matrix - direct link QUICK_EDIT
No, I didn't start to implement anything. I have a proof of concept*, which is basically working, but that is not the same. I have to have an overview to talk about 40+ tags, really. And for that I had to do the research. Without that, I think I would have had a bad time defending my points. Actually, you make it sound like the more I want to know about the issue before I come to a conclusion the weaker my position gets because I obtained an unfair advantage. That is absurd.
I think that Bort really is the most efficient way to catch damage, it's easy to do, it has meaning on its own, and it doesn't stand in the way of anything else even if it was complete and utter bullshit. You have to offer a proposal that is substantially better in these regards. Also note that I concur on so many things, but I value them differently. Protecting against Temporals is possible, but not basic, thus I'd like to move it into the future (which is not necessearily months).
Also, I mentioned that logics can be independent, thus having one does not make the other obsolete. I still don't know how to intercept projectiles.
* I had written a paragraph about it, but shortened it out. It would go at the place that now just says "Yes, it is part of it." _________________ QUICK_EDIT
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
