Messages

1

Offtopic / Re: XCOM Inspired Fantasy Game

« on: July 20, 2019, 06:34:48 pm »

I mean something else with game assets, they are NOT GPL, and my question was is legal to bundle them together with GPL exe.
You own all Copy Rights to it but none to your code. Image selling Piratez as standalone game as it still need OXCE.

Big companies have big budgets - they can easily hire the best engineers and artists of their own. What they are really afraid of is losing their market monopoly.

I mean case as MS long time ago pulled off: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
They use it to expand they monopoly by consuming smaller markets.

2

Offtopic / Re: XCOM Inspired Fantasy Game

« on: July 19, 2019, 11:48:29 pm »

I dislike the share-alike clause, which forces one to release all the source code, so he/she cannot monetize any investments into it.

Do game asserts fall under GPL? If not you can still sell them and add game engine as free bonus.

For example, you cant take Linux, improve it and sell it, because you don't retain the exclusive copyright (contrast that with BSD).

This is double edge sword, because it prevent big companies on profiting on your work for free. They need contribute back if they want use your work.
Red Hat is not MS but they still can profit from Linux and improve it.

3

OpenXcom Extended / Re: Xpiratez/OXCE Issues

« on: July 19, 2019, 11:30:07 pm »

Piratez are full package, you can't change exe without side effects.
First of all, do you download it to clean directory? If not then old files could interfere with new ones.
Second, "Crash" mean nothing, what exactly message you get and what are last lines in log?

4

OpenXcom Extended / Re: [Suggestion] Mana pool

« on: July 18, 2019, 09:58:34 pm »

There are other threads for combat stress/fatigue, for example here: https://openxcom.org/forum/index.php/topic,4473.0.html

Please keep this about mana.

This is more how we could reinterpreted this to have different "theme", something like Monopoly Star Wars game. Same basic mechanic but sold under different name.

5

OpenXcom Extended / Re: [Suggestion] Mana pool

« on: July 17, 2019, 10:26:21 pm »

This is permanent resources that need time to regen? This could be used (after name change) to simulate long term exhaustion.

6

Released Mods / Re: [UFO MEGAMOD] XCR: X-COM Classic Remastered

« on: June 25, 2019, 02:08:30 am »

https://openxcom.org/forum/index.php/topic,3287.msg113764.html#msg113764

7

Fan-Stuff / Re: Has anybody tried computing travel time from Mars?

« on: June 22, 2019, 04:06:08 am »

It depends whether all this energy can be released at once.
An instant ramen pack has enough chemical energy to rival hand grenades, but it can't just explode.

This is good point to consider, probably similar to nuclear bomb / power plant. Question is to what end UFO is closer to.

8

Fan-Stuff / Re: Has anybody tried computing travel time from Mars?

« on: June 21, 2019, 06:03:26 pm »

Mars is moving at some orbital speed and Earth is moving at another. The difference will be the dV (delta V, change of velosity) that the UFO needs to do. Like two cars speeding on a circular high way, the UFO is a roller scater that jumps off one car and travels to the other.

A space craft leaving Mars orbit will initially orbit the sun at the same speed Mars is moving and will need to make a burn that changes it's orbit to one that brings it close to Earth and then do another burn to mach its orbit around the Sun(and the ships speed) with Earth.

Calculating the path as if the craft is stationary and only needs to move from point A to B is not accurate. If the UFO just aims at Earth they will collide at a huge speed, most likely destroying the UFO. For a successful randezvous the UFO has to travel to the target and mach speed with it.

This is question how much energy UFO have available to maneuvering. Current space crafts have VERY little of this available (after you burn thousands tons of fuel to exit earth). If UFO can on demand enter and leave earth atmosphere then it could fly in "straight" line from mars to earth and decelerate before entering atmosphere.

Interesting fact, ISS kinetic energy is 1/5 of energy released by Hiroshima atomic bomb:  https://en.wikipedia.org/wiki/Joule#Multiples
This mean UFO energy source should have enough energy to destroy whole city.

9

OpenXcom Extended / Re: [Suggestion]Random alien stats.

« on: June 17, 2019, 07:48:59 pm »

If you want only overall randomized stats then you can do this today using scripts.

10

Work In Progress / Re: Nightly Builds Discussion for Modders/LPers/Players/etc.

« on: June 08, 2019, 05:02:26 pm »

BREAKING CHANGE INCOMING

SupSuper merged my PR that change how OXC handle negative indexes and common surfaces for all mods.

This mainly affect `bigSprite`, where OXC use negative indexes for terror unit weapons. Right now they are now invalid, game will reject mods that use them. Only exception is `-1` but it now mean no-sprite not terror weapon sprite.
If your mod still need this surface there are still available but under different syntax:

Code: [Select]

bigSprite: { mod: master, index: 61 } # under this we have old "-1" sprite, 60 is "-2" etc. for UFO, XCOM2 have different offsets because it have more surfaces
This new syntax allow you to access resources of other mods (work for sound and other shared surface sets too).

Code: [Select]

bigSprite:
  mod: MyOtherMod #id of mod from `metadata.yml`
  index: 120

