All-VATS Combat: 5 Script Tweaks to Approximate Turn-Based.

"what led you to choose 13 seconds as the optimal length for the enemy's turn"

Hehe. I was testing twenty and counted how many times Mel could shot at me... Seemed much more than i could so i lowered it to 15 etc... Then i came to 12 through console... In FOMM i had to enter 1.2 and while i'm but simple lawyer not a programmer i have not a slightest idea how the hell write that in this whole hex or something so i just copied the closest to 1.2 entry under GMST :) It was quite ok so it stayed that way. Besides: 13 seconds, vault 13, good noumber for fallout. Though 12 would be more classic, biblical ;)

And to tell the truth the more the better as computer seems to stuck sometimes with animations, dogs are sometimes standing 13 seconds without attacking, opponents sometimes stare at me thoughtlessly etc... But 20 seconds would be unbearable.

Anyway. After more testing i think that unless we get rid of slowdown my mod sucks badly. I mean... 13 seconds waiting isn't bad itself (in f1 and f2 we had to wait more) but having to watch this terrible camera, hear all this slowed down voices, all this riddiculus decapitations (i swear i didn't take bloody mess and still i get 100% decapitations when shooting at head! i tried to alter that but setting i was modyfing didn't work: icombatexplodepartchance seems to do something else...).
 
Good work vonmistont :clap:

I'll download the mod or make the changes myself, although I'm not sure the 13 seconds delay in V.A.T.S. will stay, considering I find the delay by default already too long. Thanks for pointing out the variable to change though, I'll try to switch to zero or some low value and see if it does help the vanilla gameplay (in which V.A.T.S. is nice, but takes far longer than normal shooting).

Next step is to make slow-mo less ... slow, I'm pretty sure there must this kind of variable somewhere. You said you couldn't find it, maybe its name is rather obscure. I'll have a look at the .ini and .esm/.esp tomorrow.

As far as decapitations goes, it's not the same as head explosions. Decapitation seem to occur whenever the target dies by a shot in the head, whereas explosions is usually death by missile or other ... explosive means, in which case you can find eyes and brains parts here and there. Still, I would also like for them to lose their heads less often, it's strange that a 10mm pistol bullet, or any bullet, would tear flesh that often instead of piercing holes.
 
