Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Yankes

Pages: [1] 2 3 ... 151
Offtopic / Re: XCOM Inspired Fantasy Game
« on: May 30, 2020, 03:29:46 am »
Maybe I do not say this clearly, you do not transfer any resources, you "spend" your old resources when you go back in time, each time you return you have less of them.

Offtopic / Re: XCOM Inspired Fantasy Game
« on: May 30, 2020, 12:25:12 am »
Since saving/loading obviously has in-game economic value, it would make sense to require player spending some resources to save the progress. Similarly to how Tomb Raider games used save crystals. In a fantasy strategy game setting, saving the game can be represented as a visit to Oracle, who takes money to predict future. Now usual supply/demand rules apply to the save-game economy. And suddenly you have save-system which work even in multiplayer games. In fact, both sides can agree on saving the game at some point and pay agreed price for that. Then any of the participating players could invoke the save. Obviously that would need to be somehow integrated with the diplomacy system.

Same way I plan to implement battlescape saves as a time travel spell, which would work even in multiplayer.

If save is not free thing, then my exploit will not work, but how you will handle "load"? We have save 10 turns before, one wining player do not want to go back but losing player do not want.
If we go time  travel spell way then could we lose resources in past too? Some thing like that:
You start with X+Y of some resource you need.
To save game you spend X, You left with Y.
Couple of turns pass. You grain Z resources.
You load game spending Y+Z
Save is modified and remove Y from your resources. Continue game.
Couple of turns pass. You grain Z resources.
You can't load game because you have only Z.

This mean if you have enough resources you can multiple times force "time travel" but each time you will have less power to revert bad future.

Currently I'm still struggling with getting the time system itself correctly. Original XCOM had only geoscape time, while battlescape was almost disconnected from the geoscape time-wise, with the only exception being night/day battles. And night missions were a special kind of nightmare, since aliens all had night vision. Now I want to connect the battlescape time with geoscape. Each Action Point squad spends on the world map this day will be subtracted from the time available on the battlescape, if squad enters the site exploration stage today. If the battlescape time runs out, then visitor will be forced to retreat unconditionally, losing any units surrounded by the enemy. Obviously battlescape time amount should be generous enough. Say 100 or 200 turns per day, but still encourage having some reserve time. Now time travel spell will not only help with the exploration, but will also unwind the time. The only catch is that the unit performing the time travel should survive.

The remaining questions is about making it possible to travel into the future from the past. That is always harder, since future is less known than the past. Or is it? Guess physicists will correct me that future is more stable and predictable than the past ( ), since the future is still there, while the past has already dissipated, leaving a few fossils at best ( ).
I don't think, result of this 3 body problem mean that you can't know what future is exactly because you need know current state better than physic laws allow.
Aside you need consider wavefunction collapse too, where result is unpredictable, and this even is very small can have big consequences. One simple example is that someone decide to nuke moon out the sky (IF we not nuke self out of earth), and all this need only one button press than is triggered by one neuron.

Offtopic / Re: XCOM Inspired Fantasy Game
« on: May 28, 2020, 07:45:18 pm »
Compared to XCOM, battles are expected to be completed faster, and there is no save in the battle. The only opportunity to save would be on the world map. But I will try to prevent save scumming. Still I guess people could save-scum anyway, running in the emulator. But at least I could use the PRNG to prevent reloading to achieve different result. I.e. all sites are pre-determined on the world generation, so there will be no way to reload the game until it spawns the type of monsters which can be easily defeated by the player's current army. Same with AI, which uses pre-seeded RNG, so reloading wont affect AI's behavior. IIRC, Heroes of Might & Magic IV determined when player reloaded the game to save scum some chests with random content and locked-up the PRGN, although that could have been a glitch. But I believe the error was determining the chest content on the pickup stages, instead of at its generation time.

But you in reality replace one save-scum with another. Now player can scout in ineffective way losing most of int units, checking what he can grain, then he reload and only do things in effective way, skipping all fights that do not give any benefits.
Another problem is "groundhog-day" where you can predict events in future.

I think maybe better system would be hybrid one, you precalculate 20 rolls ahead, and you store them in save. This mean couple of roll after reload will give same results but after som time you will have diffident outcomes.

Of corse this system could explored too, you can still reroll chest but it would need reload and doing lot of actions to exhaust all random buffer and try again.

Programming / Re: Problem in Compile
« on: May 28, 2020, 12:04:43 pm »
Looking on yaml-cpp it have this function from yaml-cpp-0.5.3 onward, you probably have some older version

Help / Re: Avatars / Paperdolls - Faces&Hair
« on: May 26, 2020, 11:53:28 pm »
Just to clarify - can I simply delete the entries in extrasprites or do I need to delete them elsewhere (armor defintions etc.) as well?
This details I do not remember, possible only extra sprites should be fine.

OpenXcom Extended / Re: Addition of More Indicator Sprites?
« on: May 26, 2020, 11:46:41 pm »
I didn't had time to do this, I could add this, but simply I do not know when it will be done.

Help / Re: Avatars / Paperdolls - Faces&Hair
« on: May 26, 2020, 02:22:33 am »
Yes, deleting is supported operation, is allowed to have "holes" in this system. Only drawback is increased chance for some other "face" to be used instead of removed one.

