Giter Site home page Giter Site logo

acf's Introduction

Armoured Combat Framework

The Armoured Combat Framework is a Garry's Mod addon which creates a balanced, realistic and fun to play combat damage system, simulating projectiles, armor and explosions, as well as engines and gearboxes.

IF YOU ARE HAVING INSTALLATION PROBLEMS, PLEASE POST ON THE FACEPUNCH ACF THREAD, NOT ON GITHUB. Please only create an issue on github if you've found a bug, or have a suggestion. The FP forum ACF thread is a good place for general ACF conversation, suggestions, and help requests.

When submitting a new issue or suggestion to ACF Issues page, please double-check that someone else hasn't brought it up yet. Be sure to check closed issues as well. Common suggestions that have already come up are turbos, propellers, cannon sizes, and engines.

Be sure to check out the ACF Wiki for more ACF related information.

acf's People

Contributors

amplar avatar brandonsturgeon avatar bubbus avatar cheezuschrust avatar fervidusletum avatar frankess avatar generalwrex avatar hoksalot avatar jonascone avatar kafouille avatar lazermaniac avatar looterz avatar noth1ng1996 avatar omnisudo avatar polysteam avatar profan avatar python1320 avatar reddeadlycreeper avatar scottyprogrammer avatar seikimatt avatar sestze avatar shadow7483147 avatar thegrb93 avatar vmajx avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

acf's Issues

HE Shove Power

HE shove power is a bit over the top right now. I believe the problem is that the applied force doesn't take into account the weight of parented props. The problem there, is how do you efficiently do that?

One option I thought of was a "contraption" table (akin to table that stores prop hp/armor) for each contraption that stores its parented and total mass.

When a prop is hit by HE, it checks to see if it has a pointer to a "contraption" table. If the table doesn't exist, it's created and stores the mass of each prop directly or indirectly constrained to the initial prop (like the engine parented/unparented mass calculation). Each constrained prop also gets a pointer to this table. If the table pointer does exist for the prop, the parented/total weight stored on the table is used to adjust the shove power. If a prop is destroyed, it subtracts its mass from the contraption table.

One potential downside is the initial calculations needed each time a new contraption is hit. I don't think it would be that big of an impact, seeing as how engines do it every 5 or so seconds.

Proposed change to health/RHA calcs.