No it isn't there. Like the variable governing Level cap. I was also searching for that and noticed today that someone already mad a mod. It was iMaxCharacterLevel. I guarantee you won't find it in esm. I think that author just made extensive console search for viable options. I think that unless someone from bethesda tells us what the hell is it (maybe they don't tell that because noone asked? :) ) we must search blind.

I recently uploaded new versions of my mod. They aim at making slowmo less painfull by lowering computer turn time to 6 seconds with damage increase. It works ok.

To make it more functional i would require:

1. variable that lowers "stagger" chance for enemies... after they are hit they just play their animations of pain etc instead of shooting sometimes
2. better camera work to make it less irritating, maybe static over the shoulder camera? variables are there i will try them tomorrow
3. Maybe APs cost reworked... Different one for different weapons would be great.
4. aesthetic mod that lowers chance for critical effects like decapitation etc. (it really bothers me, looks silly and kills atmosphere for me, it could be funny in isometric f1 f2 but now it's just too realistic, i'm disgusted)

P.S.
As to original idea of this thread (of making computer "Turn" from real time) it's fully doable right now. You can differ AP regen rate, and to prevent from attacking you can always... remove cursor from the screen :)
 
Re: All-VATS Combat: 5 Script Tweaks to Approximate Turn-Bas

qi said:
EDIT: Section 4 edited, point elaborated.

Yeah, I hate VATS too, and it would probably be more fun just to get the FPS mechanics up to a roughly STALKER-level calibre.

But - who knows? Even if you don't think my ideas workable, our discussing them could very well result in some useful orientation to future modding projects that relate to VATS and the overall combat system.

So for whatever meagre measure it might matter, MMM so clever m m m m m's everywhere, here goes:

1: Let's assume that the slow-down in VATS is based upon a variable and that this variable can be altered. Continuing on the basis of that assumption, let us suppose that we could find it within the realm of our collective ability to, by changing that variable, mitigate or negate entirely the slow-down in VATS. This modification, regardless of what one thinks about an all-VATS combat system, is sure to be a high priority even for modders who are not affiliated with NMA. It's really just a matter of time - assuming, of course, that it's possible.

2: Let's also assume that the rate of AP points' regeneration, as well as the amount deleted by attacks, are both similarly adjustable variables. I anticipate that the latter value is a property of each individual weapon. If I'm correct, then we should have great success with rebalancing weapons for use in VATS mode, making smaller calibre pistols quicker to fire than the standard 10mm, thereby making them a viable alternative, as they were in earlier games.

3: Of course the key to the idea of an all-VATS combat system, as you've likely guessed already, is to prevent the player attacking in real-time. A scripting engine could very well zero-out your ammo every three or four seconds in real-time mode, all-the-while managing a behind-the-scenes table that would calculate your total ammo based upon your pick-ups, purchases, and number of shots fired in VATS. These sums of ammo would be restored to you immediately upon entering VATS. This solves the problem very simply, you see - and also solves the problem of being seemingly unable, in F3, to unload weapons and thus retain your ammo should you decide to sell or ditch the weapon.

4: Then we would have something a bit alike to turn-based combat. The real-time segment would be your opponents' turns, during which you would be limited to using items in your inventory and manoeuvring for cover and line of sight. Because we could tweak the rate at which AP regenerates, we could then make it your "turn", with full AP, after an optimal interval of time, tied to your Agility stat. EDIT TO CLARIFY: Your AP would return all-at-once, the "rate" would be maximized - but it would not turn "on" until after a set amount of time, and this amount of time would be either tied to your Agility stat OR universal for all players and only the total amount of AP would be determined by your Agility stat. It would really come down to the nitty-gritty of gameplay testing, which is of course beyond the scope of this post.

Finally: It remains then only to halt the AI during your attack animation, which I think could be simply managed by turning all "Reds" into "Greens" (i.e., hostiles into friendlies) via scripting function, during the VATS attack animations. Then we've finally a system that begins to offer some meaningful similarity to a turn-based combat system, as we all would've preferred from the start.

Broken down into these simple steps, the task suddenly seems much more feasible, doesn't it? I've played many of the scripted mods for Oblivion and several for Morrowind, and nothing that I've proposed here seems unlikely in light of those experiences.

One of the scripting engine programmers for Oblivion's mods recently posted here, notifying us of his remarkable progress with Fallout 3. I would love to hear from him whether these ideas have much chance of panning out - but, of course, also from all of you. There may be something I overlooked, or something else that would be grand to include.

Thanks for reading, take it easy.

you liver-spotted texan prawns, you. :evil:
Click to expand...

#1: Appears to be hardcoded, live with it
#2: Partially hardcoded. Outside of VATS, a formula is used. Inside VATS, a variable is used.
#3: Ridiculous, imo. There are better solutions, I've already found one.
#4: Enemies still attack and act during VATS, by default the player is in a pseudo "god-mode" while attacking in VATS.
#5: Also ridiculous, imo.
(#6): Currently scripts cannot be modified and/or added to F3 simply because they need to be compiled. When this becomes possible, the turn-play plugin I have been working on will be released.
 
Dubby : glad to know you're working on a mod and had some success with it (apart from the obvious "no compiler" issue).

Here's a quick reply to your "contribution" :

1) You don't know that. Right now, nobody does except BS staff.

2) What is your point ? AP in V.A.T.S. is suggested to be used as it is now (with modified costs). Since when cannot a formula include time in its equation (which it already does anyway) ?

