Troutmonkey, on 09 February 2016 - 03:07 PM, said:
When I was writing the fixed and delayed convergence I realized that these methods both require extra raycast and some more steps. It's possible to add them to this project, but I don't think they will add much compared to the extra overhead they require.
Actually what I was suggesting would be more along the lines of replacing distMeter.distance in the manual convergence function with a non user-input variable range that scales with the Targeting Computer Overload.
Unless I'm completely not understanding how quaternion transformations work, which is also entirely possible. I'm going to stare at this a bit more until comprehension osmoses in.
Actually what I was suggesting would be more along the lines of replacing distMeter.distance in the manual convergence function with a non user-input variable range that scales with the Targeting Computer Overload.
Unless I'm completely not understanding how quaternion transformations work, which is also entirely possible. I'm going to stare at this a bit more until comprehension osmoses in.
It doesn't matter where the distance number comes from. The steps are
1. Shoot a raycast from the centre of the screen, see where it hits.
2. Calculate a ray that converges X distance (doesn't matter how X set)
(2.5: Add CoF)
3. Calculate the new target point by lerping between the perfect ray hit point and the manually converged point
4. Shoot a ray from the weapon to the calculated point, see where it hits.
Now that I think about it step 2 doesn't even require a raycast, just the ray so it would work out to be the same amount of work.
Ghost heat can be removed and lower heat threshold by 1/3rd and add hud flicker to loss of hud near extreme heat threshold and a loss of weapon accuracy when reaching 70%-99% of heat before shutting down, weapons inaccuracy and hud flicker to hud loss will persist until below 70% of heat.
Your idea can be added to the weapon inaccuracy part.
Ghost heat can be removed and lower heat threshold by 1/3rd and add hud flicker to loss of hud near extreme heat threshold and a loss of weapon accuracy when reaching 70%-99% of heat before shutting down, weapons inaccuracy and hud flicker to hud loss will persist until below 70% of heat.
Your idea can be added to the weapon inaccuracy part.
Just spit balling here.
Not bad ideas, but completely different to what I'm suggesting here. This CoF is completely unaffected by heat or movement. It is only effected by the values on the weapons you shoot. It will work with the current heat cap without any change being required. As for HUD effects they are cool, but not a good balancing mechanic as blue tac on the screen trumps all
Edited by Troutmonkey, 09 February 2016 - 06:53 PM.
As said above, Trout did this in a day....so much for huge amount of coding
This shows just how delusional you people are when it comes to this whole convergence argument.
It's a little bit easier to program something when you don't have to code its interaction with dozens of other systems, including netcode and HSR. Would Trout's programming even be compatible with the server-side authentication MWO uses? Will HSR have issues by drastically increasing the amount of variables it has to calculate?
I can model, texture, rig, and animate a 3d character within a day, but that doesn't mean a studio like Pixar can easily incorporate my rig into one of their feature length movies without having to make drastic, time-consuming alterations to the rig. Also, chances are even if they made the rig compatible with their pipeline, there's very likely something drastically wrong with either the geometry and/or texturing that would end up causing rendering issues and/or a substantial difference in quality for the final render.
Long story short, while it's easier to code something on your own to prove a proof of concept, that doesn't mean it's easy to implement in a fully developed game.
Awesome job OP. Like you said, your demo takes COF to the extreme, but it's exactly how I imagined it should be. There could still be plenty of long range trading but the peek-a-boo crap we have now wouldn't be nearly as dominant. People could still have their pinpoint firepower if they managed their fire control. We could finally say goodbye to ghost heat. Awesome stuff.
Troutmonkey, on 09 February 2016 - 06:50 PM, said:
Not bad ideas, but completely different to what I'm suggesting here. This CoF is completely unaffected by heat or movement. It is only effected by the values on the weapons you shoot. It will work with the current heat cap without any change being required. As for HUD effects they are cool, but not a good balancing mechanic as blue tac on the screen trumps all
This will never see the light of day in game, but you guys are free to live out your dreams on the forum. I do appreciate the OP's dedication to this idea, even if his side-kick is a bit obnoxious.
We have lasers IRL that can shoot down missiles kilometers away.
This video doesn't make any sense.
Come of fire with cannon weapons while shooting, sure between recoil and stuff that makes sense. However giving lasers what amounts to recoil literally makes no sense at all. All I'm seeing in your video is a mech malfunctioning that, not something that anyone would put up with in the field.
Rhialto, on 09 February 2016 - 09:57 AM, said:
It makes no sense to have lasers that move or deviate like this...
You are both absolutely clueless when it comes to this. Lasers on a mech would rely on mechanical parts for aiming ... mechanical parts which are not perfect. We don't have anything that can do pinpoint precision like this. Hit a missile, yes - but how big is a missile, and how much wiggle room does that provide for inaccuracy. Please, I work with this type of stuff in the Army for a living, and you're talking without knowing what you're talking about.
Edit: Kudos to OP, awesome video that shows this idea way better than I ever could have done.
This shows just how delusional you people are when it comes to this whole convergence argument.
It's a little bit easier to program something when you don't have to code its interaction with dozens of other systems, including netcode and HSR. Would Trout's programming even be compatible with the server-side authentication MWO uses? Will HSR have issues by drastically increasing the amount of variables it has to calculate?
I can model, texture, rig, and animate a 3d character within a day, but that doesn't mean a studio like Pixar can easily incorporate my rig into one of their feature length movies without having to make drastic, time-consuming alterations to the rig. Also, chances are even if they made the rig compatible with their pipeline, there's very likely something drastically wrong with either the geometry and/or texturing that would end up causing rendering issues and/or a substantial difference in quality for the final render.
Long story short, while it's easier to code something on your own to prove a proof of concept, that doesn't mean it's easy to implement in a fully developed game.
That is completely true and I won't deny any of it. I have no experience in massive multiplayer games or HSR systems. It may or may not be technically possible given PGI's resources. Still, the point of this demo is to show that if properly implemented, a system like this could solve alpha strikes.
Troutmonkey, on 11 February 2016 - 05:08 PM, said:
That is completely true and I won't deny any of it. I have no experience in massive multiplayer games or HSR systems. It may or may not be technically possible given PGI's resources. Still, the point of this demo is to show that if properly implemented, a system like this could solve alpha strikes.
I may not agree with a CoF type mechanic to solve the overall issue of TTK, but I respect the work and effort you put into creating a visualization and explaining the thought process behind it. I hope you didn't think my previous reply was putting down your work in any way, because that definitely wasn't my intention.
We have lasers IRL that can shoot down missiles kilometers away.
This video doesn't make any sense.
Come of fire with cannon weapons while shooting, sure between recoil and stuff that makes sense. However giving lasers what amounts to recoil literally makes no sense at all. All I'm seeing in your video is a mech malfunctioning that, not something that anyone would put up with in the field.
You could come up with any justification to make any gameplay dynamic 'feasible'. If we 'suspend disbelief' to have 15-100+ tons mech shooting and running around with space travel amongst other zoology of sci-fi stuff, having a many lasers/weapons not having pinpoint damage should be straightforward.
LocationPeriphery of the Inner Sphere, moving toward the core worlds with each passing day.
Posted 11 February 2016 - 06:06 PM
Troutmonkey, on 09 February 2016 - 06:24 AM, said:
Okay so I've gone full hog into try to show people exactly how I'd like the pinpoint alpha strike problem solved.
I'm advocating for a system where each weapon is assigned a value to represents it "CPU cost" on the "Targeting Computer". Each time you fire a weapon, the cost is added to the computer and the computer returns a firing solution. The Targeting Computer can only process "X" CPU per second. Overloading the CPU causes the computer to return incorrect firing solutions. The more the Targeting Computer is overloaded, the more inaccurate your fire will be. Under normal circumstances fire will be 100% accurate, but firing too many weapons at the same time will likely cause an overload. Smaller weapons and spray fire weapons (SRMs, LB10X) will have a lower CPU cost than larger weapons.
The system shall be represented with a cone of fire. The more the Targeting Computer is overloaded, the larger the cone of fire. The CoF is completely unaffected by heat or movement. The system is based on Homeless Bill's original idea from 2013 but does not use convergence as that adds more technical overhead (and losing convergence is really bad, as per my last demo).
This CoF solution proposes to solve high damage alpha strikes from any combination of weapon systems by causing that damage to be more spread out than if those weapons were not all fired at once. It is an intuitive system from a players perspective, as CoF mechanics are already present in every top FPS game on the market. Skilful players will won't be punished for their skill in aiming, as long as they can also develop a skill in trigger discipline. It will replace ghost heat, and fill in the voids that ghost heat could not solve - boating mixed lasers / combinations of lasers and AC. This solution will require developer work with relation to balancing weapon CPU values as well as artist work creating new UI elements to represent the CoF and Targeting Computer's load. Depending on how the code is written, the CoF could use existing code based on the jump jet inaccuracy code.
Here is a video of roughly how it will work. Keep in mind that all numbers for CPU "processing", CPU cost,and the maximum amount of spread are all subject to change should any value be too extreme.
This video shows how 6 "Large Lasers" would work when fired in different numbers
and how 6xAC5 would work (1:50)
If you would like to try the demo scene yourself you can download it here (~20mb). Controls are 1-6 for weapons, and Enter to switch between.
Re: This is going to be a lot of work for the devs to do / it's too hard
Yes I agree there is a lot of work to do testing wise, but adding in the mechanics and UI is rather simple as I have just displayed (Server code may require more work, I'm not sure what their netcode is like). A simpler system would be nice, but we already have a "simpler" system called Ghost Heat and it's too easy to work around it and it doesn't solve alpha strikes, it just punishes them after the fact. This system would be impossible to bypass with different combinations of weapon systems. It's a future proof system that can be used to address most balance problems for the foreseeable future.
Spoiler
It's like the NBN here in Australia. The government decided to roll out a "Fibre to the Node" system because it was "cheaper" and "easier" to do knowing that it would be worse. Now it's not even finished and it's already obsolete. If they had taken the more comprehensive approach (Fibre to the Premises) that required more initial work (but less upkeep) we wouldn't be in this situation.
If I were to balance it I would start off and say that alpha of "~25" are okay, and that anything above that would need some spread. Then you would set the Targeting Computer's limit to 25, and then set each weapons CPU to the same as it's damage value. Then you would work out the finer details from there. Reduce the CPU for LBX weapons and SRMs, increase Gauss and PPC CPU slightly.
After that point you would take it to the test server and gather metrics. You can check if the maximum cone is too large or small. If any weapons are too inaccurate/powerful you can decrease/increase their CPU. If any mechs are too heavily effected you could increase their total CPU limit.
Later you can start to use the system to add value to other less used in game items like the Command Console and the Clan Targeting Computers. These items could improve the CPU cap at the expense of tonnage and slots in addition to their other benefits. You could even use it to buff / nerf underpowered / overpowered mechs.
Do you mind explaining which parts of this are a bad idea?
I've already dealt with the usual "but it's a nerf to skill" arguments by making it so that it only applies to high alphas.
LocationPeriphery of the Inner Sphere, moving toward the core worlds with each passing day.
Posted 11 February 2016 - 10:38 PM
Troutmonkey, on 11 February 2016 - 06:47 PM, said:
Do you mind explaining which parts of this are a bad idea?
I've already dealt with the usual "but it's a nerf to skill" arguments by making it so that it only applies to high alphas.
Because high alphas to a single location still require skill.
Any scrub lord can spray 50 pts of damage, to do it to a single component requires precision. I would even argue precision that cannot be reached without a mouse with good dpi adjustment.
Because high alphas to a single location still require skill.
Any scrub lord can spray 50 pts of damage, to do it to a single component requires precision. I would even argue precision that cannot be reached without a mouse with good dpi adjustment.
The different between hitting with 5 points and 50 points of damage of damage is non-existent. I don't considering myself a top tier player but I have no triple hitting where I'm aiming the vast majority of the time, and I don't consider it any more skilful to fire 6 LLs than it is 2. Coring out a mech in one two hits because of extreme accuracy breaks the games damage model which is designed to spread damage across multiple locations. Adding an element of skill in deciding how much to shoot at once would be a good way to address this issue, because right now the correct amount to shoot in all cases is "everything"
I still think this is the best idea for solving the problem.
The problem is high damage pin point alphas.
After all if you can only put 5 damage in one location that is not a problem. The problem occurs when it is just as easy to put 50 damage in one location as it is to put 5.
The targeting computer system allows for snipers, but would not allow for massive damage snipers.
It is also an additional number that can be balanced for each weapon. So a AC2 takes less computer power than a ML etc.
The only thing this effects if being able to jump out drop a high damage alpha and hide again. If you want precision you have to aim all your shots not just one, that requires more skill. If you're in a brawl likely the cone of fire would not mean anything and heat management would be king.
LocationPeriphery of the Inner Sphere, moving toward the core worlds with each passing day.
Posted 12 February 2016 - 02:12 PM
Troutmonkey, on 11 February 2016 - 10:45 PM, said:
The different between hitting with 5 points and 50 points of damage of damage is non-existent. I don't considering myself a top tier player but I have no triple hitting where I'm aiming the vast majority of the time, and I don't consider it any more skilful to fire 6 LLs than it is 2. Coring out a mech in one two hits because of extreme accuracy breaks the games damage model which is designed to spread damage across multiple locations. Adding an element of skill in deciding how much to shoot at once would be a good way to address this issue, because right now the correct amount to shoot in all cases is "everything"
Want to watch a game die?
Take a "thinking man's shooter" with very precise aiming mechanics, and a very small audience.
Then, drop some goofball CoF mechanic onto that group of players out of nowhere that only 10% of them might actually want...
In case you have not been listening...people are asking for the game to STOP being dumbed down to the lowest common denominator. A CoF does exactly what people are asking the developers to stop doing to an even greater degree.
What is after that? Everyone meet at theta and hug until someone falls over from impact damage?
6
Troutmonkey, on 09 February 2016 - 03:07 PM, said:
