[OLD] Old OXCE+ discussion thread

[yrizoud]

Fog can be done by shifting colors to grey instead of black (like TFTD shifts to blue), but you'll lose black colors for UI elements.

About the gameplay effects of weather, IMO it's much more understandable to apply rules throughout the battlefield, like x90% accuracy and daytime vision reduced to 15. A movement penalty can also apply for heavy weather, but I hope nobody overdoes it : It's very unfun when your soldiers take forever to move.
I know such penalties shouldn't apply indoors (farm, terror city buildings, inside of UFO), but I don't see a simple way to compute these things tile per tile. I'd rather shrug it off : These penalties still apply indoors because soldiers are still wet and distracted by rain dripping from helmet.

[Dioxine]

On the 8-bit map thing, just for more explanation.

This technique's only plus is saving space by cramming 8 booleans into a single byte; useful for savegame files. It makes little sense to expose this to the modder as it's a nightmare to use; better break it up into 8 booleans for ruleset, and write a script to cram them into a single byte again, it is MUCH more ergonomic that way.

[Meridian]

This technique's only plus is saving space by cramming 8 booleans into a single byte; useful for savegame files. It makes little sense to expose this to the modder as it's a nightmare to use; better break it up into 8 booleans for ruleset, and write a script to cram them into a single byte again, it is MUCH more ergonomic that way.

1/ There are actually not only 8, but as many as you can put into an integer (at least 16 I think)

2/ I need to write a lot less code (with lot less code repetition)... instead of handling each flag separately, I can treat all of them at the same time
- and yes, cramping them together (after loading) into one byte or int would be possible... but since they have no names (see next point), it wouldn't help the readability of the ruleset anyway

3/ these flags have literally no semantics... they aren't called "canUseUnderWater" or "canBeUsedInFinalMission".... they are basically just "flag1", "flag2", "flag3", etc.

Bottomline:
- if you ask for one (or two or three) flags, which have clear names and semantics, I will do them separately
- if you need unknown number of flags with unknown semantics, I will cramp them together

Choice is yours.

[sambojin]

The joy of "I've got bigger computing donk than NASA did in the 60's, in my right pocket. Bytes don't matter to me f'shizzle." Then again, NASA got less dick-cancer for being awesome, probably....

Some old skills are still worthwhile today though. A bit-map is a hell of a lot easier to code for than a look-up table or boolean array. Depending on the styles of coding you do.

It ain't hard if it's spelled out "This is how the system works". It may even help more people be as awesome as Meridian is in the long-run.

ps. Meridian. Cheers mate. Your are awesome.

Posts merged - thanks for uselessly wasting a minute of my life - Dioxine

And, he's a ninja too :p

[Dioxine]

Hmmm, I see. Why not present it the way Yankes does?

Deployment:
enviroType: 7 (default = 0, no special rules)

Item/Armor: (maybe craft too? it'd lead to "cannot land here" message)
forbiddenEnviroType: [1, 7, 12] (default: none)

Enviros ()
- Type: 7
defaultArmor:
  soldierType: xxxx (broken between soldier races in some way...)
    <the same as normal default for soldier's race>
other rules
other rules


@Sambojin: I don't like "scarcity economics". Yes let's use the simplest tools possible, but NOT SIMPLER. Let's use the least space possible, but NOT LESS. Bytes do matter, yes, if we're counting gigabytes. Or double-posting, which is a matter of manners not filesize, as it is often the case with programming, too. And I'm not sure where you're aiming at with your dick joke.

[sambojin]

Simplicity of coding, mostly.

90-99% of Meridian's coding is aimed at X-Piratez, it appears. Especially with his play-through of it. And its a good LP to show how good X-Piratez is.

The best mod, of one of the best games ever.
If you package it for Android and iPhone, you'll go down in infamy as the best modder *ever* Dioxine.

But Meridian's patch is pretty all-inclusive, making the basic engine more user friendly, whilst also extending it massively for modders.

That's some donk!

So meh. If you want some weapons or armour to be able to be used in some environments and not others, it's easy. A 16-bit or 8-bit boolean bit-map. Probably with good comments on "How this system works".

Amazing that Meridian would bother to put it in at all, just for one or two mods in development that thought it might be useful. Probably best that it's easy to code....

lol.

Hey, Meridian. I want to rip Syndicate's graphics and sound files and make a mod for openXcom. Could you code in "burble, burble, burble, lots" for me? Only joking......

[Solarius Scorch]

I have to respectfully disagree that Meridian's work is heavily aimed at X-Piratez. I mean maybe it is, maybe not, I'm not him so I can't know for sure, but it doesn't matter - his changes are clearly written in a way to make them versatile. Which is exactly why they're so important: they are straight extensions of OpenXCom Extended, which is not written for any particular mod.

Meridian makes decades old dreams come true

[sambojin]

That's why it's good.

X-Piratez? The best game utilizing the openXcom engine so far. If Dioxine is sure he/she isn't using any IP assets, it would storm the X-Com-alike market due to excellent gameplay and innovation.



Meridian's extensions, game quality coding, ect, is for us all. Thanks

You're both saints. I hope every openXcom player eventually realizes how much further you are taking the engine and game. For any mod of it too. Thanks. I know it's not all your work, but it's the best compilation of mods and coding, for mods and coding, thus-far.

It makes openXcom better all-round.

Cheers Dioxine.
Cheers Meridian.

[Dioxine]

That's the power of open-source and free sharing, man.
And I didn't really mean to criticize anyone's way of coding. Everyone codes their own way and that's how it should be. What I was getting at is the manner how it is presented/organized from modder's (and by extension, user's) perspective so features are easier to use (the latest Yankes' changes, while ground-breaking, require some real studies to utilize )
Also this might look like aimed at X-Piratez, but I would never ask for any features that'd be useless for other mods (like dating engine, for example - I'll write it myself if it comes to that point ).

[Yankes]

If we talk about custom properties. I'm now working (still in design phase) on system of adding custom properties to armors, units, solders etc.
This will be required by script to handle custom behaviors required by modders (like "I_AM_NIJNA: 1").
It would be to kinds of properties one in rulesets (readonly but can be overridden by another ruleset) and properties form savegame (that can be modified by scripts, and will be saved and loaded by game).

For ruleset usage will be simple:

Code: [Select]

armors:
  - type: ARMOR_X
    custom:
      XPIRATEZ_PROP_A: 13
      XPIRATEZ_I_AM_NINJA: 1
      FMP_IMMUNE_TO_SOMETHING: 0
    someScript: |
      unitArmor.getCustomInt r0 XPIRATEZ_I_AM_NINJA;
      if eq r0 1;
        #do ninja things
      end;

From code perspective it will be vector of ints (names will be stored separate and used only for saving and loading from files).

I plan have this feature in 3.0 (with unhardcoded reaction code and exposing items to scripts). One interesting side effect will be that weapons could be used in calculating stat bonuses in units (like you will be able to have bigger regeneration if you have correct weapon in hands).

[Solarius Scorch]

Thanks to you, I may yet learn to code.

[Meridian]

Hmmm, I see. Why not present it the way Yankes does?

Deployment:
enviroType: 7 (default = 0, no special rules)

