Home » MODDING HQ 1.13 » Flugente's Magika Workshop » Absurdly small code changes  () 1 Vote
Absurdly small code changes[message #313897] Fri, 04 January 2013 22:49 Go to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
I feel a few code changes are too small to justify their own thread, but still need to be posted somewhere, as they otherwise get forgotten until people shout 'BUG!!!' a few years later. So I'll pin them up here.

First entry (Exe r5763 &GameDir 1583): the option NO_STANDING_ANIM_ADJUSTMENT_IN_COMBAT in the ini allows the following small change:

If we are in turnbased combat and are moving to a location, we do not change our animation to standing/crouching/prone. This way, we do not have to spend additional APs if we get moving again. This is similar to what happens if we are interrupted while running; we can simply 'pick off' where we left.
This allows the player to move in smaller sections, for example, if we want to move a long way but the game pathing is not to our liking.

[Updated on: Fri, 04 January 2013 22:51] by Moderator



Re: Absurdly small code changes[message #313902] Sat, 05 January 2013 01:18 Go to previous messageGo to next message
Uriens

 
Messages:330
Registered:July 2006
Yessss, thanks. I really hated how you have to either waste AP's on bad pathfinding that goes where you don't want it to go or to go step by step and take AP penalty for moving-stopping-moving-stopping. This fixes.

Thank you. Very Happy
Re: Absurdly small code changes[message #313916] Sat, 05 January 2013 16:21 Go to previous messageGo to next message
Sam Hotte

 
Messages:2020
Registered:March 2009
Location: Middle of Germany
:super:
Re: Absurdly small code changes[message #313946] Sun, 06 January 2013 05:16 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
Another feature, that most people wont even notice, because it is so small, are the new multi-turn actions. It is basically a system that allows a coder to set an action to be performed over multiple turns. Once you start the action, a few APs are deducted, a small icon signifies that the emrc is now performing an multi-turn action. He can still do anything as usual, but:
At the end of the turn, we look at his remaining APs. If has any left, we deduct these from the total AP cost of the action he is performing. Once he ha fully paid the cost, the action will be finished. If he is not able to do the action, it is cancelled, but we do not regain any spent APs for it.

As a demonstration, building/removing/filling sandbags is now a multi-turn action.
http://i48.tinypic.com/s2h8hy.jpg
Boss demonstrates mulit-turn actions. He begins building a sandbag barricade, but continues to fire at enemies. At the end of the turn, he has switched position, but is still facing the same tile on which he originally started building. After a few turns, he is finished, the sandbag barrier stands.

Had he not looked at the same tile at the end of his turn, or had he not had a sandbag in his main hand, or had the tile been occupied, he would have stopped building (a message will appear in that case).

If in realtime and not in combat, actions are still performed instantly. No need to wait 15 seconds for building a sandbag there.

It was previously criticized that building sandbags is too fast, thus giving an unfair advantage to the player. With this feature, building takes multiple turns (governed by the AP cost in APBPConstants.ini). So you can now build sandbags in turnbased mode, but it will keep you occupied for several turns. You can still defend yourself, but you must return to the building site every turn.

This feature was added to th trunk in r5778 and requires GameDir of revision >= 1589 (due to the added constants and the icon). It is a new savegame version but does NOT break savegame compatibility.


Re: Absurdly small code changes[message #313947] Sun, 06 January 2013 06:15 Go to previous messageGo to next message
Slax

 
Messages:1448
Registered:July 2006
Location: People riding polar bears...
Multi-turn actions! :mail: Get weapon reloading in on this and I'll be a happy chappy. Smile
How is suppression/cowering and taking damage handled in all of this? I imagine any small thing cancels the action?

Re: Absurdly small code changes[message #313956] Sun, 06 January 2013 15:44 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
The action gets cancelled prematurely if you either start a new multi-tunr action, or if you cannot continue the action at the end of your turn. This happens when you're looking at a different tile than the one you started the action on, are in the wrong stance, or do not have the necessary items in your hands.


Re: Absurdly small code changes[message #313959] Sun, 06 January 2013 18:42 Go to previous messageGo to next message
Sam Hotte

 
Messages:2020
Registered:March 2009
Location: Middle of Germany
Any chance you could extent this onto reading a weapon? Like the mortar had a 'time to ready' of more than 120 APs so that setting it up to fire (or change direction of fire) would need at least 2 turns to accomplish?
Re: Absurdly small code changes[message #313961] Sun, 06 January 2013 19:20 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
The current mortars have no 'readying'. You look into a direction and fire, there is no setting up involved, apart from crouching and looking into the general direction of the target. So this feature does not apply to this, as the firing action itself should be instantly.


Re: Absurdly small code changes[message #313962] Sun, 06 January 2013 19:38 Go to previous messageGo to next message
Sam Hotte

 
Messages:2020
Registered:March 2009
Location: Middle of Germany
But we could easily add a ready time to mortars like any other weapon, couldn't we?

Edit: I'm aware that we also should have a proper animation then for this. i'm just talking theory currently; trying to understand how things work (or don't).

Edit

[Updated on: Sun, 06 January 2013 19:48] by Moderator

Re: Absurdly small code changes[message #313963] Sun, 06 January 2013 19:45 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
We could an extra cost that has to paid prior to firing, yes. But using this for ready times is pretty pointless, as one of the major points behind this feature is the possibility to perform actions while performing another action. Readying a weapon means preparing it for a firing position, and moving cancels that.


Re: Absurdly small code changes[message #313964] Sun, 06 January 2013 19:56 Go to previous messageGo to next message
Sam Hotte

 
Messages:2020
Registered:March 2009
Location: Middle of Germany
So it's not about "multi-turn actions" but rather about "pick up previous task after doing something else"?

Anyway, couldn't the code part that allows for stretching this "previous task" over multiple turns also be apllied to "firing a gun" so that we could come to the point in the future of having somehow more realistic simulation of heavy weapons?
That's what i was after by example of the mortar, if you get me.
Re: Absurdly small code changes[message #313965] Sun, 06 January 2013 19:59 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
Ah, now I get your intention. Yes that would be pretty easy actually for weapons that target a tile and not a person. Though a bit odd, as you'd only fire if you've accumulated enough APs. So if you are not planning careful, you might shoot later than you originally intended if you spend too much APs on other stuff.

[Updated on: Sun, 06 January 2013 20:00] by Moderator



Re: Absurdly small code changes[message #313966] Sun, 06 January 2013 20:08 Go to previous messageGo to next message
Sam Hotte

 
Messages:2020
Registered:March 2009
Location: Middle of Germany
My point is not about spending APs on other stuff while readying e.g. the mortar (but i wouldn't mind this ability as a bonus on top).
My vision is that i start setting up the mortar (or any other BFG Wink ) in turn N by means of the L-key. This consumes more than 100 APs so that it stretches into next turn until mortar is ready to fire first shell.
(Bonus vision: as launching the shell also consumes lot of APs, firing then also can be started in turn N+1 (after mortar is finally readied) and streches into turn N+2).

If you still consider this as "would be pretty easy" then i hereby would like to make this a formal "feature request". Smile

Re: Absurdly small code changes[message #313969] Sun, 06 January 2013 21:53 Go to previous messageGo to next message
Uriens

 
Messages:330
Registered:July 2006
I'd like to see that also. I just hope AI will know how to deal with the change.
Re: Absurdly small code changes[message #313974] Mon, 07 January 2013 07:19 Go to previous messageGo to next message
Maalstroom

 
Messages:343
Registered:December 2008
Location: en route to San Hermanos
I would like to see the same thing for sniper rifles. For a really long shot you need some time to prepare. For example aiming with an OSV with a ballistic computer attached to shot something over a mile away needs some time. Should take more than a turn for all the the sniper rifles.
Re: Absurdly small code changes[message #313984] Mon, 07 January 2013 19:17 Go to previous messageGo to next message
lockie

 
Messages:3929
Registered:February 2006
Location: Scotland
Quote:
Should take more than a turn for all the the sniper rifles.


And by then the target will have moved , making this redundant ?


Re: Absurdly small code changes[message #313986] Mon, 07 January 2013 20:22 Go to previous messageGo to next message
Maalstroom

 
Messages:343
Registered:December 2008
Location: en route to San Hermanos
snipers watch their targets while they move, paying attention to their behavior. "one shot one kill" doesn't come easy and yes, snipers kill moving targets also, that's what makes them so special.
Re: Absurdly small code changes[message #314189] Sat, 12 January 2013 23:15 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
The AI is not able to handle this change. Making it do so would be rather severe, as this would require the AI to return to a certain gridno every turn. Which would be very very hard to do.

When you aim with a sniper rifle, it would be illogical to do be able to do sth else, like switching your stance, wouldn't it?

If you want longer aiming time, you could simply increase the draw cost. Theoretically one could raise the cost and also reduce the APs of the next turn... but that would be rather bad, as then there would be now way to stop aiming. If our draw/aim AP cost is > 100 APs, and we are able to deduct from next turn's APs, we could screw ourself and block our entire next turn. Not advisable.


Re: Absurdly small code changes[message #314430] Sun, 20 January 2013 06:02 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
IoP has improved very old item spawn code of mine. To quote r5794: Quote:
code improvement: added a much easier way to add items in cheat mode. 'ALT' + '.' allows the user to input the item number he wants and spawns the item on the selected merc. 'CTRL' + 'ALT' + '.' spawns the previously selected item. (by IoP)
This should be quite handy to anyone testing anything anywhere in regard of items - just press and enter the number of the item you want, and it spawns in the inventory of your currently selected merc, or on the floor. Of course, you need to have cheats active for this.


Re: Absurdly small code changes[message #314431] Sun, 20 January 2013 06:10 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
I've improved the dialogue system a bit. As a result, it is now easier to rename buttons. I worked on a few dialogues, thus we can now have this (r5795):
http://i47.tinypic.com/2jf0x1s.jpg
This should make it easier to understand what a button does Wink


Re: Absurdly small code changes[message #314438] Sun, 20 January 2013 14:09 Go to previous messageGo to next message
mr_clark

 
Messages:46
Registered:December 2011
Location: Potsdam, Germany
Heh, I need a "Take off clothes" Button in real life Wink

Looks very good, though!
Re: Absurdly small code changes[message #315744] Mon, 25 February 2013 23:19 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
As I am currently not in the mood for something relevant, I just added externalised squad names to the trunk (my mod will take some time, thus I'll not release it with that):
http://i45.tinypic.com/4u787p.jpg
The new xml SquadNames.xml will be needed from now on. You can define your squad names in there. Any length you want, but only the first 9 letters will be shown. These names will be used if USE_XML_SQUADNAMES = TRUE.

The xml has slots for 20 names - as there can only be 20 different combat squads at any given time. As this was no problem in the 14 years up to now, it won't be a problem now.

The necessary revisions are 5872 and GameDir r1608.

Did not test this for Robbie Tables.

I also moved Pockets.xml and PocketPopups.xml from Inventory to Items, as this makes much more sense. Thus any mod with GameDir >= 1608 will need an exe of r >= 5872!


Re: Absurdly small code changes[message #315748] Tue, 26 February 2013 00:58 Go to previous messageGo to next message
Uriens

 
Messages:330
Registered:July 2006
Thanks for changes.

Don't forget that xml editor will need update to reflect file changes.

Re: Absurdly small code changes[message #315981] Tue, 05 March 2013 22:31 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
Something truly, truly ancient today. :professor: I found a piece of code that I believe was implemented by SIRTECH themselves, they just never turned it on it seems. When a building is damaged by someone with explosives, this causes loyalty penalties. A big one for the team that caused the damage, a smaller one for the current owners of the sector, who didn't stop this.

This means if you decide to blow an alternate entry into buildings when preparing for an attack, the building's owner is getting pissed.

This is added in r5899.

Damn, they thought of everything back then. :bunny:


Re: Absurdly small code changes[message #315987] Tue, 05 March 2013 23:38 Go to previous messageGo to next message
Hazapuza

 
Messages:263
Registered:February 2009
Location: Finland
Does loyalty have some kind of effect on Deidranna's regime? Do they receive fewer troops/slower reinforcements? Or does this simply imply that there was supposed to be a more complicated loyalty system in place? Just asking, I always thought loyalty was there just for the player to worry about.

Anyhow, nice work. Smile

[Updated on: Tue, 05 March 2013 23:38] by Moderator

Re: Absurdly small code changes[message #315988] Tue, 05 March 2013 23:46 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
Well, any kind damage to the enemies town loyalty directly translates in a gain for the player - no hidden system there.


Re: Absurdly small code changes[message #315989] Wed, 06 March 2013 01:34 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
I upgraded weapon switching (r5900):

new key combinations:
- SHIFT + K: switch to and from riflesling
- SHIFT + K + ALT: switch to knife, or from knife to gun
- SHIFT + K + CTRL: switch to sidearm, or from sidearm to non-sidearm gun
the switches will search for a valid spot for the replaced hand items, thus a LAW won't go into a holster etc.


The functions are mildly intelligent. If you have an AR in your hand and give the command to switch to your knife, the AR will be moved to the first slot in your inventory hat can take the AR. This will not work, of course, if no slot is found. This also does not retrieve guns/knives from stacks.

Sidearms in this context are all guns of the HANDGUNCLASS (1 in Weapons.xml).

Note that sidearms are not automatically stored in holsters, as there is no easy way to tell if a slot is in a holster or a vest. Okay, there actually is, but this is pointless since we have vest with holsters and whatnot nowadays. They are simply placed in the first free slot.

Knifes, however, will always be put back to the knifeslot if its empty and they fit - because that slot is not governed by LBE and comes pretty early in the slot loop.


Re: Absurdly small code changes[message #316135] Sun, 10 March 2013 16:17 Go to previous messageGo to next message
merc05

 
Messages:78
Registered:January 2013
I was testing this new loyalty based on building damage system and whenever I cause an explosion inside a building on a map that is not a part of any town I get an assingment error. Anyone else is experiencing this?
Re: Absurdly small code changes[message #316136] Sun, 10 March 2013 16:22 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
This was fixed in 5909 and again in 5916.

[Updated on: Sun, 10 March 2013 16:26] by Moderator



Re: Absurdly small code changes[message #316699] Fri, 29 March 2013 00:04 Go to previous messageGo to next message
wsmithjr2013

 
Messages:50
Registered:March 2013
Location: New Jersey
Flugente
First entry (Exe r5763 &GameDir 1583): the option NO_STANDING_ANIM_ADJUSTMENT_IN_COMBAT in the ini allows the following small change:

If we are in turnbased combat and are moving to a location, we do not change our animation to standing/crouching/prone. This way, we do not have to spend additional APs if we get moving again. This is similar to what happens if we are interrupted while running; we can simply 'pick off' where we left.
This allows the player to move in smaller sections, for example, if we want to move a long way but the game pathing is not to our liking.


Don't know if I found a bug or maybe a known side-effect to this option. I've found that when a merc is in this motion stance, you can not give items to them. A merc can *give* an item to a standing merc, but if the target merc is in motion, you can't transfer the item even if both mercs have plenty of AP available.

I've seen this with exe 5945. It's not a huge deal but can be annoying. Being able to tell the merc to "stand still" without doing something else that uses APs such as turning would help but I'm not aware of how to do that.

Thanks for any help.
Re: Absurdly small code changes[message #316703] Fri, 29 March 2013 02:02 Go to previous messageGo to next message
Sam Hotte

 
Messages:2020
Registered:March 2009
Location: Middle of Germany
Not sure, but you could try if hitting the corresponding stance's key might work. E.g. if the merc is "frozen" in running mode, hit 'S' to make him stand (shouldn't cost you APs, but you will have to pay the initial cost of "start running" if you move on afterwards).
Re: Absurdly small code changes[message #316746] Fri, 29 March 2013 23:15 Go to previous messageGo to next message
wsmithjr2013

 
Messages:50
Registered:March 2013
Location: New Jersey
Sam_Hotte
Not sure, but you could try if hitting the corresponding stance's key might work. E.g. if the merc is "frozen" in running mode, hit 'S' to make him stand (shouldn't cost you APs, but you will have to pay the initial cost of "start running" if you move on afterwards).


Thanks. Unfortunately, unless you do something to spend APs, that doesn't work. Pressing "S" while in motion doesn't do anything. I'll look for the bug report thread and post there.
Re: Absurdly small code changes[message #316749] Fri, 29 March 2013 23:38 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
That is an unfortunate sideeffect. We were never able to give an item to someone who is in a moving animation - which was no problem till now as we barely ever had the chance to try.

The corresponding checks are... nested in a way that makes changing this relatively hard. The reason is that handles generally clicking on persons, and I'd rather not mess with this.

As a workaround, you have to either switch stance, look in another direction, or switch weapons in your hands (changes anim if you have a rifle, and does not cost APs if you do it by rightclicking on the roster).

[Updated on: Fri, 29 March 2013 23:39] by Moderator



Re: Absurdly small code changes[message #316774] Sat, 30 March 2013 12:21 Go to previous messageGo to next message
Parkan

 
Messages:451
Registered:April 2010
Location: Russia,Sevastopol

I don't know is possible to add few features in game like this:

Quote:
Enhanced Close Combat System

This option generally improves many things around the game's close combat system, like:

* HtH hit to head deal more damage but has lesser chance to hit.
* HtH hit to legs do half damage but has much better chance to hit.
* HtH damage on lying enemies increased.
* HtH damage on surprising attacks(from behind, when enemy didn't seen or heard the merc) is increased.
* Aimed HtH attack cost less APs. If you have MA or HtH trait, this is converted into "focused punch" - martial artists
perform their spinning kick then.
* Attributes used for HtH attacks or stealing slightly tweaked.
* Experience recieved for certain actions in close combat tweaked to be more logiacal (gain agility for dodging etc..)
* Stealing all items is now possible only when the enemy is knocked down. The APs you need to steal items are now
based on number of items you want to take. The standard APs for pickup item are charged for every item you selected to
take. If you select more items to take from the enemy than you have APs for, the rest will remain with the enemy and a
message occures that you haven't taken all you wanted.


Can you made stealing all item from unconcius character an optional option?I think it not a quite good thing for game balance.If i turn off this option i losing some effects from this system like :"* Experience recieved for certain actions in close combat tweaked to be more logiacal (gain agility for dodging etc..)"because not all players move in tactical combat in stealth mode near enemy to improve agility.


Plus one question:It is possible to externalised the enemy gun modifier?(admins,regular,elites)?I think elites with their +5 modifier ruin game item balance

[Updated on: Sat, 30 March 2013 12:26] by Moderator

Re: Absurdly small code changes[message #316781] Sat, 30 March 2013 14:38 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
Why the need to add an extra setting disallowing to steal all items? Simply don't steal then.

Yes, those values could be externalised.


Re: Absurdly small code changes[message #316784] Sat, 30 March 2013 14:44 Go to previous messageGo to next message
Parkan

 
Messages:451
Registered:April 2010
Location: Russia,Sevastopol

Flugente
Why the need to add an extra setting disallowing to steal all items? Simply don't steal then.

Yes, those values could be externalised.


It may be simple,but the PRIZEEE!! =)It very tempting to not steal items from enemy who stand near to your merc.So,if it is not so be difficult to separate those options?If difficult or it wasting time-forget what i say. Razz

[Updated on: Sat, 30 March 2013 14:53] by Moderator

Re: Absurdly small code changes[message #316795] Sat, 30 March 2013 17:13 Go to previous messageGo to next message
Gambigobilla

 
Messages:718
Registered:July 2008
It's single player game so roleplaying fixes many glitches. Pretend its already coded.

@Flugente,

If it's not too much work, could you please make it so we can steal items from "dying" enemies.
Re: Absurdly small code changes[message #316988] Wed, 03 April 2013 20:05 Go to previous messageGo to next message
Istrebitel

 
Messages:222
Registered:December 2009
Location: Russia, Saint-Petersburg
Unfortunately, the very much needed function of hotkey-swap of main weapon to sidearm or knife doesn't really work.

Most usual scenario is you have a gun in a hand, another gun in your sling slot, and a knife in your knife slot. In this scenario, using SHIFT + K + ALT puts your gun from your hand into your free large pocket (usually the backpack) and then using it again puts your gun from your sling into your hand. Thus you can no longer switch guns via SHIFT + K.

I suggest to change the "intelligence" of the swap system so that it prioritizes weapons in other locations over weapon in the sling when swapping back from knife to a gun.
Re: Absurdly small code changes[message #316992] Wed, 03 April 2013 21:24 Go to previous messageGo to next message
Flugente

 
Messages:3416
Registered:April 2009
Location: Germany
I don't see it that way. The rifle sling is the logical position for a gun you want to draw quickly, thus it will be checked first. Think about it: if you have a rifle on your sling, and one stored in your backpack, and you need to quickly draw one - which would you choose?


Re: Absurdly small code changes[message #316998] Wed, 03 April 2013 22:08 Go to previous messageGo to previous message
Istrebitel

 
Messages:222
Registered:December 2009
Location: Russia, Saint-Petersburg
This is logical, I agree, but however logical it is, it is useless right now.

It is as logical as a famous (at least in Russia) joke (I hope I translated it correctly, because I couldn't find it's version in english by googling):

Sherlock Holmes and Dr. Watson are flying in a hot air balloon. They got lost and don't know where they are because of a dense fog. Suddenly they were floating near a skyscrapper which had an open window with a man sitting inside. Holmes asks the man:
- "Sir, could you please tell me where we are?"
- "Of course, sir, you are in a hot air balloon!" - the man answered.
After parting with the man, Holmes tells Watson:
- "I know for sure Watson that this man was a programmer".
- "How could you know that, Holmes?" - asks Watson.
- "He gave us an absolutely correct, but at the same time an absolutely useless answer".

Basically, this is useless, because in order to use SHIFT+ALT+K, I have to forget about using SHIFT+K, which makes no sense (and forget about using my rifle sling slot, which also makes no sense).

Therefore, please consider the following logic:

If we have more than one large gun in our inventory, as a sane individual, we would most likely place one of them in the rifle sling slot, because that slot can only hold an item of this type (and a machete, I belive, as a unique exclusion from this rule).
In this case, if we use SHIFT+ALT+K command to take a knife out, where would the weapon we had in our hand go? It cannot go to the sling, therefore it goes into our inventory (combat pack, or if no slots are there, big backpack).
This means that if we use SHIFT+ALT+K command to place the knife back, where should we look for a weapon we previously had in our hand? Not on the sling, but in the inventory.

Therefore, logic for SHIFT+ALT+K command in case we have a knife in our hand should be like this:
- if we have one big weapon in the inventory, start from the sling slot and then go on to the rest of the inventory
- if we have more than one big weapon in the inventory, then start with inventory and check sling slot last

However, since if we have only one weapon in the inventory, it doesn't matter in which order do we look - we will still find the same item.

Therefore, it is more logical to start with inventory and check the sling LAST.

[Updated on: Wed, 03 April 2013 22:10] by Moderator

Previous Topic: New feature: combat jeeps
Goto Forum:
  


Current Time: Wed Oct 24 06:05:48 EEST 2018

Total time taken to generate the page: 0.02662 seconds