3) Instead of mocking others ideas, why don't you give us yours ? I gave mine of weapon drawing/holstering, but apparently you did not read the whole thread.

4-5) That they attack during V.A.T.S. is exactly what point 5 addresses, and suggests disabling the AI or turning enemies into allies. I agree there may be other ways to do this, but I have not thought of one yet. Did you ? If so, please share your knowledge with us.

6) Variables are nothing more than variables. Construction Set or not, an external program can be made, running scripts and modifying these variables much like a trainer does. Actually, a trainer could be the starting point of such a tool. I don't share your optimism concerning modding tools released by Bethesda given their current communication on the matter. Currently, it's more an "if" than a "when". But I don't lose any hope that F3 can be modded either, with or without BS's help.
 
Ah, please accept my apologies if I seemed hostile. I'm sorry.

1) Well, not for certain. But it acts as a playback of gameplay data that appears to be set, activated, and played out on a different frame ratio than normal gameplay. Doing this with just a script, or a variable... is... well. Well it's not a very good idea. There are alot of values for VATS in GMST, and I've looked at about 90% of them - none of which alter the slowdown effect. I also think the slowdown is hardcoded because of how it manipulates the sound dynamics - it's just more logical to do that in C or C++, and allow for the other procedurals to be configured by the team outside of the sourcecode. Atleast that's what I would have done, same to say for some of my coder buddies too.

2) There are numerous GMST that determine the cost of an attack inside VATS. AP usage outside of VATS (which as I mentioned is disabled by default, I'll explain why in a moment) is determined by a formula, which appears to derive a value from **each weapon** that is unique to that weapon and not based on weight, rof, damage, etc. Various tests have led me to conclude this.

3) Drawing/holstering is already configured with two script commands: EnablePlayerControls, and DisablePlayerControls. I have a script ready to make proper use of these but as I said, need a compiler first. :( Furthermore, as to explain the above in #2, my research and digging has led me to conclude that Bethesda had originally intended to build a gameplay engine very similar to the original design by black isle, with action points being used in real time. This functionality still exists in Bethesda's Fallout, but is actually disabled by default. it does not work for all possible actions, but it does work for the most important ones. Second, the script(s) that would work in tandem with these un-hinging changes would also be run once per frame, or once per second - I'm not sure which Bethesda uses, but it is one of those two. (It is likely once per frame)

4-5) Personally I am not bothered by this, but that is only because I am not relying on VATS as the sole outlet for fighting. With the plugin I've been working on, VATS is in effect the same as "aiming" was in fallout 2 & 1 - chance of higher damage & targeted appendage effect(s), at the expendeture of higher action points. Where as, the "run and gun" gameplay utilizing action points is much like the basic turn-play that f2 & 1 had. Because this game has the capacity for real time interactions, it cannot easily - or likely sensibly - be retooled for turn-based combat. However, governing the relative "speed" at which the player can sustain an attack, and likewise for the opponents, in effect will emulate turn-based combat. That's the goal of my mod, and so far it's looking good.
 
Thank you for you polite reply, I admit I mistook you for the kind of person you clearly aren't. My reply was a bit hostile in response, please accept my apologies as well.

As pointed out by Raven_75 in this very thread, slow-mo seems to be nothing more that a script setting "GlobalTimeMultiplier" and various camera angles. He also said that Bullet-Time can be reproduced in the console without entering V.A.T.S. by using sgtm(0.x). It alters sounds automatically as well, the sound engine probably keeps track of this variable for distortions effects.

I didn't notice any difference in AP usage outside of V.A.T.S., it seems to be regenerating at a constant rate whatever I have in hands. I agree AP cost is probably more than just a weapon's characteristic and nothing more, but it is part of the formula, and has a pretty big impact.

