Home » MODDING HQ 1.13 » Flugente's Magika Workshop » Absurdly small code changes
() 1 Vote
|
|
|
|
|
Re: Absurdly small code changes[message #344802 is a reply to message #344799]
|
Tue, 29 March 2016 20:37
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
Currently, C-18 is worse than Jelly in every regard, with these changes, it beats it in pure protection (but still loses everywhere else).
These penalties are for the 100AP system (I am not completely sure whether the game reads these as percentages and correctly adjusts to the 25AP system, have to check).
I really like CVB's idea of a tunnel vision penalty (a very small one, no worries). I could lower the Aim penalty on helmets in general and add a tunnel vision instead.
I am not that satisfied about the pants too. There aren't that many penalties to play with down there, AP & stealth being logical, aim not so much. Hmm. I could lower aim penalties and play a bit with weight and coverage.
At least from the current description, the Field Uniform is almost a copy of the Zylon stuff. But edmortimer's idea is better - make it non-armoured (or very, very low armoured), camoed, light-weight and allow plate inserts. Then change it to very low coolness. That way one has to get a plate to make it worthwhile, and it would compete with Flak Jacket and Kevlar vest by having no penalties whatsoever.
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.Report message to a moderator
|
|
|
|
|
|
Re: Absurdly small code changes[message #344846 is a reply to message #344806]
|
Sun, 03 April 2016 19:41
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
While testing tunnel vision values a bit, I discovered that tunnel vision penalties are applied rather broad, as we apply the vision penalty before doubling our vision range (it's a vision code thing). As a result, 1% or 10 % didn't make a difference (in stock, might be different in Bigmaps).
I've thus altered the code a bit - the penalty also now better applies to the side.
0% tunnel vision
1% tunnel vision
4% tunnel vision
One could still ask "Why is this called tunnel vision, this doesn't seem like tunnel vision at all?", but I think it's at least better than what we currently have.
Additionally, if both body items and weapon have tunnel vision penalties, we now use their maximum, not their sum. It seemed somewhat odd to me that a helmet would further reduce our view if we're already looking through a high-powered scope.
Committed in r8134.
It would now be more reasonable to have this on helmets.
[Updated on: Mon, 16 May 2016 19:41]
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.Report message to a moderator
|
|
|
|
Re: Absurdly small code changes[message #344851 is a reply to message #344846]
|
Sun, 03 April 2016 22:33
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
I've worked in the feedback - these are the values I plan to incorporate:
Current stock armour vest values (base version)
ID Name Weight Price Aim AP Stealth Flak? Protection Coverage Degradation
161 Flak Jacket 20 600 -1 0 0 True 20 75 25
164 Kevlar Vest 32 1000 -2 0 0 False 25 70 15
167 Spectra Vest 32 2000 -4 -3 0 False 29 85 13
189 Kevlar Leather 20 950 -1 0 0 False 20 85 20
196 Guardian Vest 32 1400 -3 -3 0 False 28 70 50
283 Zylon Vest 30 1300 -2 -1 0 False 25 85 25
284 Field Uniform 35 1400 -2 0 0 False 25 85 25
295 SWAT Vest 33 1100 -2 -1 0 False 28 90 15
803 Dyneema Vest 20 2000 -3 0 0 False 29 85 13
806 EOD Vest 65 4000 -10 -8 0 True 50 99 5
812 Twaron Vest 25 1200 -3 -3 0 False 28 75 15
183 Ceramic Plates 12 1000 -2 0 0 False 50 50* 15
837 Titanium Pl. 10 750 -1 0 0 False 35 10* 10
Flugente's proposed rebalancing
ID Name Weight Price Aim AP Stealth Flak? Protection Coverage Degradation
161 Flak Jacket 25 600 -2 -1 -10 True 20 75 25
164 Kevlar Vest 31 1000 -2 -1 -10 False 25 70 15
167 Spectra Vest 36 2000 -6 -5 -20 False 31 84 13
189 Kevlar Leather 20 800 -1 0 -5 False 17 90 25
196 Guardian Vest 34 1200 -2 -4 -15 False 28 70 14
283 Zylon Vest 30 1300 -1 -1 -10 False 25 75 50
284 Field Uniform 8 250 0 0 -5 False 8 90 25
295 SWAT Vest 36 1800 -4 -3 -5 False 26 90 15
803 Dyneema Vest 36 2000 -6 -1 -20 False 28 84 13
806 EOD Vest 65 4000 -10 -8 -25 True 50 100 5
812 Twaron Vest 30 1500 -4 -3 -15 False 28 77 15
183 Ceramic Plates 12 1000 -3 -1 -3 False 50 50* 15
837 Titanium Pl. 10 750 -1 -1 -3 False 35 50* 10
+C-18 -1 -1 -3 4
+Royal Jelly 1 0 3 2
Zylon vest now beats Kevlar vest, except for price... but it has a serious degradation drawback. 50% degradation ensures that this armor goes down really, really fast. Additionally, AP mali were slightly reduced.
The Field Uniform is new - is is cheap, lightweight, has tiny penalties, high coverage... and abysmal protection. As said, I plan to drastically lower coolness on this (so you'll see this in the very early game). It's basically your very first armour - either upgrade it with plates, or switch to a better armour, which is where the penalties come in.
Current stock armour pants values (base version)
ID Name Weight Price Aim AP Stealth Flak? Protection Coverage Degradation
170 Kevlar Leggings 39 800 0 -3 0 False 23 65 15
173 Spectra L. 39 1800 0 -6 0 False 27 90 13
282 Zylon Combat P. 35 1000 0 -3 0 False 23 90 25
294 SWAT Leggings 39 900 0 -3 0 False 26 75 15
802 Dyneema L. 30 1800 0 -3 0 False 27 95 13
805 EOD Leggings 48 2400 0 -12 0 True 45 99 5
811 Twaron Leggings 30 1000 0 -3 0 False 26 80 15
838 Leg Protectors 10 400 0 0 0 False 14 25* 20
Flugente's proposed rebalancing
ID Name Weight Price Aim AP Stealth Flak? Protection Coverage Degradation
170 Kevlar Leggings 35 800 0 -2 -10 False 23 65 15
173 Spectra L. 39 1600 -2 -6 -20 False 29 85 13
282 Zylon Combat P. 31 1000 0 -2 -10 False 23 75 50
294 SWAT Leggings 39 1400 -1 -4 -5 False 24 90 15
802 Dyneema L. 35 1600 -2 -2 -20 False 26 85 13
805 EOD Leggings 48 2400 -4 -10 -30 True 45 100 5
811 Twaron Leggings 33 1200 -1 -4 -15 False 26 75 15
838 Leg Protectors 10 400 0 -1 0 False 14 25* 20
Like for vests, zylon now degrades very fast. Aim penalties have been reduced.
Current stock armour helmet values (base version)
ID Name Weight Price Aim AP Stealth Flak? Protection Coverage Degradation Tunnelvision
176 Steel Helmet 14 100 -1 0 0 False 14 65 5 0
177 Kevlar Helmet 14 400 -1 0 0 False 23 75 20 0
180 Spectra Helmet 14 900 -1 0 0 False 27 75 15 0
293 SWAT Helmet 14 500 -1 0 0 False 26 65 20 0
302 Camo Steel H. 14 200 -1 0 0 False 14 65 5 0
801 Dyneema Helmet 10 900 -1 0 0 False 27 70 15 0
804 EOD Helmet 35 1600 -4 0 0 True 45 99 8 0
810 Twaron Helmet 10 600 -1 0 0 False 26 70 20 0
Flugente's proposed rebalancing
ID Name Weight Price Aim AP Stealth Flak? Protection Coverage Degradation Tunnelvision
176 Steel Helmet 12 100 0 -1 -10 False 18 65 5 0
177 Kevlar Helmet 12 400 -1 -1 -7 False 23 65 20 0
180 Spectra Helmet 14 800 -3 -3 -14 False 29 75 15 2
293 SWAT Helmet 14 700 -2 -2 -3 False 24 85 20 4
302 Camo Steel H. 12 120 0 -1 -10 False 18 65 5 0
801 Dyneema Helmet 11 800 -3 -1 -14 False 26 75 15 2
804 EOD Helmet 35 1600 -5 -5 -20 True 45 100 8 7
810 Twaron Helmet 12 600 -2 -2 -7 False 26 70 20 1
Aim penalties have been lowered. In exchange, helmets with high coverage get a tiny tunnel vision percentage (see previous post for example effects with 1% and 4%.
If there aren't cons, I'd like to implement this soon-ish.
[Updated on: Mon, 19 July 2021 22:24]
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.Report message to a moderator
|
|
|
|
|
|
|
Re: Absurdly small code changes[message #344950 is a reply to message #344861]
|
Sat, 09 April 2016 00:35
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
As of GameDir r2312, I've added the above changes (minus whatever typo I did for platinum plating).
This was actually more work than feared. After doing the changes, it turned out that the xml editor, in its infinite wisdom, had rewritten every single ammo item class index. Needless to say, removing that prior to committing was extensive.
After that, it turned out I forgot to add the NCTH aim stuff, so I redid that in the editor, after copying over the current, up-to-date stock GameDir xmls.
After then adding the NCTH stuff, it turned out that the ammo item indizes were garbled yet again. With stock xmls copied right over from GameDir. This did not raise my mood.
While editing the armour values, it also turned out quite a few C-18/Jelly versions of armour did not even have item descriptions. Or even a friggin' picture, instead they use the tnt image as a placeholder. It also turned out pants did not have any NCTH values set at all. Some of these things have been like that for over a decade. For a community that frequently jacks off on how carefully it maintains and improves the game, that is utterly disgraceful.
Up until now, I've always tried to make as few disruptive changes to xmls as possible, as to allow modders to adapt easily. Perhaps that is the wrong way. Perhaps I should go and change the xmls so much that the pressure to get this xml editor working again (or a new one working) is big enough that someone finally does something like that? There are more than enough weird xml things that we keep around simply for compatibilitiy reasons. Like that weird workaround in AmmoTypes.xml, apparently made in a time when there when floating point numbers weren't invented yet.
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.Report message to a moderator
|
|
|
|
|
|
Re: Absurdly small code changes[message #344980 is a reply to message #344950]
|
Sun, 10 April 2016 15:39
|
|
CVB |
|
Messages:129
Registered:September 2014 Location: Berlin |
|
|
Flugente wrote on Fri, 08 April 2016 23:35As of GameDir r2312, I've added the above changes (minus whatever typo I did for platinum plating). Good work, thanks a lot!
Quote:While editing the armour values, it also turned out quite a few C-18/Jelly versions of armour did not even have item descriptions. Or even a friggin' picture, instead they use the tnt image as a placeholder. It also turned out pants did not have any NCTH values set at all. Some of these things have been like that for over a decade. For a community that frequently jacks off on how carefully it maintains and improves the game, that is utterly disgraceful. I always thought the TNT image was an intentional, not so subtle hint not to use these items...
Quote:Up until now, I've always tried to make as few disruptive changes to xmls as possible, as to allow modders to adapt easily. Perhaps that is the wrong way. Perhaps I should go and change the xmls so much that the pressure to get this xml editor working again (or a new one working) is big enough that someone finally does something like that? There are more than enough weird xml things that we keep around simply for compatibilitiy reasons. Like that weird workaround in AmmoTypes.xml, apparently made in a time when there when floating point numbers weren't invented yet. Given the amount of times some random problem reported in the forum was actually caused be a buggy editor export, I long ago decided not to use that anymore. I get along just fine with Notepad++ and some plugins. For mass changes I can use a spreadsheet program.
IMHO, modding would profit much more from a decent comments section explaining the tags in every xml file than from an xml editor trying to play catchup with ever evolving features.
Peace is a purely theoretical state of affairs whose existence we deduce because there have been intervals between wars.
J. PournelleReport message to a moderator
|
Sergeant
|
|
|
|
|
|
|
|
|
Re: Absurdly small code changes[message #345402 is a reply to message #345097]
|
Tue, 10 May 2016 22:03
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
As it it probably well-known to anybody familiar with stock items, weapons are sometimes bizarrely treated. As it doesn't make any sense the the FN FAL and FAMAS cannot attach rifle LAMs while the equally ancient G3 can use all the latest tacticool gear, those guns now (GameDir r2317) have access to that as well.
While it probably doesn't make sense that ancient guns without rails can attach attachments that require rails, that would mean that a significant portion of all guns should get their attachments culled. At the same time, gun selection is even more bizarre... M40A1 is at 70% progress, while the superior M21 Tactical arrives at 50% progress.
Also, the gun selection is so absurdly skewed to HK weaponry... for example the entire elite gun selection consists of 64 guns, 30 of which are HK. I assume that at some point some serious HK fanboy got to make up this one.
While I'm not in the mood to redo that now, gun selection is in desperate need of a revamp.
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.Report message to a moderator
|
|
|
|
Re: Absurdly small code changes[message #345552 is a reply to message #345402]
|
Mon, 16 May 2016 18:03
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
As of r8217 and GameDir r2321, there is a no disability: hemophilia. This causes a merc to bleed a lot faster, and even for tiny wounds that normally don't cause bleeding (wounds with < 13 damage). Only bleeding is affected, bandaging/doctoring/anything else works just fine.
And yes, women can actually get this, it's just super-rare (no, not because they all bleed to death on their first period, you twat!).
I've awarded this to Henning and Brain. Henning because that seems likely for an inbred aristocrat, and Brain because 'why not?'.
[Updated on: Mon, 16 May 2016 19:45]
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.Report message to a moderator
|
|
|
|
|
Re: Absurdly small code changes[message #345573 is a reply to message #345555]
|
Wed, 18 May 2016 00:24
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
As of r8221, I've improved the improve gear function again (if you don't know what that is,check it out, as it's very convenient!). The function now additionally picks up extra mags if any mag-stack in your inventory is not yet full, and merges the mags in a stack. If a remaining magazine is not full, it is sorted to the front, so you can see that. This has the welcome side-effect that seemingly full stacks no longer hide empty ones after the first.
Ira has 2 used mags, and there are 4 lying around. We could pick that up by hand, but... effort!
After using said function, we now have 2 full and one almost full mag in one neat stack.
Obviously, this could still be improved more (replacing attached attachments etc.), but for now, I'm happy with this.
@silversurfer: Yeah... Psycho Pro Inc. will say that as well . But it's a thing and works. Not as suicidal as mercs unable to bandage themselves.
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.Report message to a moderator
|
|
|
|
Re: Absurdly small code changes[message #345629 is a reply to message #313897]
|
Sun, 22 May 2016 17:28
|
|
Frank2368 |
Messages:1
Registered:May 2016 |
|
|
Don't know if it's the right place to post this but I couldn't find a suggestion board. ><
I found some inconsistencies in the weapon stats.
M1 Garand, K98k and Mauser M03 which uses the 30-06 and 8mm Mauser should have their damage bumped up to 40 (both rounds are more powerful than the 7.62x51mm as well as 7.62x54mmR)
The Redhawk Alaskan which fires the 454 Casull has a handling of 6 even though it has a huge kick. It should be at least 14 or 15.
Report message to a moderator
|
Civilian
|
|
|
Re: Absurdly small code changes[message #346059 is a reply to message #345629]
|
Sat, 02 July 2016 22:44
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
As you might know, when we target a prone soldier, we cannot target their head/torso/legs specifically. Any hit in that position is always deemed to be a torso-hit. Not only is this weird (we can no longer differentiate between head and legs? dafuq?), it also allows some tactical decisions that seem odd but are effective. For example, as I always have my mercs go prone in combat for that sweet, sweet bipod-bonus, I never ever get hit in the legs.
For this reason, I never wear pants. This does away with all those pants-penalties and lowers weight. I could also forgo the use of helmets, though that is a bit more risky.
This is not exactly a bug - Sirtech explicitly coded it this way. The reason is that while standing or crouched, the body part we aim at/hit is simply determined by height - which obviously doesn't work while prone.
As of r8264 & GameDir r2326, no more of that. Head/torso/legs can now be aimed at (and hit) on prone targets. Sadly, due to the obfuscated way structure JSDs, bullet travel etc. works, this sometimes leads to unexpected results.
Another sideeffect is that stray bullets no longer ignore crouched and prone soldiers. This will affect both mercs and enemy soldiers, and should be taken into consideration regarding friendly fire (-> militia).
I consider this a bugfix, not an optional feature. However, in order to ease this transition (and to allow players to observe the difference), for a limited time, ALLOW_TARGET_HEADANDLEG_IFPRONE in JA2_Options.ini turns this code on and off. Should I get overwhelming feedback that the community would rather play with the buggy code it is familiar with, I will remove the code, otherwise at an not yet specified point of time, the code will be always active and the option removed.
For the same reason, the game will also tell you what part of a body you've hit if the target is prone.
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.Report message to a moderator
|
|
|
|
|
Re: Absurdly small code changes[message #346070 is a reply to message #346060]
|
Sun, 03 July 2016 13:32
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
What part of a body is hit depends on where the bullet hits the soldier. If it is near the center of the body, it's a torso hit, if it's near the next tile in the direction we are looking at, a headshot, if it's near the tile of the other direction, a leg shot.
This sometimes leads to unexpected hits as the underlying JSD files sometimes seem ... weird. But as a rule of thumb, the above applies. So if you for example attack a prone target from the front, headshots are likely and leg shots very unlikely.
What I meant with the friendly fire issue above is that if a bullet was not fired at us from a long range and not an explosive fragment, there were cases were it always hit us if we were standing, but never if we were rpone or crouched. The easiest way to see this difference is to open automatic fire at a region behind your mercs in various stances.
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.Report message to a moderator
|
|
|
|
|
|
Re: Absurdly small code changes[message #346209 is a reply to message #346142]
|
Wed, 13 July 2016 01:09
|
|
Uriens |
|
Messages:345
Registered:July 2006 |
|
|
LatZee wrote on Fri, 08 July 2016 20:13One vote for keeping this in options. Not that i mind it by itself, it takes a bit to get used to it and then it's mostly fine, but fighting with militia present is already a clusterfuck, probably more militia dies to friendly fire then from enemies at least now you can help them a bit by ordering them to the ground occasionaly, with this on I will literally run away screaming from any fight involving militia
I quite agree with this. Until now you could go crouch/prone and be safe from militia 'friendly' fire. If that option no longer works it may cause lots of problems (and grief) due to the AI's inability to avoid shooting friendlies. Also, some maps/mods have lots of civilians in some sectors placed, how should i put it - badly. For example, there is a map in UC where if you enter it from the west side you see a female civilian and lots of children standing in the street and an enemy soldier has a spawn point right behind them. Usually, with 'up to now' system those civilians would go crouch and be safe from stray bullets but now, when that soldier sees you, it will be a massacre.
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
|
|
Re: Absurdly small code changes[message #346376 is a reply to message #346292]
|
Tue, 26 July 2016 23:49
|
|
Flugente |
|
Messages:3507
Registered:April 2009 Location: Germany |
|
|
While I sometimes rant about the tendency to move vital functions to Lua scripts that have no business there (and as it's a pain to 'debug' makes my life harder), sometimes Lua is quite useful. Modders sometimes might want to do things that we can't really move to options or xml, and they can do that in Lua. A problem, however, is that they cannot alter what is stored in a savegame and what isn't. Technically, modders could use the SetFact/GetFact functions, but as there is no documentation on what values do what, that would be tremendously dangerous.
Luckily, that problem is now somewhat solved. I've added an array of 1000 signed integers that will be stored in savegames, and are reserved to be used exclusively by modders. You can do so with GetModderLUAFact and SetModderLUAFact, see an example from strategicmap.lua:
-- text colours
FontColour =
{
FONT_MCOLOR_DKWHITE = 134,
FONT_MCOLOR_LTYELLOW = 144,
FONT_MCOLOR_RED = 163,
FONT_MCOLOR_DKRED = 164,
FONT_MCOLOR_LTGREEN = 184,
}
-- these numbers aren't used in the code - we only use them in LUA
Languages =
{
LANGUAGE_ENGLISH = 0,
LANGUAGE_GERMAN = 1,
LANGUAGE_RUSSIAN = 2,
LANGUAGE_DUTCH = 3,
LANGUAGE_POLISH = 4,
LANGUAGE_FRENCH = 5,
LANGUAGE_ITALIAN = 6,
LANGUAGE_CHINESE = 7,
}
-- We have an array of 1000 signed integers that a modder can use to set whatever data he wants.
-- We simply set up some enums here to make it easier for us to remember what is what
ModSpecificFacts =
{
TIXA_PRISON_VOLUNTEERSGAINED = 123,
TIXA_PRISON_SUBLEVEL_VOLUNTEERSGAINED = 124,
ALMA_PRISON_VOLUNTEERSGAINED = 125,
}
-- this function is called whenever we liberate a sector. If fFirstTime is true, this is the first time we liberate this sector
function HandleSectorLiberation( sNewSectorX, sNewSectorY, bNewSectorZ, fFirstTime )
-- are we liberating this sector for the first time?
if ( fFirstTime ) then
-- we get a few volunteers for liberating prisons - we assume prisoners would be more than eager to fight against the regime
-- due to code limitations, fFirstTime is only used in surface sectors
if ( bNewSectorZ == 0 ) then
-- Tixa
if ( sNewSectorX == 9 and sNewSectorY == SectorY.MAP_ROW_J ) then
AddVolunteers( 30 )
AddTransactionToPlayersBook(1, 0, 1800, 100)
if ( GetUsedLanguage( nil ) == Languages.LANGUAGE_ENGLISH ) then
SetScreenMsg(FontColour.FONT_MCOLOR_LTGREEN, "The prisoners are very grateful for freeing them.")
elseif ( GetUsedLanguage( nil ) == Languages.LANGUAGE_GERMAN ) then
SetScreenMsg(FontColour.FONT_MCOLOR_LTGREEN, "Die Gefangenen sind für die Befreiugng sehr dankbar.")
else
SetScreenMsg(FontColour.FONT_MCOLOR_DKRED, "Translation missing!")
end
-- inform us that there is a sublevel
if ( (GetModderLUAFact(ModSpecificFacts.TIXA_PRISON_SUBLEVEL_VOLUNTEERSGAINED) == 0) ) then
SetScreenMsg(FontColour.FONT_MCOLOR_LTGREEN, "This prison seems to have a sublevel, where more important inamtes are held.")
end
-- if we haven't yet freed the Alma prisoners, give us a tip about that
if ( (GetModderLUAFact(ModSpecificFacts.ALMA_PRISON_VOLUNTEERSGAINED) == 0) ) then
SetScreenMsg(FontColour.FONT_MCOLOR_LTGREEN, "A few inmates inform us that there is another prison like this in Alma!")
end
SetModderLUAFact(ModSpecificFacts.TIXA_PRISON_VOLUNTEERSGAINED, 1)
-- Alma
elseif ( sNewSectorX == 13 and sNewSectorY == SectorY.MAP_ROW_I ) then
AddVolunteers( 10 )
SetScreenMsg(FontColour.FONT_MCOLOR_LTGREEN, "The prisoners are very grateful for freeing them.")
-- if we haven't yet freed the Tixa prisoners, give us a tip about that
if ( (GetModderLUAFact(ModSpecificFacts.TIXA_PRISON_VOLUNTEERSGAINED) == 0) ) then
SetScreenMsg(FontColour.FONT_MCOLOR_LTGREEN, "A few inmates inform us that there is another prison like this in a place called Tixa. They aren't sure where it is though.")
end
SetModderLUAFact(ModSpecificFacts.ALMA_PRISON_VOLUNTEERSGAINED, 1)
end
end
end
...
which leads to this ingame:
In this example, ModSpecificFacts are enums from that 1000-sized array. You can name and use them however you like. They will be saved and loaded in the savegame, what you do with them is up to you. In this small example, I use it to print out different texts and a tiny bit of 'lore' depending on what sectors you already liberated. You can use this to set up your quests, store states of some attack, whatever. Integer values from -2^31 to 2^31 are valid.
While I'm at it, I added a few other tiny functions:
- SetScreenMsg() can be used to print out texts, as seen in the image above (you could also print texts to other places, but I'tm not letting you access that ). The first number is for the colour (in the example I listed some values), the second is the text, which can be up to 1000 chars long.
- As you might want to have a different text depending on language, GetUsedLanguage( nil ) returns the language the game currently uses. The value corresponds to the Languages-enum I listed.
This has been added to the code in r8276 & GameDir r2331. This will be widely used in a future feature, but is useful enough on its own that I released it now.
@Modders: The, say, first 100 numbers will soon be used in an upcoming feature which will demonstrate the usage of this more widescaled. It's better for now if you use numbers 100-1000. (I don't plan on using all 100, but better safe than sorry).
[Updated on: Wed, 27 July 2016 01:30]
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.Report message to a moderator
|
|
|
|
Goto Forum:
Current Time: Tue Dec 03 23:49:08 GMT+2 2024
Total time taken to generate the page: 0.02945 seconds
|