For names, I do not have time to check exactly how this values goes, but base game have only `F0-F3` and `M0-M3` base looks, if you add this variant then you can have values e.g. `M4-M7`, max something around `F127` (something like  `nationality + 4 * variant`).

Help / Re: Avatars / Paperdolls - Faces&Hair
« on: May 25, 2020, 10:32:13 pm »
I suppose you mean in OXCE?
There is hierarchy of different faces, we start at top of vanilla 8 variants (4 skin colors * 2 genders).
Image you have 64 soldiers, each one will have one of this variants, this mean you will have 8 soldiers with same face.
Then we define 16 possible faces, this cause that from this 8 soldiers half get new face, rest stay to old one version.
If we expand number possibility, this happens again half of all units get new face type.

This expansion end at around 256 possible variants (including gender versions).

How exactly engine define who gets what? By bit masks, each unit get rolled random number in range from 0 to 63, name it variant.
When engine try show some soldier graphic check if there is any "look" (for specific gender and nationality) in range 32-63,
if is any, game check if variant number match this range then this look is returned.
if there is no available in this range then game "compress" variant look to 31 values (by dropping byte value 32)
after that game check range 16-31 to see if there is any mach, if it is, it return it other wise reduce again max possible value to 15.

This go until value of variant go to zero, then we leave with only 8 possible version from original game.

One of this two descriptions should be readable enough to understand how logic work there.

Help / Re: Starting conditions - adding additional soldier types
« on: May 25, 2020, 02:41:57 am »
Right now you need copy and paste it.

Help / Re: Starting conditions - adding additional soldier types
« on: May 25, 2020, 02:02:41 am »
This right now work only for list and list look like:
Code: [Select]
  - AAAA
  - CCC

You have map:

Code: [Select]
  AAAAAA: bbbb
  CCCC: ddd

I need look at this case if is easy to add this new functionality here too

Released Mods / Re: [COMPILATION] Final Mod Pack (FMP)
« on: May 23, 2020, 08:04:33 pm »
OpenXCom Extended is OpenXCom that is Extended in modding capabilities and FMP should not needed it as it should be compatible with normal OXC

OpenXcom Extended / Re: How underwater bullet trajectory works?
« on: May 23, 2020, 07:58:23 pm »
If I recall correctly this is "desired" color you want have, after that game iterate for each palette and try find best matches for desired color.
Logic is somthing like:
Get some color for palette, mix in your desired color in RGB, now for this new color in RGB find best match in same palette.
This will give transition from original color to final one in same palette and it represent transparent vapor cloud.

The X-Com Files / Re: Skin mod
« on: May 22, 2020, 06:14:09 pm »
Code: [Select]
my amateurish level suggests that the armor is already attached to the skins, but I could be wrongDo you mean unit face color (and hair)? If you want have marching in your new armor define `spriteFaceColor` and `spriteFaceGroup`
Correct values you need check main mod what it have.

Overall code is responsible for updating this colors in unit graphic, you need only use correct values in graphic and rule set to make it work.

Btw there are 4 different recolor options:

Hair color - based on nationality of soldier
Face color - based on nationality of soldier
Rank color - based on rank of soldier
Utility color - unique value for each soldier

This mean you can have same armor but some colors can be different based on rank of unit (red beret for commander) or have color schema like Power Rangers :)

Offtopic / Re: XCOM Inspired Fantasy Game
« on: May 21, 2020, 11:17:25 pm »
Code: [Select]
You just need a rotated version of each sprite, and there will be additional 3 views, each different by 90 degrees.At first glance this is disadvantage, because you need do 4 times more work than normally, but there is trick, each tile can have its own rotation, this mean if you see 4 same item each can facing different direction, this mean every version can be used even if player do not rotate map, even once.

Offtopic / Re: XCOM Inspired Fantasy Game
« on: May 18, 2020, 01:31:34 am »
That is called Z-buffer. A thing 3d hardware implements very efficiently.

But in case of tile-based isometric game with oversized sprites, you want to be very careful with Z-Buffer, so objects wont clip through walls. I.e. you want to render your giant units with Z-test turned off, just like you render HUD in FPS games to avoid it clashing with objects on screen. Then there are also transparent surfaces, which still require tricky sorting. Unless you do physically based rendering, where actual light rays travel the scene.

Although games like Warcraft III turned the clipping bug into a feature, providing buildings with foundation, that can be unearthed on uneven terrain.
This is correct, if done poorly then big objects will be problem, but if we use tiles then on load we can check if any pixel do not "escape" 3d box where it should be.
Then if it clip then it should clip, this WC3 example is why I think this is very good function why try use this approach. In some special cases I would like if unit clip through other objects. Water, high grass, mud, waterfall, ivy, bushes. magic portals etc.

Transparency is indeed problem, but I think of work around. Instead of multiplicative transparency use additive, with it order in each surface is draw will be irrelevant. First you will draw all not transparent objects, after this transparent.

To have reasonable speed this will probably require manual use of see4 intrinsic because compilers sometimes miss some transformations (same OXCE code have 3x time speed difference based on different GCC version).

Pages: [1] 2 3 ... 151