Item/Armor: (maybe craft too? it'd lead to "cannot land here" message)
forbiddenEnviroType: [1, 7, 12] (default: none)

Enviros ()
- Type: 7
defaultArmor:
  soldierType: xxxx (broken between soldier races in some way...)
    <the same as normal default for soldier's race>
other rules
other rules

I thought the requirement was for multiple "enviros" for a single deployment... wasn't it?

E.g.

Code: [Select]

Deployment:
enviroTypes: [1, 0, 1, 0, 0, 1, 0, 0]

Item/Armor:
forbiddenEnviroTypes: [0, 0, 0, 0, 1, 0, 0, 0]

where
  enviroTypes: [1, 0, 1, 0, 0, 1, 0, 0]
could be shortened to
  enviroTypes: 37 (1+4+32) https:// if this is too difficult to use, option above is also OK for me, but not option below
or expanded to:
  enviroTypes:
    type1: true
    type3: true
    type6: true

For example type1 would mean "underwater weapons only", type3 would mean "one-handed weapons only" and type6 would mean "scuba/space suits only"

PS: and I wouldn't call it enviroTypes, just customTypes, because it can cover many other aspects than just environment

[Dioxine]

Hmm I cannot imagine a situation where you'd need multiple enviros per map... Either you're on Mars, or you're not. Either you're underwater, or you're not. How many enviros would one need? 5? 10? If no more than this, combining makes little sense. But let's wait what other people say on this.

If we need multiples, I'd vote for option #1, eg.  [0, 1, 0, 0, 1]

Also regarding naming - maybe enviro is misleading but customType means literally nothing (a custom type of... what???) If enviro is bad then we need some better name. In my own understanding, a mission consists of yourself, enemy, terrain and the rest, which seems natural to be broadly called environment.

EDIT: Also multiple enviros per map can lead to direct conflicts between enviro rules, and unclear preference of armor. Naturally a modder can make it in a way that avoids conflicts, but - this way you can make 500 or more enviro combinations, but with much tighter constraints. If you don't need 500 enviros (combinations), I think it is better to stick to '1 enviro per map' rule, as there will be no conflicts and modding would be much easier.

[Meridian]

Hmm I cannot imagine a situation where you'd need multiple enviros per map... Either you're on Mars, or you're not. Either you're underwater, or you're not. How many enviros would one need? 5? 10? If no more than this, combining makes little sense. But let's wait what other people say on this.

Yes, that's why I don't want to call it enviroType, but customType.
It is not only about environment.
Originally Solarius came to me with this request:

For the X-Com Files mod I'm working on, I would like to add "undercover" missions where you can only use certain equipment (only concealable weapons like pistols and only selected armours, meaning no armour).

You see that this has nothing to do with environments... he wants to disable certain weapons and armors for certain mission types. It is a generalization of environmental conditions/restrictions, to "any" (or "custom" if you will) conditions.

If we need multiples, I'd vote for option #1, eg.  [0, 1, 0, 0, 1]

OK.

Also regarding naming - maybe enviro is misleading but customType means literally nothing (a custom type of... what???) If enviro is bad then we need some better name. In my own understanding, a mission consists of yourself, enemy, terrain and the rest, which seems natural to be broadly called environment.

"A custom type of mission".

I can't think of any better name... these conditions can represent virtually anything. I don't know... for example a mission where only weapons which don't make any noise are allowed (e.g. knives, swords and bows). That's not type of environment, it's just a custom type of mission.

EDIT: Also multiple enviros per map can lead to direct conflicts between enviro rules, and unclear preference of armor. Naturally a modder can make it in a way that avoids conflicts, but - this way you can make 500 or more enviro combinations, but with much tighter constraints. If you don't need 500 enviros (combinations), I think it is better to stick to '1 enviro per map' rule, as there will be no conflicts and modding would be much easier.

Yes. That's why I didn't want to implement it.
I would say that the modder should explain to the user, which armor/items are allowed for that kind of mission and which are not... or as Solarius stated earlier, just let the player find out.... the hard way.

Not a problem, they will learn. There will be Ufopaedia.orgrmation on that (mostly in armour descriptions). And maybe you could add a message why the mission is over instantly, like the "all aliens died in crash" one.

So for example I could produce a message "There are no soldiers capable of fighting in this mission... Aborting now."
And because I am a nice person, the crash site would not disappear, so that the player can reequip and return.

[Dioxine]

"For the X-Com Files mod I'm working on, I would like to add "undercover" missions where you can only use certain equipment (only concealable weapons like pistols and only selected armours, meaning no armour)."

For me it's environment, in this case, created by social constraints But I agree it's arguable definition. Otoh "customType" on a weapon is unclear, it could be something like "battleType" which has nothing to do with mission rules. IMO it's misleading, but there's little point in fighting over words Like I said, better to wait for what Solarius and others have to say in the matter...