Home » MODDING HQ 1.13 » Flugente's Magika Workshop » Absurdly small code changes  () 1 Vote
Re: Absurdly small code changes[message #353694 is a reply to message #353657] Wed, 06 June 2018 00:00 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
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 Bang head

Fixed in r8569.



"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #353722 is a reply to message #353694] Sat, 09 June 2018 22:44 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
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
Toggle Spoiler

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:

Toggle Spoiler


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.

[Updated on: Sun, 10 June 2018 10:29]




"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #353724 is a reply to message #353722] Sun, 10 June 2018 11:19 Go to previous messageGo to next message
townltu

 
Messages:306
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.
Re: Absurdly small code changes[message #353725 is a reply to message #353724] Sun, 10 June 2018 12:48 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
Eh... what? I didn't get half of that tbh.

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.



"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #353747 is a reply to message #353725] Mon, 11 June 2018 21:18 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
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.



"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #353748 is a reply to message #316795] Mon, 11 June 2018 21:19 Go to previous messageGo to next message
sob1

 
Messages:12
Registered:June 2018
the logic strikes again! big grin

(I have to post a few inane messages before I can share my new IMP and other contribs in a Magika WS thread)



Dr. Phil as a playable comedy IMP: http://thepit.ja-galaxy-forum.com/index.php?t=msg&goto=353751&#msg_353751

Lawrence of Arabia as an IMP:

http://thepit.ja-galaxy-forum.com/index.php?t=msg&goto=353801&#msg_353801
Re: Absurdly small code changes[message #353749 is a reply to message #313946] Mon, 11 June 2018 21:20 Go to previous messageGo to next message
sob1

 
Messages:12
Registered:June 2018
Very interesting implications for crew-served weapons!



Dr. Phil as a playable comedy IMP: http://thepit.ja-galaxy-forum.com/index.php?t=msg&goto=353751&#msg_353751

Lawrence of Arabia as an IMP:

http://thepit.ja-galaxy-forum.com/index.php?t=msg&goto=353801&#msg_353801
Re: Absurdly small code changes[message #354122 is a reply to message #353749] Mon, 23 July 2018 00:24 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
Several things happened up to, say, r8577:

  • 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 big grin
  • 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 ? cheeky )
  • 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]




"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #354140 is a reply to message #354122] Tue, 24 July 2018 23:51 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
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.



"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #354199 is a reply to message #354140] Tue, 31 July 2018 23:03 Go to previous messageGo to next message
Toybasher

 
Messages:19
Registered:April 2018
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.)
Re: Absurdly small code changes[message #354202 is a reply to message #354199] Wed, 01 August 2018 22:22 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
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.



"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #354215 is a reply to message #354202] Sat, 04 August 2018 20:16 Go to previous messageGo to next message
ZedJA2

 
Messages:143
Registered:January 2018
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.

[Updated on: Sat, 04 August 2018 21:04]

Re: Absurdly small code changes[message #354216 is a reply to message #354215] Sat, 04 August 2018 21:51 Go to previous messageGo to next message
silversurfer

 
Messages:2462
Registered:May 2009
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.



Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Re: Absurdly small code changes[message #354217 is a reply to message #354216] Sat, 04 August 2018 22:39 Go to previous messageGo to next message
ZedJA2

 
Messages:143
Registered:January 2018
@ SilverSurfer

Thanks for info and the fix.
Re: Absurdly small code changes[message #354382 is a reply to message #354217] Wed, 15 August 2018 22:41 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
Minor new stuff (up to r8595):
  • 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.



"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #354551 is a reply to message #354382] Mon, 27 August 2018 04:05 Go to previous messageGo to next message
ZedJA2

 
Messages:143
Registered:January 2018
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.

[Updated on: Mon, 27 August 2018 04:06]

Re: Absurdly small code changes[message #354573 is a reply to message #354551] Wed, 29 August 2018 00:32 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
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.



"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #354589 is a reply to message #354573] Wed, 29 August 2018 23:26 Go to previous messageGo to next message
ZedJA2

 
Messages:143
Registered:January 2018
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.

[Updated on: Wed, 29 August 2018 23:28]

Re: Absurdly small code changes[message #354625 is a reply to message #354589] Sat, 01 September 2018 00:46 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
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.
https://i.imgur.com/i7GTrcX.png
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]




"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #355193 is a reply to message #354625] Sun, 30 September 2018 23:20 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
Changes of minor interest up to r8626:
  • 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.



"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #355255 is a reply to message #355193] Sat, 06 October 2018 20:47 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
As indicated elsewhere, I'm altering the way we set colours on ammotypes.

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...
https://i.imgur.com/dF83IKI.png
but as this is a picture, these are the only bullet colours available:
https://i.imgur.com/0pRMkVy.png
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:
https://i.imgur.com/kGH8OX6.png

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]




"Is there any way to get the blood to flow up the walls?"
"I don't see why not."

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.


Re: Absurdly small code changes[message #355373 is a reply to message #355255] Sun, 21 October 2018 09:38 Go to previous messageGo to next message
ZedJA2

 
Messages:143
Registered:January 2018
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.
Re: Absurdly small code changes[message #355533 is a reply to message #355373] Tue, 30 October 2018 17:07 Go to previous messageGo to next message
silversurfer

 
Messages:2462
Registered:May 2009
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.



Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Re: Absurdly small code changes[message #355546 is a reply to message #355533] Wed, 31 October 2018 17:37 Go to previous messageGo to next message
sevenfm

 
Messages:1731
Registered:December 2012
Location: Soviet Russia
Made a small demo video showing how door side opening works:


@silversurfer is it possible to use diagonal 'give' animation to open door? It would look much better i think.



7609+fix | 7609+AI (r847) | 7609 unofficial modpack | Win8+ fix | Experimental project | Vengeance:Reloaded | Youtube

"It's already "dog-eat-dog", friend. Not sure what worse a bunch of zombies could do."


Re: Absurdly small code changes[message #355547 is a reply to message #355546] Wed, 31 October 2018 19:01 Go to previous messageGo to next message
silversurfer

 
Messages:2462
Registered:May 2009
sevenfm wrote on Wed, 31 October 2018 16:37

@silversurfer is it possible to use diagonal 'give' animation to open door? It would look much better i think.

Yes we can! I improved the code in r8633.

Btw. you are right. It does look MUCH better. happy

[Updated on: Wed, 31 October 2018 19:02]




Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Re: Absurdly small code changes[message #355549 is a reply to message #313897] Wed, 31 October 2018 21:27 Go to previous messageGo to next message
crackwise

 
Messages:46
Registered:April 2013
Wow, this is awesome! It will definitely improve gameplay for clearing rooms!
Re: Absurdly small code changes[message #355551 is a reply to message #355549] Wed, 31 October 2018 21:42 Go to previous messageGo to next message
ZedJA2

 
Messages:143
Registered:January 2018
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.
Re: Absurdly small code changes[message #355553 is a reply to message #355551] Wed, 31 October 2018 22:57 Go to previous messageGo to next message
silversurfer

 
Messages:2462
Registered:May 2009
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...



Wildfire Maps Mod 6.07 on SVN: https://ja2svn.mooo.com/source/ja2/branches/Wanne/JA2%201.13%20Wildfire%206.06%20-%20Maps%20MOD

Re: Absurdly small code changes[message #355556 is a reply to message #355553] Thu, 01 November 2018 01:38 Go to previous message
ZedJA2

 
Messages:143
Registered:January 2018
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>
Previous Topic: Ongoing redesign: start options/ini/ingame options
Next Topic: New Feature: IMP gear selection
Goto Forum:
  


Current Time: Sat Nov 17 10:57:46 EET 2018

Total time taken to generate the page: 0.02960 seconds