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 ... 136
2
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.

3
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.

4
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.

5
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.

6
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.

7
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.

8
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.

9
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.

10
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.

11
OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread
« on: May 06, 2019, 10:30:00 pm »
Yes, this is intended, this is change made in propose of future changes and refactors.
Terrain is change because bullet physically hit at that moment, and after bullet hit/explosion animation will play.

12
OpenXcom Extended / Re: [Suggestion] requires for pages
« on: April 30, 2019, 01:07:49 am »
Changing number of pages in article based on research will be very hard. To make it correct way I would need refactor whole article handing, and nearly rewrite it from scratch.

But looking on your example, why not separate articles for each attack? Each page have nearly nothing in common with each other and have different research requirements. Goal of multi page articles was to handle one big thing that do not fit on one screen.

13
Offtopic / Re: XCOM Inspired Fantasy Game
« on: April 30, 2019, 12:59:49 am »
Why not just flood half of the island into a swamp? I see nothing wrong with it. ;)
Typical for Troll :>

14
XPiratez / Re: Allow melee to be reaction able.
« on: April 20, 2019, 07:56:14 pm »
Code already allow reaction to melee attacks. Only for backward compatibility its not active. Scripts can alter this behavior to enable reaction.
This mean you can encode if you are kung-fu masta nobody can react to your attacks.

15
Offtopic / Re: XCOM Inspired Fantasy Game
« on: April 20, 2019, 07:47:48 pm »
One solution would be not use hex but triangles, if they are arranged in hex then you keep all hex good properties but you still can have orthogonal moment.
Trick is that 1TU allow you to move thought 2 triangles. I added small graphic that show this, All red dots are valid unit positions, black lines are allowed "half" moves. Effective this is multiple hex grids overleaped on each other.

Pages: [1] 2 3 ... 136