Right now health and armour are functions of surface area. (https://github.com/nrlulz/ACF/blob/master/lua/acf/server/sv_acfbase.lua#L53-L54) In the code, health is defined as the structural integrity of a prop which is interpreted as the amount of material left after getting holes punched in it. Either I'm not seeing it or it's funny that we make no mention of prop volume at all in the health/rha calc.

Let's change health to a linear relation with prop volume, and armour to a relation between volume and area (higher area/volume implies less solid volume). It'll fit the concept better then and we won't have to screw with fudge-factors as much.

Growing entry barrier for new users

ACF is already fairly hard to break into for new users, and with the introduction of #35 and #36, it's just going to get that much worse. We need a way to ease new players into the basics of acf.

I propose we add a button to the top of the acf tool gui that pops up a browser window, which takes them to the wiki page here on github. The wiki should have:

External links
Could have links to various YT tutorials / combat videos / etc

Installation tutorial
Covers what svn link to use, or using the download zip button. People who don't know how to svn can be referred to the wiremod svn tutorial.

E2 Functions
Lists all ACF related E2 functions, with a description, expected inputs, and expected outputs.

The very basics mobility walkthrough.
Covers linking and orientation, wiring and expected input values. It should also use specific examples for the user to follow along with.

Intermediate article on mobility nuances.
Covers power vs torque, engine torque vs clutch rating, gear ratios and how it affects torque/speed, effect of wheel size, clutching techniques, effect of vehicle power:weight, explanation/usage/pros/cons of cvt

Mobility FAQ.
Covers common problems such as no acceleration, stuttery acceleration, overtorqued gearboxes, backwards clutching inputs, braking spaz, engine not functioning due to changed weight, etc.

The very basics weapon walkthrough.
Covers basic ammo creation, linking, wiring, activation of ammo. It should also use specific examples for the user to follow along with.

Intermediate article on weapons.
Covers pros/cons/differences/roles for weapon types and ammo types, tracers, colored tracers, ballistics (drop, drag, dead-on vs angled impacts, ricochets), refilling

The very basics of armor walkthough.
Covers RHA, HP, weight, basic acf armor tool usage.

Intermediate article on armoring.
Covers ductility pros/cons/usage, tank armor (common relative armor distributions, angled armor), effectiveness of AP and HE vs RHA and HP

Weapon/Armor FAQ.
Covers weapon not firing, brittle armor, refill not working

Combat Guidelines
Covers common building etiquette such as non-intersecting internals, weight classes, no auto-aimers, etc. Stress that these are just guidelines for fair and balanced play.

.

Any thoughts or other topics that should be covered? Radiators/fuel can be added to mobility topics later on.

Additional gun calibers --AWAITING IMPLEMENTATION--

Hello,

These days, i believe apart from some engine balancing we could use some extra guns, to freshen up the combat scene and further diversify vehicle's equipment until missiles get implemented properly.

For start, me and my friend have made a:

  • 240mm Howitzer
  • 150mm and 280mm Mortar
  • 12.7mm RAC

(Got the guns added in the gun list, all we need now is to resize them all but the Howitzer). They are all properly balanced in terms of stats. All they need is combat testing, which is what we're looking forward to by getting this implemented).
The purpose of those is to fill the gaps in the mortar list, as well as effectively increase the optimal tonnage range of acf, seeing as currently, people just build bigger and builder and don't stick to the traditional 40t limit.

If you find this idea interesting, and look forward to implementing this to ACF, please let us know, so we can continue with the model resizing (Won't take too long) and send you the end product. Who knows, if this gets approved we might start making more gun calibers to further diversify ACF's arsenal, and allow for bigger constructs.

----------UPDATE-------

We got the above implemented and resized(in a really hacky way), as well as add:
-170mmC and AL
-406mmHW (My friend did the model for this by accident and we were like "what the hell, let's do it". It might say caliber:290mm but balance wise it's double as powerful as a 203mm, even more!)

Right now we're waiting for Karbine or someone else to "proof read" it and check for balance inconsistencies and stuff and after that, implement it.
It's already quite balanced but it wouldn't hurt getting a different opinion.

Link: https://dl.dropboxusercontent.com/u/5669996/gunsgunsguns.rar

Workshop & ACF

There was a discussion going in the Wiremod Workshop about ACF (http://steamcommunity.com/workshop/filedetails/discussion/160250458/864974880624851382/#p1), and there's something I wanted to straighten out.

Bubbus was talking about separating the extras from ACF into several packs so people don't have to re-download a lot of things on changes. Workshop has long since changed; unless everything is wrapped up in one big superfile (even then I think it hashes and distributes blocks), it will only push deltas.

Also, I believe we use Jenkins (http://jenkins-ci.org/) to push workshop updates. We have it set up to monitor a workshop branch on github, and when we push to it, jenkins will then push to the workshop.

Figured that info would be useful to you guys.

CVT

buff large CVT to 2800nm torq limit so it can handle torque from a fuel-driven 21l v12 diesel

that is all

Ammo Crates: Better size selection

It can be difficult to find the right size ammo cache for every little nook in your vehicle, which is fairly important with the recent ammo capacity nerf.

I was thinking: instead of a pulldown with various sizes to choose from, why couldn't the user input the dimensions desired, and acf would create an ammo crate with a custom phys box similar to how makespherical works, except rectangular. The user could choose between the various visual models, which would be scaled to fit the desired size (like that old crate maker tool).

Version check

So it looks like github's new design has broken the version check which to be honest was kind of a hack anyway... so instead of just updating the string match we might as well do a proper version check.

I like the idea of the pre-commit hook updating it automatically, but as we discussed in #26 it's not the most effective since it's clientside. @Bubbus mentioned something about a serverside post-upload hook that would bounce back a modified commit though, I wanna know more about that. We can run whatever it is we need to run on my server. If we could pull that off we'd have automatic version updating for anyone who commits from anywhere, even from auto-merging pull requests so I think that'd be best.

Adjust Diesel HP/Armor

Diesel engines should have considerably more armor/hp than petrol engines, and have a smaller torque penalty from damage, as they are built to be tough. For tanks, this would make them a better choice over petrols, as they can take more punishment before succumbing to damage.

Engines related to #42 would be even less durable from maximizing power, and less suited for use in tanks.

Armour balance ~ideazone~

Moving the armour chat from the fuel issue (#35) over to here.

I figure we could replace the health/armour system with density/ductility sliders, something like this:

High density ductile has huge hp per volume, high density brittle has huge pen resistance per volume (not the same as RHA). Low densities have lower amounts of both, but lighter. Add value clamps on each side to keep things competitive. Then we add the new traced ballistics to convert those material properties into an eRHA upon impact.
Highest ductility values can take additional health damage due to loss of structural integrity, highest brittle values can take extra rha degradation due to fractures.

You end up with a system pretty similar to the current one, but you now have two clamping numbers and two scaling numbers which totally control armour balance, along with damage behaviour which discourages super-biased materials (sponges get swiss-cheesed, ceramics get shattered). They still have a use though because their first-hit resistance will be higher than less biased props, letting them survive bigger explosions and shell hits at the expense of follow-up damage events.
You also get the benefits of traced impacts: no weirdness with volume vs RHA (no more 250mm soda cans); side-on impacts get proper RHA values; pancake armour can't have physically impossible eRHA; and more... No need to stack a bunch of armour plates together too which is nice.

Crits?

Fuel FGD

From Lubstar:

Fuel tank map entities that don't run out of fuel or slowly refuel them self.
And settings like this

  • Name
  • Parent
  • Refueling speed
  • Max fuel (0 for infinity)
  • Self refuel speed
  • Fuel type (electric,petrol,diesel)
  • Start Active
  • inputs for on/off (for func_buttons)
  • Range
  • model

And a trigger brush that refuels all tanks in it.
same as above but without range and model

massive lags after update 410 or higher

Hello, im using re 450 on linux. our players cant spawn more then 2 cars since updates after 410

server fps will drop, usermessage spam in netgraph etc. unplayable.

no errors appear, i noticed that the fps drops more, if you connect 2 engines to a gearbox

Gun unloading doesn't work

Been a problem for a while, forgot about it. Basically the unload function on guns does nothing. Unload is used for on the fly ammo type changing, which is pretty important. Right now you have to switch ammo and wait for the next shell to be loaded, which is pretty clunky and wasteful for big guns.

More racing engines

With fuel, I think we can add more racing oriented high power, high rpm, low torque engines without disrupting the balance of tanks overmuch. These engines would require fuel, and would suck down ludicrous amounts of it. We can add a new efficiency category for racing engines that increases the fuel consumption even further, if need be.

I have a variety of custom engines that fit the bill, they would just need some minor balancing to fit with existing engines.

Gearbox script error

When someone on my server reconnects after placing gearboxes, console gives the following errors when they look at the placed gearbox, and they get kicked for "too many lua errors".

[ERROR] addons/acf/lua/entities/acf_gearbox/cl_init.lua:26: attempt to index a nil value

  1. GetOverlayText - addons/acf/lua/entities/acf_gearbox/cl_init.lua:26
    1. unknown - gamemodes/sandbox/entities/entities/base_gmodentity.lua:33

[ERROR] addons/acf/lua/entities/acf_gearbox/cl_init.lua:26: attempt to index a nil value

  1. GetOverlayText - addons/acf/lua/entities/acf_gearbox/cl_init.lua:26
    1. DoNormalDraw - addons/acf/lua/entities/acf_gearbox/cl_init.lua:14
    2. unknown - addons/acf/lua/entities/acf_gearbox/cl_init.lua:6

Transfer case: Independent drive directions

I was thinking the other day, that it would be handy to be able to do tank turning with a single transfer case. Is this feasible? It would be one less entity moving around with tanks.

Could separate the gear input into left and right, akin to clutching on dual clutch. Then some special case code in the gearbox to tell it which direction an output should apply torque.

Also, a couple options for adding them into transmission list.
Option 1:
Modify existing (dual clutch only?) transfer cases to be able to reverse outputs independent of each other. Wouldn't have to add more entries to transmission list.

Option 2:
Separating it into a new type of transmission, like how dual-clutch is set up. However, would necessitate at least 6 new entries to the transmission list (small, medium and large varieties of normal and inline). It would also only come in dual-clutch, to reduce number of entries. No point in dual drive directions without other dual drive controls.

ACF globals

Everyone needs to remember to update that one line in acf_globals.lua for the update checker!

And also please do a Pull before you edit/commit/push conflicts are bad!

Armor Properties Tool

The Armor Properties Tool sets the wrong armor values if ductility is a value other than 0. For example, giving a prop 200mm of armor and -80 ductility will cause it to end up with 89.44mm of armor. Giving a prop 200mm of armor and +99 ductility will cause it to end up with 268.32mm of armor.

Engine Designer

Making a dedicated topic for the Engine Designer; moving it out of #42. I'll probably have a lot of questions on balance once I get started.

Inputs

  • Cylinder Arrangement
  • Fuel type
  • Torque
  • Powerband Locked by divisor, 1.6 for petrol, 3 for diesel. Divisor means the top of the powerband divided by the bottom of the powerband. You would set the engine's powerband within the engine's available RPM range based on its fuel type/displacement. For example, if you have set a motor to 100nm, it would probably be around 0.75-1 liter based on your piston arrangement. From this, the engine will display its maximum rpm possible, we will say 10000 (gasoline engine). From this, we will be able to set a powerband from a minimum above idle rpm (this modifier will be based on fuel type; higher for gas, less for diesel) with a divisor of 1.6 (gasoline divisor). If we wanted a torquier engine with low range power, we would set the powerband min to 3100, and the peak to 5000. 5000 / 3100 is roughly 1.6. This kind of engine will obviously suffer in horsepower. The powerband minimum, again, will be dictated by a minimum based on the fuel type and displacement. For instance, since this example engine is gasoline and probably around 1 liter (100nm input torque), the minimum powerband rpm would be between 3-5k rpm. If this engine were 1000nm, and 10 liters, it would probably have a minimum of
    1500 rpm (while a diesel may be 700 minimum) Basically, whatever point in the engine's available RPM range you set the peak min/max will determine how much horsepower your engine develops, its weight, and flywheel mass. The larger an engine is in displacement, the lower amount of available RPM range. So, you won't really be able to make an F1 engine out of a 20 liter motor.
  • Sound
  • Pitch Modifier

Output

  • Displacement based on input torque, cylinder arrangement
  • Idle based on fuel type, displacement, and slightly modified by the powerband, so high revving motors will have a higher idle.
  • Redline based on displacement, cylinder arrangement, powerband maximum. if the powerband maximum is already reached by limit of displacement, then the redline will end there. Otherwise, the redline will most likely be between 1 and 2 thousand revs above the powerband peak. This will be based on displacement/arrangement, etc.
  • Flywheel mass Based on displacement/fuel type/cylinder arrangement. For example, a single or twin cylinder engine would require a much heavier flywheel than an 8 cylinder.
  • Power this is a product of torque and RPM. It will also be modified by the cylinder arrangement to balance engine types. For example, a V6 engine is supposed to be more torquey than an inline 6 and boxer 6, but produce less horsepower. So if there is an I6 set to 500nm and a V6 set to the same, the I6 should produce more horsepower, but the V6 would be lighter, and lower displacement.
  • Engine weight X amount of KG per liter of engine displacement modified by fuel type
  • Engine model size

Most of the modifiers will require a lot of fine tuning to get everything balanced, but it can be done.

Balance example

Remember, acf is centered around carbureted gasoline engines and the tech of the 30s-60s, not modern engines.
Inline 4 vs V8

Both engines 500 NM torque, same power output, low-range power build

I4 would be defined around 7 liters
V8 would be defined around 5 liters

I4 would be natively heavier due to cooling and structural requirements (heavier flywheel to balance etc)
V8 would be lighter

I4 would be smaller (this is important to combat vehicles)
V8 larger

I4 would require a lower powerband to create equal torque
V8 wouldn't need such a low powerband to develop the same torque (less work))

Other Thoughts

I believe someone mentioned that engines created with the designer should have a slight power advantage over the current "premade" engines.

"Crew" Modules

Seeing as we're in need of more internal components to force players to adapt to bigger sizes, it would be the perfect addition to add some sort of "Crew" Modules.

Let's start with a gunner/loader module. Basically, what this does is act like an entity that you can simply link to a gun with ACF that buffs the fire rate and/or the accuracy of a weapon, through a slider, by a maximum of 25%.

However, this would also come at a cost. The module would have to be as big as an acf pod or pilot seat and weigh 250kg. In addition, the bigger the gun, the more gunners it should need to reach its maximum buff efficiency of 25%. What would be good in my opinion would be:

  • 1 gunner for up to 2200kg weapons
  • 2 for up to 6000kg weapons
  • 3 for the bigger ones.

This could easily be done by having a "light" module, a "medium" module and a "heavy" module.
Last but not least, losing a module in a fight should lead to a severe debuff, according to the module's attributes. For example, if i had a "light" gunner module boost my gun's attributes by 25% and it dies during a fight, my gun would be nerfed by 40% on top of the buff, so a total of 85% efficiency.

A similar method could be adapted for engines too, but only a single driver "module" could speed up the engine by 15-20%, as deemed fit, at the weight of 250kg as well.

If, once the module is destroyed, the debuff thing is too much to implement though, it should just remove the buff from the modules only.

Conclusively, all these do nothing but buff the effectiveness of vehicles. People can still make small vehicles without a crew and it'll be the same as before, but people who build bigger vehicles with crew modules will enjoy a boost in both firepower and mobility. This should not nerf any current vehicles nor be mandatory, but considered as an advantage to building bigger vehicles.
I hope this gets implemented as soon as possible, seeing as it would, in my opinion, change the way vehicles are built, and diversify ACF even more.

P.S: Hopefully what I wrote makes sense, since my native language is not English.

Viable engines for Aircraft

So basically, when it comes to ACF fin aircraft, you need an awful lot of power and torque for the weight of the engine for satisfactory performance.

With normal 25% fuel, options start to limit themselves, especially in higher engine size classes. There just isn't much in the way of high power/torq, low weight engines. There also isn't really a way to implement this easily without totally screwing tank balance, but requiring fuel could be a start.

TLDR; big(~20l) racing engines for planes plz.

ACF size is ballooning due to giant .wavs

The sound folder is getting pretty ridiculous. ACF content is 586MB, of which 442MB is sound data.

I propose we compress all these sounds to .mp3 format. Source supports some high quality mp3s so we shouldn't lose out on audio clarity (though it doesn't matter for half of the sounds cause they're from youtube).

Me and Frohman entertained the idea in the past and discovered that appropriate compression can take the sound folder from ~440MB down to ~50MB. We'll need to update sound references to the new .mp3s, but it won't be more than a quick find+replace job. I think it's worth it.

Issues? I'll go ahead with it otherwise.

decrease fuel consumption

2x 23L V12 consume 10 liters fuel in 10 seconds with 100% throttle?

Please balance this to a realistic value.

examples:
A Boeing 747 need 37.9 Liters per 10 seconds, but it has 156000 HP. 2x 23L engines are below 1500 HP

The Maybach HL230 used in a TIGER TANK is a 23L V12 Diesel, that need 1000L per 100km
ok, 2 engines = 2000L / 100km
max speed is 20kmh (of the tiger tank), it will reach the 100km in 5 hours

2000L in 5 hours, that is 1.111 liters per 10 seconds.
or 0.555 liters for a single engine

HE Projectiles: Fuse

I've noticed there's some existing code for fused projectiles; I was wondering if there is a reason that HE shells don't take advantage of this for airbursting. Are there any potential balance issues? Airbursting HE 203mm HW on aircraft or above tanks? I know it would be useful for smaller caliber weapons as anti-air.

My only concern is how the user sets the time delay on the fuse.

A wire input on the gun doesn't make much sense: assuming only HE rounds are fuse-able, do we always have the wire input on the gun? If the input is only when the HE round is loaded, what happens when round type is switched?

A wire input on HE ammo crates makes a bit more sense, but is a bit clunkier: say the user has to use 4 crates to fit all their ammo, then they have to wire each crate.

Fusing could be set with other settings during ammo creation in the tool. This I think would be more realistic (I assume fuse delay couldn't easily/rapidly be set on the fly, in the 40s-60s). It would also make it far more difficult for large caliber, slow firing weapons to be used as AA, due to unload/reload speeds to get the best appx. fuse delay.

Using e2 functions, say Gun:acfSetFuse(timedelaymillis), is another option, but excludes users who don't e2.

Radiators

Size is what drives balance in acf, so I thought of an idea for radiators. Basically, you link any prop to a motor and it gets assigned as a "radiator", and based on its size (surface area probably, like armor calc) determines its cooling effectiveness and ACF assigns it a weight so you can't use a bit of armor or baseplate for a radiator.

In basic form:
Engine will not operate without a radiator of sufficient size depending on motor type
Radiators will be pretty big (their whole purpose is to take up interior space)
Their mass assigned based on surface area so they are too light to be used as armor and structural (weight doesn't really matter, it's size that does giggity)

Down the road:
Engines can run without radiators, but will offer less output than an engine with a radiator
Overheating
Require to be touching open air (this is kaf's original idea) to operate (such as sitting on the engine deck)
Require to be in proximity of engine

If you've got any more ideas, please share

Ammo capacity too small for larger vehicles with larger guns.

a8def66 was commited with the following intent:

These changes are to ... force tanks to go larger to carry more ammo or use smaller engines to fit ammo in existing vehicles. There is currently no incentive to use a smaller engine in a tank.

I think this commit has failed at its stated intent: people are still making tiny speedracers and larger tanks like my 80t or my friend's 50t TD have scarce ammo supplies. Combat isn't fun when I only get to take 10 shots. Let me ask these questions;

  • What was this commit intended to balance?
  • Why was this approach taken to achieve the intent?
  • Why has it not worked?
  • What is a more effective approach?

I'd like to revert the ammo capacity nerf and replace it with something more sane. Smaller ammo capacity fraction in the smaller boxes on a sliding scale rather than a flat nerf would make much more sense in achieving the stated goal.

New Armour tool is causing imbalance with composite armour.

I've been contacted by various gents who say that the new armour-slider tool makes tank armour near-undefeatable with appropriate composite techniques. By placing a high-health layer over a high-armour layer, the health cost of armour is absorbed by the external 'soft' layer, defeating HE, AP and HEAT. APHE should theoretically be effective - detonating upon the armour layer after penetrating - but I have been informed that this is not the case.

I have presented solutions: high-armour props could carry a weight penalty; clamping could be revised; value curves for armour and health could be made non-linear.

Composite armour should definitely be beneficial, but if we're receiving reports of imbalance it would be impudent to ignore them. Any suggestions? I'll be talking with the gents more tomorrow to see how to best resolve the issue.

Different fuel grades and cooling

I finally had some time to dick around with acf, however it was on GGG with sestze's weird fuel settings, which set shit to 100%.

Raised an interesting idea, why not have two grades of fuel? Regular (which would be 25% boost) and something like race gas or super high octane/cetane (100%)

the "nitro" would consume at incredulous rates ( and be incredibly fragile and kaboomy) and require cooling to be sustained or some shit. Would open the door to engine heat and cooling and shit.

With cooling too, could have the option to run cooling ents instead of fuel for the same 25% bonus, or run fuel AND cooling for a further bonus (like 40-50%). Like fuel is supposed to do now, trade interior space for mobility.

Additionally, you could run the super high grade + cooling for a max bonus of 75 or 100 or something, at the cost of a shitload of interior space because incredulous consumption rates.

Engines would still be able to run without fuel or cooling.

I also think that engines that use fuel should no longer run when empty or fuel not active.

We need fuel.

Combat is hitting breaking point. I can't keep nerfing things to try to supplement the real problem. Tanks are too small. We need fuel to take up interior space. It's the easiest thing to do. It will use ammo crates and each engine will have a specified consumption based on throttle.

Fuel basics:

Same flammability/explode-ability for gasoline/diesel.
Use ammo crates.
Engines should be rated in liters or gallons per minute (it will be exaggerated obviously.)

Please, tweak, ferv, someone, I'm ready to give up on ACF. Changes need to be made to combat that aren't raw nerfs.

Strange Issue with list.Get()

[ERROR] addons/xcf/lua/autorun/acf_globals.lua:171: attempt to index field 'Clas
ses' (a nil value)

  1. unknown - addons/xcf/lua/autorun/acf_globals.lua:171

Timer Failed! [Simple][@addons/xcf/lua/autorun/acf_globals.lua (line 170)]

When you try to PrintTable(ACF.Classes) its nil.

when you PrintTable(list.Get("ACFClasses")) it prints fine

when you manually load them with lua_run it sets them, and then it prints, I've tried about 20 different things to fix it, and it seems to just be my dedicated server!

Server is a fresh install, and XCF and ACF are fresh installs.

Am I missing something Special we're supposed to do on dedi's? works fine on my client, Both ACF and XCF do it.

Ammo Type: Flechette

I've been fiddling around with a new ammo type, flechette rounds. Here's what I've come up with so far:

Intent:
Create a shotgun-type anti-infantry or anti-light armor round for cannons and other slower firing weapons. Each round of ammo contains several smaller AP submunitions (flechettes) per shot. The flechettes are dispersed as they leave barrel; the initial round does not carry the submunitions some distance before releasing them.

Limitation:
Flechette ammo type is limited to C, AL, HW, and SA guns. AC, RAC, MG, and HMG fire too fast to make submunitions feasible, and MO, GL, and SL rounds don't have enough KE for AP rounds. This prevents guns from getting too spammy with submunitions. SA has the highest fire rate, around 300 submunitions per minute (with a maxed shell length).

The maximum number of flechettes contained per round is floor(caliber * 0.25 - 3). For example, a 25mm SA round can hold up to floor(25*0.25-3) = 3 flechettes. A 50mm cannon round can hold up to 9. The minimum number of flechettes is 3. The limit is arbitrary, but keeps guns from spamming submunitions.

Customization:
Number of flechettes per round; increased spread in addition to the inherent spread of the gun.

Balance concerns:
203mm HW can fire 47 flechettes per shot, at 189mm pen per flechette, or scaled down to 3 flechettes at 259 pen per.
25mm SA fires 3 flechettes at 47mm pen per, whereas standard AP rounds for 25mm SA have 1 shot at 56mm pen. Larger caliber rounds approach ~60% pen of an AP round, per flechette (when number of flechettes is maxed).
Minimized round lengths can boost submunitions/min upwards of 500-600.

Possible solutions:
Some propellant could be wasted, effectively reducing KE of each flechette. Could base it on the wasted space inside shell? (shell area - num flechettes * flechette area)
Increased drag on flechettes.
Increased minimum spread for flechettes.

Other thoughts:
Should the flechettes be carried by the initial round until released by fuse timer? It would allow for a more customizable cone of dispersion.
Should mortars be allowed to fire flechette rounds? The argument could be made that the flechettes shot from a mortar gain enough KE falling from a high fire angle to be useful as anti-infantry.
Additional ammo type, explosive flechettes ;D

Script error

I'm getting this error, when i create a server using "start new game" from the menu::

[ERROR] addons/acf/lua/autorun/acf_globals.lua:243: attempt to compare number with nil

  1. v - addons/acf/lua/autorun/acf_globals.lua:243
    1. unknown - lua/includes/modules/hook.lua:82

I couldn't find anything using google, and noone seems to have this problem. What am i doing wrong?

Limited Top Speed Issue

On other computer I built a car that has top speed about 120 kmh or about 75 mph, well on my computer almost every single car's top speed is 75 kmh, I tryed to get that car from other computer on my computer and top speed was limited by 75 kmh instead of 120. I tryed to completly reainstall Garry's Mod(I deleted all folders) and it didnt work. Then, I tryed to join a random server and its top speed was 75 kmh. Then I tryed on a diffrent server and it worked just normally(120 kmh), on single player and most of servers I was limited by 75 kmh. When I reach about 75 kmh differentials start to brake, its really annoying, if you can help me with anything I will be very thankful.
P.S.
Im using Makespherical, Sprops wheels.But I think that just doesnt matter, because gearbox start to brake. D:

Engine Parenting

Suggest we make engines parentable. Since the use of driveshafts requires that they are welded like gearboxes, and they are now a vulnerable component of a vehicle, it makes sense to make them parentable like gearboxes.
I don't see why this was not done long before--just like gearboxes they require a physical entity's positioning on the vehicle and a constraint, and attempting to parent and not weld would sever the gearbox links. I cannot think of any practical way it could affect combat.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.