A somewhat obscure error: the stis for faces are numbered as face index.STI. If the face index is < 100, we use 2 digits, otherwise 3. But as that check was on the profile index instead of face index, if you used a profile >= 100 with a face index < 100, the game looked for, say, 051.STI instead of 51.STI, and thus found no file
Fixed in r8569.
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.
Part of the game code is a huge array that stores so called Facts. These are a sort of 'notes', mostly to store quest-related data (Did we give Madlab a video camera? Has Steve heard about us rescuing Joey? Which whores are available?). We use them in the code, in lua
if ( (CheckFact( Facts.FACT_CHALICE_STOLEN, 0 ) == true) ) then
and also in NPC scripts, set in .npc files. The important thing I want to draw attention to is that NPC conversations also set facts. This makes sense when you think about it, most NPCs have some long dialogue over several files that they never repeat. This is achieved by setting a fact.
Unfortunately, these facts set for conversation purposes are not listed inside the code. This is bad if, say, some dashing young coder comes along, codes something which needs a fact, sees in the enum that a number is still 'free' and then uses that number, unaware that some NPC conversation also evaluates that flag or sets it. Possible results range from NPC never says a few lines to I talked to Dimitri, that suddenly triggered all the rebels, and now my team is dead in the rebel basement ten minutes after gamestart.
Luckily this hasn't occured until now, Sirtech avoided that and just didn't list these numbers, the lazy gits. My code additions also don't do that, because I'm lucky awesome.
I've gone over all the stock .npc files in r8570 and added all relevant numbers to the enum in Quests.h. Below are now the known facts:
Q: I am a coder who wants to code new quest stuff. What does this mean for me?
A: Hu. Where have you been all these years, you lazy bastard? Whatever. Don't use the numbers already used in the array above and you're good (and add whatever facts you are introducing).
Q: I am a modder and have added new NPCs or altered existing .npc files in my mods. What does this mean for me?
A: Check whether any of your .npc files (not the one in stock, I've checked those and added what was missing to the above array) for usSetFactTrue (or called sth. similar). If that number is neither 0 nor 65535, check whether that number is in conflict with the above. If it is already in use, move it (not necessary if you replaced the original NPC that set it, duh).
Q: I am a player. What does this mean for me?
A: Nothing, unless the modder of a mod you play tells you otherwise. In case this inexplicably saddens you, here is an owl to distract you.
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.
Messages:384
Registered:December 2017 Location: here
Question arises about the maximum number of such global variables in JA2?
Wiz 8 has a limit of 1000, that was overcome by madgod's dll injected code,
it makes the game read a fact's byte value instead of the simple 00h/01h on/off function,
for npc scripts it means 1 fact allows more fact conditional operations
than all the 193 remaining free slots in Wiz8 npc.dbs did before.
(his code also extended the .dbs limit, but only partially for not_alive_npc)
Additionally a modder desperatly needing more facts
could revamp the vanilla use_only_npcScript facts to free more fact slots for alive npcs.
Btw, whoever worked with madgod's Cosmic Forge Wizardry 6/7/8 Editor
will agree that the ja2 editor is an incompetent tool and modding even merely JA2 content is a mess.
The fact array currently has size 500. But I can simply increase the savegame version, expand that array and add a savegame conversion, as I've done dozens of times. This is no problem.
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 r8571, facial animations are only deactivated if all 4 offsets (both eye and mouth) are 0. Up to now, animations were deactivated if <usEyesY> or <usMouthY> were 0, which isn't really a good enough reason in my book.
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.
Fix: it was possible to create an IMP health < OKLIFE. Not a good idea, as they immediately land in a coma upon arrival.
When setting up autobandage, use first aid kits before using medkits. I always hated the fact that precious medkits were used up before first aid kits.
Fix: using a riot shield in a box fight disqualifies the boxer. Yes, this was possible before
Fix: in rare instances, the face of the first merc hired was replaced with Skyrider. That took a while to find.
Fix: face gear was not shown for non-IMP mercs if their face index wasn't their profile number. Like, say, if one were to use the same face several times on a merc (now why would we do that ? )
Suppression now works in realtime outside of combat. This is both more realistic and is a requirement for a feature I'll pot, say, tomorrow or so.
[Updated on: Mon, 23 July 2018 23:58]
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 discovered a rather annoying bug: It was possible to get the game to freeze when hovering over the savefiles in the save/load screen. This happened only in Release exes, and has me wondering why it doesn't happen all the time... anyway, fixed in r8586.
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.
Small change here (hence why I'm posting it here rather than make a new thread) but I think the wording of the surgery prompt ought to be changed. When I first played I (and likely other newbies) did surgery every time the game asked me and ran out of supplies.
The problem is the wording asks if you want to perform "necessary" surgery, (don't remember if it's only for multiple patients or one patient.) which implies the operation is pretty much mandatory and consequences may result if you decline.
Maybe changing the wording to something like "emergency surgery" or "field surgery" might be less confusing to new players.
Or flat out telling them "This action will rapidly restore health but is extremely inefficient on supplies. Are you sure?"
As mentioned the current wording seems to imply you have to do surgery everytime the game prompts you, when in reality it seems surgery should only be done when you are pressed for time and you need a mercs health restored as quickly as possible. (counterattack on the way, etc.)
Fair enough. I've simply removed the word necessary in r8590, there was some text (on the trait description or so) that already stated it would drain supplies a lot.
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.
Not sure where to post this error, so posting it here, move the post if needed.
This error was found in the latest SCI build from last Wednesday, SCI Revision 8589 on Game Directory 2430. It has probably existed for some time before this build.
In the DifficultySettings.XML file, in the TableData Folder, there is the following inconsistency:
Comments Descriptors say:
ChanceOfEnemyAmbushes : 0- false 1 - true
However, in the actual values in the various Difficulties values that are negative integers ( like -15) and positive integers (like + 5) exist.
Either the Descriptions in Comments are wrong, or we have out of range values in the various difficulties which are doing nothing of value.
Please investigate and correct either the Description Comments or the Values. Thanks.
Note: This seems wrong aka inconsistent in both the Data 1.13 folder and the Data Folder for the Vanilla version.
It's probably a copy+paste error in the description. The "ChanceOfEnemyAmbushes" modifies the chance for ambushes so it can take negative (decrease chance) or positive values (increase chance). Fixed in GameDir 2431.
Fix: death in autoresolve should have always resulted in corpses, but this only rarely happened. Now corpses should always be properly created and randomly dropped all over the maps after autoresolve. Luckily, we've just gotten the tools to clean them up.
Fix: dropped items were cloned when dropping from someone dying in autoresolve. Which is good, because...
... the new JA2_Options.ini setting NPC_AUTORESOLVE_DROP_ALL (default FALSE) allows NPCs (enemies, militia, bandits, creatures...) to drop items in autoresolve like they would in tactical combat. The other drop settings (probability, drop all etc.) still apply.
If one were to point out that items dropping doesn't make a lot of sense if the enemy wins, I point you to the already existing NO_REMOVE_RANDOM_SECTOR_ITEMS. Set that that to FALSE and the AI will steal items whenever it takes a sector, which is what happens if you lose in autoresolve.
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.
Just a note on the Surgery Option. I tend to just Doctor, saving on Medical Supplies and rarely using Surgery. Now, this means I have to click on No, and then click on Yes, almost every single time. This isn't very ergonomic.
It might have been better, for such a rarely used feature, to simply add Surgery to the Dropdown listbox as another choice.
Meanwhile, back at the same ranch, we have now Training, which then gives multiple options once chosen, and Militia, which provides us with 2 more. So in the Surgery situation, we added an annoying extra click, but for the Training ergonomics we broke Militia out of the Training section onto its own part of the main drop down list.
See how the two revisions are philosophically completely 180 degrees out of phase of each other? Not sure if this was the intent. Normally, you don't want to force a mandatory extra click on a very common feature, to choose only Doctor and not Surgery (which is common in the early going to save money or medical supplies). I'd have rather than asked "Just Doctoring, not Surgery for faster/large resource use? Then the user picks Yes, and the second question is skipped , otherwise No would prompt pick Surgery or just skip the second prompt altogether.
Of course, the other side and related issue is that it can be hard to get the cursor to pick the right choice from the rather large dropdown list now for tasks. But it isn't THAT hard.
Eh? Surgery is not an assignment. So it has no business being there. So when else would we set that? I'm not setting up a second 'DOCTOR but without surgery' assignment. What if I want to do surgery on some but not on others? Change assignements all the time? Nah.
I never made that much sense for militia training being lumped together with all the merc stat training stuff to begin with, now at least militia-related things are lumped together.
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.
Well, ok. You could ask the question then so that a Yes simply does Doctoring with no Surgery and has no more prompts, while a No would then do the Surgery as well with no more prompts.
I understand how classification of assignment might be important here. However, to me it is just a drop down list. I personally prefer my suggestion in the sentence above. It is just a suggestion however. Because over the course of a campaign, I will now have to be very careful with that mouse and click at least 100 more times on something. Seems a waste.
And, I don't mean to be a pain, but if you consider Assignments a reason for not changing a droplist, you can see how someone could say Training Militia is Training, etc. Even though I personally agree with you overall for Militia.
I don't think the ergonomic use of a Drop Down list should be overwhelmed by a Assignment Classification. But I can see how that might complicate the coding, adding one non-assignment but sub-assignment type task to the list.
It's up to you, of course. I just find mouse control on that little list and on the yes no choices already difficult enough at 1024x768.
As of r8622, there are no longer any ini settings for IMP slots in the ini. Any empty slot With <Type>6</Type> in MercProfiles.xml is now an IMP slot, and you can have as many of them as you like.
SEND IN THE CLONES!!!!!
Since always, we've differentiated between male and female IMP slots. We've always stated which slots were for males, which were for females, and how many there were for each. Quite a bit of code was also used to this.
Naturally, this is all unnecessary. So as of r8608 & GameDir r2441, I've removed this restriction. The ini settings now look like this:
;------------------------------------------------------------------------------------------------------------------------------
; The following settings allow you to control how many IMPs you can have. For each IMP you need to define a profile slot.
; See Mercprofiles.xml to check which slots are still free.
; The old distinction between male and female slots no longer applies.
; If there are any errors in the following then the default values (3 males slots 51-53 and 3 females
; slots 54-56) will be used instead.
;------------------------------------------------------------------------------------------------------------------------------
MAX_IMP_CHARACTERS = 10
IMP_1 = 51
IMP_2 = 52
IMP_3 = 53
IMP_4 = 54
IMP_5 = 55
IMP_6 = 56
IMP_7 = 169
IMP_8 = 192
IMP_9 = 193
IMP_10 = 194
How many men/women you create is up to you. Note that you can also use the same voice for several people. In releases long gone this wasn't possible, because of non-existing reasons.
It's likely I'll soon alter the GameStart setting too (why do we need to set an artificial restriction on the number of IMPs? If you don't want more IMPs in your campaign, stop creating new ones!). Quite a few settings are nonsensical to only be settable at gamestart (OCTH/NCTH, food system, backgrounds can be switched at any time without leading to any problems...)
[Updated on: Sun, 30 September 2018 23:14]
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.
Fix: hourly drug addiction did not cause proper consumption of drugs
Sounds/SoundsProfiles.xml and all relevant code has been removed. All that stupid xml did was silencing mercs if they didn't have a value set. If you don't want mercs to have sounds, remove those sounds. I see no need for such anal nonsense.
Any rumour that I'd ever add in easter eggs hidden as harmless maintenance is obviously fake news. Chairman Draygan himself said so.
Dynamic ammo weighting (DYNAMIC_AMMO_WEIGHT in JA2_Options.ini) now also applies to food, drugs, canteens and camo kits. I didn't rename the ini setting though, sue 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.
Basically, what happened in code until now was that when we wanted to specify the colour of ammo (for colouring the displayed string), we entered an index. This index referred to a palette entry in an obscure sti library. We then took that palette entry, took its RGB values. We then converted those to unsigend integer, then converted that to unsigned short. We then casted that as signed short. Then we used that colour to display the text.
What I want to do is at least scrap the bizarre 'refer to a value in a palette' nonsense - because this has the annoying sideeffect that we can only use the colours in the palette, while technically any RGB value is useable. It's also, as said, needlessly obscure, whereas 'set values for red/green/blue part of colour' is easier to understant
Anyway, the following tags have been removed from AmmoTypes.xml:
<fontColour>
<grayed>
<offNormal>
<onNormal>
and the following ones have been added:
<red>
<green>
<blue>
which each take a value from 0-255.
Furthermore, the ammmo display in the decription box is coloured...
but as this is a picture, these are the only bullet colours available:
Naturally, that won't do, as you can't see any differences this way. I've thus changed this too, the underlying 'bullet picture' is always the first one, with the colour being similar to the inventory picture:
While I was at it, I noticed that when removing a mag in the description box, the bullet picture colours weren't refreshed, so I fixed that as well.
This has been added to the trunk in r8627 & GameDir r2449. If you use the new without the new AmmoType.xml tags, all ammo colours will look the same. So update your data instead of using a new exe with old data and then complaining they don't fit.
[Updated on: Sat, 06 October 2018 20:54]
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.
The contents of the last 3 posts by Flugente may seem to chronicle only minor fixes, but I really find all of them excellent fixes, and a great way to streamline many leftover oddities. Well done.
As of r8630 you can open doors from the side. I say "open" NOT "inspect", "disarm traps", "smash" or "pick lock" because doing the latter from the side makes no sense. If the door is locked your merc will move to the door and present the door UI as usual.
If your merc is more than 1 tile away he will move to the door and open it. So get in position first and then try to open the door if you don't want your merc to be turned into Swiss cheese...
I have tested this with normal doors, double doors and sliding doors. I don't think we have other types in the game. All doors can be opened from left or right.
Definitely is awesome! I'm still a bit worried it will make things too easy, as is shown by throwing a grenade thru the door in the video above. But it is also realistic.
QUESTION:
Will the enemy A.I. be able to also open doors from the side? Then, I suppose it would be balanced, and dangerous as all heck.
Nope. AI has no means of doing that. On the other hand AI also doesn't know how to blow up walls to "open" a room, which was my preferred method of entering dangerous rooms before.
The grenade method in the video was nice but a poor merc might as well throw that thing on the wall next to the other merc so it's not without risk...
True, I remember it used to be risky when I tried it long ago, probably in Vanilla. Well, I gave them static tanks in patrols and so on, so that is balancing, in my view.
I completely forgot I could blow holes into buildings, even though I carry TNT around all the time. <facepalm>
I am testing in other language versions. Set USE_WINFONTS = 1 in Ja2.ini. This does not work. The color has not changed. The colors are all gray. Is it a bug for Use Winfonts mode?
(test in: English ver svn8633. Chinese ver. svn8641)
@silversurfer found minor issue with door side-opening: you cannot open door if someone occupies a tile in front of it, probably because path check fails. Is it possible to allow door opening in this situation?
Unfortunately no and it doesn't make much sense to me anyway. Most of the time you'd have to reach through someone else or the door would swing through someone else if that someone is in front of the door. If someone is already in front of the door he should open it himself.
I'd agree with SilverSurfer on this as well, for the same basic reasons. If the door opens inward, which some might use as an excuse, I'd say the occupants inside could then block or bar the door, or resist it, changing game mechanics, so let's not use that excuse. And if it is opening outward, it will force the opener, who is in front to either move aside, open the door himself, or be shot thru, all of which are unreasonable.
But, this is part of the player trying to optimize/game the new mechanic, as foreshadowed.
AKA, can we attach a rope to the door, which is then attached to the helicopter, and just force the door open with the helicopter And can we code that as a silent action if the helicopter has the whisper rotor upgrades installed? Pretty please?? tee hee.
Messages:1533
Registered:January 2015 Location: Home Free
Quote:
AKA, can we attach a rope to the door, which is then attached to the helicopter, and just force the door open with the helicopter happy And can we code that as a silent action if the helicopter has the whisper rotor upgrades installed? Pretty please?? tee hee.
Ha! I did try to make it sound interesting. Hey, you never know what Flugente is up to in his Magicka Shop. Now, we just have to decide how much it is influenced by Skyrider's lockpicking, I mean Mechanical Skill. LOL.
So... I kinda had a bit of fun with fire modes and other shenanigans.
r8649: Drug effects on first aid kits can be applied during bandaging. I also new useful merges: Combining 2 rags creates dirty bandages. These work like the first aid kits but are used up much, much faster... and have a chance to infect the patient with diseases (Tetanus and Tubercolosis). Adding alcohol to them produces bandages, which work the same but lack the disease chance.
Given that all you need to produce these are any sort of knife, a bottle of spirit and some corpses, this seems like a sufficiently grim addition to any battlefield
r8650: Merges.xml: <mergeType>15</mergeType> is a merge that reduces the status of <firstItemIndex> by 10 during merging. Thus you spend 10% of a bottle on the above merge.
r8651: If CAN_FAN_THE_HAMMER is set for Gunslingers in Skills_Settings.ini, they can use burst fire if using revolvers with <fBurstOnlyByFanTheHammer> set to 1 and burst data set in Weapons.xml if they are in hipfire mode.
This is demonstrated in the video by Scott - Gunslingers can dump their entire revolver via burst in hipfire. Technically the tag blocks burstfire unless those exact conditions are met, but as I added the burst to revolvers in the first place, it feels more like an addition.
r8652: The new <BarrelConfiguration>-tag in Weapons.xml specifies how many bullets a gun can shoot at once. Valid values from 0 to 256 (though keep in mind the game only supports 1000 bullets in the air at a time, will ya?). If no tag is set, one barrel will be used. Note that this tag can be used several times, as seen by the guns in the video.
The AP cost is the same regardless of number of barrels used. Shooting both barrels of a Baikal costs the same as just one. This should make the Baikal and the sawed-off a lot more useful.
r8653: If DELAYED_GRENADE_EXPLOSION = TRUE in JA2_Options.ini, toggling fire modes on a grenade launcher toggles whether the grenades explode on impact or with a 1-turn delay. Note that for internal reasons this does not apply to gas-effect grenades.
As new icons were added (I'd say they are placeholders, but we all know nobody is going to draw replacements), GameDir >= r2461 is required.
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.
r8653: If DELAYED_GRENADE_EXPLOSION = TRUE in JA2_Options.ini, toggling fire modes on a grenade launcher toggles whether the grenades explode on impact or with a 1-turn delay.
The original idea of this feature was to change the balance of the game, preventing instant killing with grenades/mortars for both player and AI. If we give the player the ability to avoid delayed explosion on launched grenade, this feature becomes pointless and option can be removed.
In Ja2+AI, player has control on delayed mode unless DELAYED_GRENADE_EXPLOSION is set, in which case all grenades use delayed explosion and player cannot control that.
Hu? I thought the intention was to allow to prime grenades by hand if one wants, and this was just to allow both modes for GLs too. Hmmm. Have to think about that then.
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've added a few new things this month. And the thing isn't even over.
r8658: If a gun has a magazine size < 5, the 'out of ammo' soundfile is only displayed with a chance of CHANCE_SAY_ANNOYING_PHRASE (JA2_Options.ini). This should make using guns with tiny magazine sizes less annoying.
r8659: Skinning a bloodcat yields a bloodcat pelt. The status of said fur depends on how messily you murdered the poor thing, and how skilled you are at flaying stuff.
r8660: A new additional dialogue event allows adding voice lines whenever zombies rise, as seen at the end of the video.
GameDir r2466: Molotov cocktails now have an added light effect. This was already present in most mods, not sure why it wasn't in stock.
r8662/GameDir r2467: A paramedic/doctor can fill a bloodbag from a willing, fully-healed, not-knowingly-diseased, non-drugged teammate. These can then be used to boost surgery - in stock the health regained is increased by another 15%. A full bag is used every time you decide to use this option. Which makes things easier for me and is how it is in life.
Because you people would otherwise prey on the civilians like a tabloid preys on dick pics, this only works on your teammates. It also does not work on corpses. Blood donation people are serious about freshness. True fact: they don't appreciate it when you come to the donation station with a clean jam jar full of blood you already took, even if you made sure to wash it hot (with dish liquid and all!).
Anyway, if the person donating the blood has diseases, this will be spread to the patient (though only for disease #0 for now due to coding reasons).
GameDir r2468: I don't know what the people who ages ago filled the starting gear kits where smoking, but given that quite a few doctors have no first aid kits/medkits to speak of... it wasn't that good. Though note that the previous addition of makeshift bandages also eases this problem a bit... Anyway, added first aid kits and empty blood bags to several kits.
r8664/GameDir r2470: Armour and its attachments can have a fire resistance value, which lowers (or increases!) fire damage received. For demonstration purposes I set it to 100% for full EOD armor, which allows Sara to play Targaryen. This won't work with stock values, where I added a 50% resistance to full EOD suits.
[Updated on: Mon, 11 February 2019 00:08]
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.
Not entirely what I was aiming for this evening, but at least somewhat useful, as of r8666, stun effect explosions briefly remove gas effects from any tile they affect.
As the smoke code is... not as accommodating as I had hoped, all smoke deleted will come back the next time it updates, which is every turn. A more 'realistic' smoke effect spreading would require more recoding of that part than I am currently motivated to do.
Still, this does allows us to, say, extinguish fire long enough for mercs to traverse the blast zone, possible to even drag someone else out.
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.
) 1 Vote
Blog
Search
Help
Members
Register
Login
Home
)
we have string . . . 