Old syntax still work

Code: [Select]

bigSprite: 120
and is equal to

Code: [Select]

bigSprite:
  mod: current #alias for current mod
  index: 120

Example of change I made to make Final mod pack to work with this new version:

https://github.com/Yankes/Final-Mod-Pack/commit/bdad8bb33713577259d0f36a779d50da295a9dd3


some additional changes:

added `ignoreInBaseDefense` from OXCE as some mods used negative index to limit usage of items.
if you exceeded `reservedSpace` for your mod, game will fail to load.

11

OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread

« on: May 28, 2019, 10:41:06 pm »

Could you make a tweak to the ToItem attribute on damageAlter? Currently, it goes through items one at a time, damaging it until it destroys that item. I can't see a good way to use this functionality. It randomly destroys an almost-fixed number of items, regardless of how many items are on the unit(s) hit by the attack.

I propose that ToItem causes all items held by the attacked unit(s) to be hit the same as if they were on the ground. This means, for example, that a ToItem value of 1.0 on an explosive would destroy items held by units just as though they were laying on the ground.

If the current functionality of ToItem is worth maintaining, then I propose a new value: ToAllItems

First changing this will affect vanilla behavior, you need have good reason to do this.
Second, same logic is used to items in inventory as items on ground, only difference is that items and unit in inventory get damage from overkill of target unit.
Third, current behavior of item damage is bad, its do only one check for item armor value and if damage is bigger then item is destroyed.

12

OpenXcom Extended / Re: [Suggestion] sqr formula for throwing range

« on: May 10, 2019, 08:55:59 pm »

Some thing like this could be done by scripts, this is simple calculation task, that scripts can handle fine.
It could do even more, each armor could have different throw ranges (or per item).

[ps]

After fast looking on code, I see that logic is bit more complicated: https://github.com/OpenXcom/OpenXcom/blob/master/src/Battlescape/ProjectileFlyBState.cpp#L693

Nowhere in code we have `2.5 × Strength / Weight` it only have `dz -= (double)(50 * weight / strength)/100;` in loop.

13

Resources / Re: Graphic Gallery

« on: May 09, 2019, 01:13:28 am »

That way supporting HD-graphics would be a matter of adding support to blitting routine.

No, if you really want you could today load 2x bigger sprites to game and it would not crash, but problem lay in other place, offset.
Game is full of magic numbers that fit current graphic size and completely do not work with any other size. And adding arbitrary sizes will be hell of a work to do.

14

OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread

« on: May 08, 2019, 11:23:30 pm »

Excuse me, but this seems like a pretty important change as far as animation behaviour is concerned, in a mod that prides itself on keeping/preserving vanilla consistency. Going by this you could also do away with the shooting animation entirely and just show the results instead.

This is priority of OXC not OXCE. When I start OXCE, my main goal was modding capacity of engine even when sacrificing original behavior.
See: https://openxcom.org/forum/index.php/topic,6459.0.html
If new behavior have similar (not same!) end effect and give more options for modder then I throw through the window original behavior.

And here we have exactly this case, changing order is very visible but end result is same. As it give lot of potential for new mod capabilities and code refactor that will simplify and allow future changes and new functionalities. And only thing left is personal taste and familiarity with old behavior.

For single hit animation current version look even better IMHO.

As far as i am concerned the tiles are 'precognitive', since the only inidication that any damage has been delat is when the hit animation plays - which is does after the terrain tile is already destroyed. Damage calculation in-game isn't transparent to the player. I'd ask you to reconsider and at least give us an option to enable vanilla behaviour (for animations).

People evaporate in nuclear strike before shock wave reach them.

Options to toggle it is out out question, because whole point of this change was to simplify game logic not add new cases and versions. Whole point is that I could really on this that calculation was done before all animations.

Only thing that could be done (as I said previous post) to alter how tiles are handled after damage calculations. That could allow delay update of tiles to some frames after hit, but this need more work and right now I have other priorities.

Right now you are only one I know who is very against this change, if there was more demand for changing it, from more people, then I could consider to alter current behavior. Other wise I leave this as is.

15

OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread

« on: May 08, 2019, 08:26:55 pm »

Doesn't this break vanilla behaviour/animation cycles?

As Nord has pointed out this looks extremely odd atm, since the terrain breaks before the projectile hit animation plays out.

Might i suggest moving this change into a seperate dev-branch until this has been sorted out? I'd like to use a version of OXCE that doesn't randomly crash, but right now i'd actually prefer the game to randomly crash instead of having precognitive terrain tiles.

With what version were these changes introduced?

This is already sorted out, and tiles aren't precognitive because damage hit them at this moment. Overall gameplay behavior is exactly same as previously, only moment when animation is play was changed.

This change is important in long run, because damage calculation is done first now then it can affect how explosion will play out, that is impossible in old version.
Example could be that explosion animation is played in random places even if damage do not reach that place, in new version I could add that animations is show only where damage was done.

One thing I have in mind is do not update every tile at once during explosion. Instead do it by circualr "layer" that will simulate propagate of shock wave.