MOLLE pouches that fit in large slots don't show the pocket volume value/icon
Filled MOLLE pouches can be attached to a rig which makes them appear empty, and items inside them are "hidden" until the pouch is removed.
Ok, I fixed both issues in r7788.
Attaching MOLLE pockets now works like this:
If there is something inside the pocket already it will be placed into the soldiers inventory. If there is no space it will be dropped to the ground.
I used the same mechanism for detaching MOLLE pockets. If there is something inside the pocket detaching is no longer denied but the content is placed in the soldiers inventory or on the ground. If MOLLE pockets are manipulated in sector inventory contents are always put on the ground instead of the soldiers inventory.
It's not a perfect solution but still better than the old bugs.
In addition to the changes to camo I posted here exe r7791 enables us to see detailed camo info for a merc on the map screen. The info displayed is the same that we can already see on the tactical screen.
As of r7803 and GameDir r2231, we have 2 new ammo properties:
<dDamageModifierLife> alters the life damage a bullet deals. Default 1.0, valid values from 0.0 to 100.0
<dDamageModifierBreath> alters the breath damage a bullet deals. Default 1.0, valid values from 0.0 to 100.0
Note that breath damage and life damage are independent of each other (they are both based on a bullet's impact, an internal value you won't see ingame). So it would is possible to have a bullet that deals no damage to life at all but completely knocks out a target, for example.
To demonstrate this, 12 gauge Rubber slugs have been added. Item pictures have been provided by smeagol - thank you, oh provider of Arts!
Rubber slugs have lowered range and accuraccy and deal higher breath damage than a normal slug would. Their damage, however, is just 30% of what you are used of a shotgun. Might be useful if you want to take prisoners.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
Flugente, would you be so kind to replace the 2 shell picture with a picture of 2 shells? At the moment it is the same picture as the drum box which can be quite confusing.
Hu? Hmm. Perhaps I made a typo somewhere, will check in the evening.
I'd also like to point out that if using an exe >= r7803, I strongly suggest using the new AmmoTypes.xml as well. The reason is that if the xml tags are not present, the game will likely use a default value of 0.0 - which would lead to gun performanece being somewhat, ehem, lacking damage. Simply add those tags to every ammo type and bee done with it. This of course goes for any mod as well. Then again, no modder would ever use a new exe without the appropriate data, right? Riiight?
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
A cosmetic change in r7808: when aiming a weapon in prone stance, this also counts as mounting the weapon. I hereby redefine mounting as weapon is readied and leaning on a physical object, which can be a structure, person or floor. Calculations will not be affected - this is basically visual: whenever M appears on your gun, you get (part of) the prone stance boni.
Simply seems easier to understand to me.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
Mercs roping down from the heli might be a cool animation, but it gets boring fast if one has to watch the entire team doing it. That's why as of r7832 up to 3 mercs can rope down at the same time. Looks a bit like synchronous swimming, but hey, it's faster.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
Pah. Synchronised squads die easily - kill one, the rest die out of team spirit.
Anyway, smeag had a good idea, and I implemented it in r7833:
Anything you'd normally apply on your merc in tactical (canteens, food, drugs, clothes, elixirs...) can now also be applied in strategic. It was always very inconvenient if you wanted to feed 10 mercs and had to give each of them food items, then assign them to a squad, then enter tactical and so on (technically not necessary, as they autofeed, but I know you people like to micromanage everything).
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
Some vanilla mercs (Buzz, Biff, Flo, Haywire, Razor, Bubba) were absolutely incapable of certain conversations. This meant that they could never ever be good at some conversation parts. As a result, even a lvl 10 Flo with maxed out stats everywhere and a higher killcount than Robocop was incapable of threatening, say, a shy puppy. This has been corrected - the mercs can now do these dialouge choices, they are jut very, very bad at it.
Wirecutters no longer give a bonus to disarm, as there is a separate tag for this JMich introduced (wasn't used in stock 1.13 before though). Similar, toolkit, wirecutter, utility knife & KCB knife now have a bonus on disarming bombs. The bonus also depends in their status, it is sufficient to have them somewhere in the inventory.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
A little code bit that will mostly be relevant with Increased teamsizes in r7868: If a sector has less placements (map editor-defined) for militia than militia slots, what happens is that the excess militia simply does not appear in tactical. This can effectively limit you in defense - you might have 64 militia here, but only 32 will show in combat This is only relevant for militia in that sector itself though, not for those that reinforce from adjacent sectors in tactical.
I added a code part that distributes these excess militia to random locations instead of not spawning them, but only up to the minimum of MAX_MILITIA_PER_SECTOR, MAX_NUMBER_MILITIA_IN_TACTICAL and MAX_STRATEGIC_ENEMY_GROUP_SIZE, for compatibility reasons.
All of this wont even be an issue with stock settings (most maps have at least 32 placements) though, so no worries there.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
As of r7872 when a merc tries to blow up, unlock (with a key) or pick a lock he will only unlock that lock and not open the door automatically. This means that you can now unlock a door, end your turn and open the door in the next turn with almost full AP instead of being a sitting duck in the doorway.
Smeag stumbled upon a very weird bug, and it took me a while to fix it (r7873). What happened was that if one of his mercs hit someone, sometimes he then gained an absolutely obscene amount of stats (in this case, he gained 32 DEX and 38 MRK).
The reason is this code part (shortened for clarity):
This might seem harmless - we gain experience depending on how hard the shot was, represented by pBullet->sHitBy - but this is nefarious. sHitBy is INT16, thereby signed. usExpGain is UINT16, thereby unsigned. If sHitBy is negative, which happened here (at the moment I'm not interested what exactly NCTH does there), usExpGain 'rolls over' - here, it became 65535. Which is an obscene amount of experience, which results in this whacky stat gain.
Today's morale: Don't do that, dammit! Unfortunately, I cannot check for this effect in StatChange, as I cannot determine in there whether exactly this happened earlier. I can merely look at all other locations where we can gain stats (which are a lot) and build in safety checks (in this case, only award exp if sHitBy > 0.0).
Hopefully, any other coder reading this can now be aware of this problem and keep his/her eyes open.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
As of r7872 when a merc tries to blow up, unlock (with a key) or pick a lock he will only unlock that lock and not open the door automatically. This means that you can now unlock a door, end your turn and open the door in the next turn with almost full AP instead of being a sitting duck in the doorway.
That sounds really helpful . Is this also active in realtime/non-combat? It might be a bit annoying there, if you always have to open the door after picking the lock.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
As of r7872 when a merc tries to blow up, unlock (with a key) or pick a lock he will only unlock that lock and not open the door automatically. This means that you can now unlock a door, end your turn and open the door in the next turn with almost full AP instead of being a sitting duck in the doorway.
That sounds really helpful . Is this also active in realtime/non-combat? It might be a bit annoying there, if you always have to open the door after picking the lock.
That's a good point. I changed the behaviour in r7874 so the new door opening mechanism is only active during turn-based combat.
A little code bit that will mostly be relevant with Increased teamsizes in r7868: If a sector has less placements (map editor-defined) for militia than militia slots, what happens is that the excess militia simply does not appear in tactical. This can effectively limit you in defense - you might have 64 militia here, but only 32 will show in combat This is only relevant for militia in that sector itself though, not for those that reinforce from adjacent sectors in tactical.
I added a code part that distributes these excess militia to random locations instead of not spawning them, but only up to the minimum of MAX_MILITIA_PER_SECTOR, MAX_NUMBER_MILITIA_IN_TACTICAL and MAX_STRATEGIC_ENEMY_GROUP_SIZE, for compatibility reasons.
All of this wont even be an issue with stock settings (most maps have at least 32 placements) though, so no worries there.
Any chance to get a new exe to use for testing? Seems very useful. I have upped enemy garrison's to 500% of normal and enemy attacks me with usually 50-60 soldiers. Having full militia force to counter this helps.
Stat losses are now displayed in the laptop, just like stat gains.
- Breath regeneration through sleep is now displayed in a tooltip in strategic (in case you wonder how much sleep you require if your merc suffers from hunger, disease and a sleeping bag.
- If NOTIFY_IF_SLEEP_FAILS is set to FALSE, there is no popup box is ordering a merc to sleep fails (default is TRUE). I currently play with ~50 mercs, it is annoying to order them to sleep and cosntantly have that little box pop up .
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
As of r7906 & GameDir r2259, there is a new item tag in Items.xml: mines with <antitankmine> set to 1 will only be activated by vehicles or robots.
I've added the soviet TM-62P2 antitank mine. It is powerful enough to seriously damage or even destroy tank... or, say, an icecream truck. Any human or animal, however, can simply walk over it without ever noticing it.
For added fun, this mine is made with plastic casing and thereby not detectable via metal detectors.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
MAX_BACKPACK_WEIGHT_TO_CLIMB is the maximum weight a backpack can weigh and still allow you to climb with.
; The sBackpackWeightModifier in items.xml can modify that number by either making it harder (positive number modifier)
; or easier (negative number modifier). If the sBackpackWeightToClimb is -1 (default) then the option is unused.
;
; If USE_GLOBAL_BACKPACK_SETTINGS is TRUE (default), it uses the same rules for all backpacks, while if FALSE checks for
; the fAllowClimbing tag in Items.xml, and if that is true you can climb with the backpack.
;
; Both options can be used at the same time, so you may climb with (for example) a malice backpack that weighs less than 5kg
; (or 50 hg) but not climb with a radio set.
Is it possible to add this feature to stable release?I know in ja2_option.ini in stbale release that feature was here but in game it is not worked.on unstable release it work.
1.Serve the public trust
2.Protect the innocent
3.Uphold the law(c)Robocop
The feature was not present in the stable release and nobody is going to back-port features into an old release. You'll have to use the current development build if you want newer features.
Does the stable release became already old vs Development build?
The stable version is older than you think. The gap between stable r7609 and current dev build 7919 might not sound big but feature wise the stable branch is based on r6749 and that is quite a big gap. Recommendation is to use the dev build if you want all the features. I don't think that there will be another "stable" version anyway. It's too much hassle for not much gain.
There are several problems with activating cheats via Ctrl + GABBI:
If one accidentally presses a wrong key, cheats are reset. This is very annoying while debugging keypresses - if Ctrl is stuck and you press one of those buttons, very helpful cheats that are very useful in debugging are deactivated.
This isn't a competitive game. If someone wants to cheat, why not. Why have them jump through the hoop of entering that stupid code all the time?
The cheat activation takes up valuable key combos.
For this reason, as of r7927, pressing [Ctrl] + [g] causes this prompt to activate/deactivate cheats (whatever fits):
If someone would not know that, he' still start by [Ctrl] + [g], so he'll find the prompt anyway.
And no, this is not optional. We won't keep outdated, tedious stuff just for the sake of nostalgia or whatever.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
Google is your friend. I'm not checking the entire code for that.
In other cheat-related news, as of r7928,
Obliterating a sector [Alt] + [o]) will now destroy tanks as well.
Spawning a new enemy via [Alt] + [b] can create tanks.
This should make debugging tank-related issues more tester-friendly.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
In fortification-related news, two issues have been fixed in r7931:
When jumping over fences or sandbags, mercs occasionally jumped into the structure. This was a result of the code being needlessly complicated to achieve... something. This has now been fixed.
Sandbags could only be jumped if their height was < 2. But a structure with a .jsd-size of 1 barely offers protection, thus limiting the usefulness of sandbags. It was also no visual barrier, as pointed out here.
I've changed the code - now sandbags with a height of 2 can also be jumped over. This requires changed jsd files, which have been added to the stock GameDir in r2266.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
Message boxes are very limited. I've added a little expansion in r7935:
This dropdown box is fully functional. We are thus no longer limited to 16 buttons. I have no good example of this in the trunk, but the code is fairly simple. Here's how to create such a message box:
std::vector<std::pair<INT16, STR16> > dropdownvector;
for ( INT16 i = 12; i < 30; ++i )
dropdownvector.push_back( std::make_pair( i, szNationalityText[i] ) );
DropDownTemplate<DROPDOWNNR_MSGBOX>::getInstance( ).SetEntries( dropdownvector );
DropDownTemplate<DROPDOWNNR_MSGBOX>::getInstance( ).SetHelpText( szPMCWebSite[TEXT_PMC_CONTRACT_DROPDOWNTEXT] );
wcscpy( gzUserDefinedButton1, L"Whatever." );
wcscpy( gzUserDefinedButton2, L"Uhm... green?" );
DoMessageBox( MSG_BOX_BASIC_STYLE, L"How do you feel?", GAME_SCREEN, (MSG_BOX_FLAG_GENERIC_TWO_BUTTONS | MSG_BOX_FLAG_DROPDOWN ), YourMessageBoxCallBack, NULL );
Note that MSG_BOX_FLAG_DROPDOWN is flag and can (and should) be used along other flags to create the buttons we want. Once a button is pressed, the box closes. Evaluate it in your callback:
In order for this to work, I had to alter the mouse priorities if the message box region that blocks all callbacks not in the box and the dropdown mouse priorities. In the worst case, this might led to some glitches, though I haven't found any for now.
When you add several rows of buttons, the box might be too small. In true Sirtech style code, the game crashes if that background has a height > 207, because reasons. Will fix if necessary.
[Updated on: Sat, 25 July 2015 20:29]
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
I have an idea for a use, Flugente.
Create a cheat that allows you to spawn an item using the dropdown menu? as in being able to scroll through weapon names and pick which rifle you want to spawn, etc
I imagine that especially with wil's mods there'll be some spaces between items, so some limitation will be needed. Definitely would be faster than having to alt-tab and look up values in the xml editor though
You mean as an alternative for [Alt] + [.]? Even with stock data that would be way to time-consuming, scrolling through 1.7k items, let alone in mods.
I know now that it could never work between us, as much as we wanted to, it could never be! Not because you're a rabbit, but because you're black.
If you want, you can donate to me. This will not affect how and what I code, and I will not code specific features in return. I will be thankful though.
Why implement a search feature that is already there? Just open Items.xml in any text editor and search for whatever you want. I would rather have Flugente spend his time on useful stuff than polishing cheats.
...
This might seem harmless - we gain experience depending on how hard the shot was, represented by pBullet->sHitBy - but this is nefarious. sHitBy is INT16, thereby signed. usExpGain is UINT16, thereby unsigned. If sHitBy is negative, which happened here (at the moment I'm not interested what exactly NCTH does there), usExpGain 'rolls over' - here, it became 65535. Which is an obscene amount of experience, which results in this whacky stat gain.
...
I'd like to clean up the warnings in the code like this one. What's the best way to go about getting that integrated? Zip file or request repo access?
7-year C++ professional. With maybe a touch of OCD for stuff like that.
I'd like to clean up the warnings in the code like this one. What's the best way to go about getting that integrated? Zip file or request repo access?
7-year C++ professional. With maybe a touch of OCD for stuff like that.
Best way is to create a patch for the latest code and drop a message to user RoWa21. He can apply it to the repository.
) 1 Vote
Blog
Search
Help
Members
Register
Login
Home
This is only relevant for militia in that sector itself though, not for those that reinforce from adjacent sectors in tactical.
. Is this also active in realtime/non-combat? It might be a bit annoying there, if you always have to open the door after picking the lock.
.