You must have done a lot of digging to find these remnants of real time action costs by Bethesda, I commend you for that. The whole point of this thread was to use V.A.T.S. to turn the game back into a Turn-Based approach, or at least something close to it. This is what we're trying to do by dividing the time during which the player can act, and the time during which the enemies do. I agree it's far from perfect, in its current state movement is a big issue as the player can only move during his enemy's turn and not at all during his own. But we have time to think of something until the tool that can make it possible come out.

I don't think applying costs to real time actions will make the game have a turn-based "feel". It will still be real time, as you and the enemy won't have any turn to speak of. On a side note, this system would still allow the player to compensate his poor character skills with his own aiming skills, something that an all-V.A.T.S. battle system would make impossible.
 
I took a look at sgtm and have two possible rough conclusions about sgtm:

1) VATS-mode must have some sort of hardcoded slowdown, in addition to sgtm time alterations.
2) VATS-mode recalibrates sgtm rapidly, during the playback. This can be apparently altered with external sgtm fiddling, but is still subject to be reset to another value by the VATS engine itself shortly thereafter.
 
It sounds to me as if Dubby's got a very good mod in the works insofar as making AP actually matter again, which is a nice step forward. Nevertheless, I do think Bowyerte has a good point in mentioning the real aim of this thread, which is to emulate turn-based gameplay by manipulating and exploiting VATS. I don't say that with the intention of discouraging Dubby from contributing, as I do appreciate the insight he's contributing, but it is important to keep in mind so we don't get too sidetracked into debate over what overall system would be "best."

Dubby, I'm no good with the technical stuff, but I am curious what you mean by "VATS Engine." Do you mean the Fallout executable file itself? Did you get any idea of how rapidly VATS recalibrates sgtm? Is it static rate, or at least formulaic? Maybe by having a script "spam" sgtm with the intended rate, the recalibration by VATS could be overcome? Or, if that's more trouble than it's worth, maybe we could just bring up the "base" speed of VATS, bumping the overall speed up by, for example, a factor of two, but the slowdowns/speedups done by VATS would still run their course; the overall effect would still be better than default.
In any case, if the only issue that this will effect is playback speed of VATS attacks, I don't think we need to worry too much; at worst, it's an annoyance, not a total upset of our intentions.

I'll post more later, rushed at the moment, thanks again everyone, bye.
 
I'm 90% sure that slowmo is not hardcoded. I not only checked variables in esm file but also took a look into exe file. And i found interesting line there, statement suggesting that slowmo is

SET FOR EACH VATS CAMERA

And it seems to be true. I have no experience with hex. I tried to modyfy cameras with fomm but no result yet. I'm sure though that if someone experienced with hex look at it we could get rid of it.

What else tells for this theory? Take look at how each camera shot have different time. Melee fight shots are at 0.7 globaltimemodifier etc. Camerashots following your bullets are much much slower etc. It IS coded for each camera. Possibly in camera data. I think i even found which hex byte makes that but when i change that NOTHING changes but maybe it's something wrong i do. I'm not a programmer.

I also know how to implement AP burn for real time. Also for drawing weapons, crouching etc. But unfortunately there is no limit so you could go with your APs below 0, to infinity.
 
vonmistont said:
SET FOR EACH VATS CAMERA
Click to expand...

Oh, when you said that, a little lightbulb went on for me.

Let me elaborate.

With fomm, open the esm. Look down to the bottom-end of the list of groups, and open the group named GRUP (CAMS). The VATS cameras are all in here, however I do not know what part of the subrecord list controls the slow-down effect. I will however, help as best I can:

Code: 
(CAMS) BulletFlybyCam01Slow
	(DATA)
	01 00 00 00 <- integer, 1
	01 00 00 00 <- integer, 1
	01 00 00 00 <- integer, 1 (these three are probably switches)
	37 00 00 00 <- integer, 55
	00 00 80 3F <- float, 1.00
	00 00 00 3F <- float, 0.50
	8F C2 F5 3C <- float, 0.03
	00 00 20 40 <- float, 2.50 (if the slowdown is here, it is one of the above four entries)
	00 00 00 00 <- probably unused
	00 00 00 00 <- probably unused
	
	(MNAM)
	This is a FormID entry that points something to something else, somewhere else. No, I don't know what the formID is referencing, but it may be a projectile (GRUP) PROJ entry.
 
Very interesting, it's true that the slow down is different depending on camera angles (Assault Rifle bursts, or Sniper Rifle single bullets are clear examples).

During your experiments with AP burn, did you somehow manage to include movement costs as well ? I just had an idea reading the Tweaking Guide recently published, when I found a console command that ... disables AI.

I haven't tested it in game yet, but if it does what it says it does, ie make the AI stop all kind of movements and continue their previous action, then there may be a different approach for movement.

If AP cost to movement is possible, then a script checking if AP is negative could be used to temporarily add a 500lbs important item (not droppable) to the player's inventory, thus preventing any further movement, and enable AI back. Once all AP have regenerated, the item would be removed and the AI disabled again. Of course, AP would only regenerate if the player currently has the said item in his inventory.

Shooting would remain as we thought it would, using V.A.T.S. to enable player controls and disable them as soon as V.A.T.S. is finished.

These scripts would only run in the presence of an enemy. There is already a way to check for close enemies in the game, since the red markers on the compass seem to do just that.

This is just my unrefined quick thoughts about it after reading the Tweaking Guide, feel free to criticize it to your heart's content :)
 
I will cite what made me so sure about that camera-controlled slowdown:

"Bad Vats Camerashot Data : '%s' has a Global Time Multiplier that is too small"

I found that in exe file (along with many many more GMST type variables, some worth mentioning like bonus chance for critical while in VATS i.e.)

>Dubby
Thanks. While not a programmer i already figured this out (by a little but lame way :) i just copied every 4 bytes to floats and integers of GMST variables and observed what gave me sensible results :) ). What i didn't know was that integers cannot control slowdown. I was almost sure that the one controlling slowdown would be this fourth integer.
I compared different cameras data and noticed following changes. This integer was set to 07 00 00 00 that is 7 for melee and granade cameras and in fact gtm is 0.7 for that camera shots. While most of other cameras like ranged cameras had 03 00 00 00 and gtm could be 0.3 in that case.
But now when you explained it to me... hymmm maybe it would be 2nd float then?
But somehow any changes i made don't work. I notice absolutely no difference even when i change all values to 00 00 00 00. but maybe i did something wrong that's why i ask for help.
Also take a look on CPTH node it also controlls cameras.

>Bowyerte
No i didn't check that when i noticed that below 0 to infinity issue. The script would be quite easy i think but since we can't make scripts i let that go for now.

Try experimenting on your own the variable i'm talking about is

fActionPointsRunAndGunMult

default 0 while on 1 you get normal ap burn.

There are also variables for walking etc. Maybe they work i didn't try it.

EDIT:

P.S. Dubby what do you think about ability to compile script under Oblivion Construction Set and then just exporting that mod to Fallout?
 
Bowyerte said:
These scripts would only run in the presence of an enemy. There is already a way to check for close enemies in the game, since the red markers on the compass seem to do just that.
Click to expand...

Scripts that are designated with 'Begin GameMode' are read every cycle when the player is in gamemode (not in pipboy, dialogue, etc.). As far as I know, this means the script is read every frame... however fast that is. This goes for *all* scripts that use gamemode. Imo this is a lousy solution, but it's one bethesda has been using forever.

@vonmistont

Sadly, I am -extremely- doubtful compiled scripts in oblivion would run in fallout 3. Simply because the compiled scripts come in three subrecords. SCTX, the uncompiled 'base' script (that you edit/write)... SCHR, the compiled header portion... and SCDA, the compiled function(s) of the script. Someone needs to crack the compiler routines in order for scripts to be customized. Fortunately, atleast, I am pretty sure there are some folks working on this already.
 
You must log in or register to reply here.
Back
Top