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.


Topics - Finnik

Pages: [1] 2 3
1
OXCE Bugs FIXED / [FIXED] Amiga thinking divide by 0 base unit TU
« on: September 30, 2024, 05:54:06 pm »
Found a potential crash for feature https://github.com/723Studio/OpenXcom_FTA/commit/4e88674019846454586011a8ccf7179edac782f0

total += bu->reselectAllowed() ? bu->getTimeUnits() * 100 / bu->getBaseStats()->tu : 0;

Some units that act like a furniture for player to kill (like I have it, as I don't like specific tile destruction mechanic in vanilla) might have tu: 0 in their ruleset, that produces a crash, as there is no checks for it.

2
This feature can enable modders to create diverse lore and background for different types of base defense missions (that are technically already possible with new features like https://openxcom.org/forum/index.php/topic,11429.0.html and https://openxcom.org/forum/index.php/topic,10808.0.html)

Currently, the game uses can spawn alien mission for base defense encounter, that specify the UFO to "land" near the base. Battlescape encounter uses base to generate the map and `alienDeployment.data` section of the landed UFO to generate enemies (race taken from alien mission). But the briefing data is hardcoded and can't be modded.

Possible design - make a new property in `alienDeployment` rule to override vanilla logic and use briefing data from UFO's `alineDeployment.briefing` (currently, it is ignored), like it is done for terror missions.

3
OXCE Suggestions DONE / [DONE][Suggestion] Ladders / climbing
« on: March 21, 2023, 01:04:59 pm »
[Suggestion] Gravlift not only for floor tiles
----------------

While creating a level design for my craft, I faced with a code vs. design problem - I wanted to make a side ladder to deploy troops from the hatch of the craft, but in order to make a ladder I actually must define it not in object (ladder), but only for the floor tile type.
I know, currently modders live with that, but I don't think it is very good:
1) If the ladder tile was destroyed, but floor tile is ok - gravlift will still "magically" (for the player) works.
2) As a modder, I need to define floor image, as craft map will replace floor tile of the landing zone's floor tile, which is not very good - I want my craft ladder even don't touch the ground with keeping original landing zone tile as is.

I looked at the code, but was a bit confused - it looks like a simple check in gravlift code for working only with floors. I altered it, but it turns to be not working. Also, this tile engine part is still very scare to me to touch, and I have no idea why this restriction was originally placed.
You might want this change in OXCE, as such gravlift ladders appear in different mods, but if you don't - an advise for implementation of such a feature would be also super appreciated.

4
From the Ashes / Alien weapons art style
« on: February 25, 2023, 02:06:08 pm »
While I'm finishing core engine features for the next huge release, I've started to think about more content, especially for aliens.
I want to choose art style for my alien's weapons and I want to know what you guys feel about it: https://forms.gle/T3wx8YU1LTyXwecCA

5
OXCE Suggestions OK / [SUGGESTION] Spawn crafts in hangars on base defense
« on: November 26, 2022, 11:19:34 am »
I know that this topic has probably been discussed more than once in the OpenXcom community. And since there's nothing like that in the game so far, it's likely that such suggestions have been rejected repeatedly. However, I would very much like to get an up-to-date status from the OXCE developers, also to take this into account in planning my own activities. Like many (it seems to me) players, I wondered how it was possible to completely evacuate base personnel and crafts in such a swift alien assault. But after seeing these screenshots of the original game's modification recently, I can't stop thinking about a new game feature that would display the player's ships in the hangar.

(source: https://www.strategycore.co.uk/files/bbs-toolkit/)
Aside from the aesthetic component, this would provide aliens with additional cover in the hangars.
I think I can more or less imagine a significant amount of work to implement such an engine feature, there will be a lot of problems - you need to check the size of the kraft map, center it (of course, check if there is a map for it at all).

6
From the Ashes / Suggestions
« on: September 15, 2022, 08:30:34 pm »
At this point I very welcome any suggestion from the community. Please, feel free to share your ideas here.

7
Rejection reason: this is beyond/outside the scope of OXCE


I've just got an idea to call `void Soldier::die(SoldierDeath *death)` from the geoscape event. The idea is pretty raw, but I want to know your opinion, guys. There would be in issue to define SoldierDeath tho, but I think it could be fun to have some creativity here. For instance, a soldier can choose to leave the X-Com project if low score (low opinion on the project), can die because of super heavy wounded or infection because alien monster bite - modders could have a wide variety of applications. I would definitely use this in my project. Feedback welcome.

Would require some work, I know - defining soldier name in the event description text as a parameter, some model for defining soldier death case.

I also know your @Meridian opinion about removing items on event, but I think with `die()` method it is easier to do. Please, correct me if I'm wrong.


8
Programming / Question - how to cleant #includes
« on: July 15, 2022, 08:34:22 pm »
Is there any free tool to check if there are unused includes in some classes in my project? I can only find ReShaper C++ https://www.jetbrains.com/resharper-cpp/ that is not free to use. I don't want to pay $150 for it every year =)

9
Hey!
Could be a rare case, but when I was analyzing code I noticed, that when you `void Production::startItem(Base * b, SavedGame * g, const Mod *m) const` and your project require the craft, it would be removed and deleted. But when we look to `refundItem`, we can see that there is no way to refund the craft in case we abort construction.

I understand how coplicated proper handling of this case, you can stuck with no free hangar space. But may be at least warn the player about consequences?

10
I'm considering if there is a way to define more complex shape for units, like we can define it for tiles. AFAIK, now it's just a cylinder with height, defined with property. But I think there can be a way to define voxel model with yaml ruleset in unit or soldier property
Code: [Select]
units:
  - type: STR_SECTOID_SOLDIER
    race: STR_SECTOID
    rank: STR_LIVE_SOLDIER
    stats:
      tu: 60
      stamina: 90
      health: 30
      bravery: 80
      reactions: 63
      firing: 54
      throwing: 58
      strength: 20
      melee: 12
      psiStrength: 60
      psiSkill: 20
    armor: STR_SECTOID_STANDARD_ARMOR
    standHeight: 16
    value: 15
    standingLOFT: [2, 2, 2, 3, 3, 4, 4, 4, 3, 0, 0]

Numbers define LOFT id's from LOFTEMPS.DAT file (see attachment)
In this case, we can fix some common problems when default collider does not reflect image asset completely. I'd also suggest in this case to keep weapon handob image offset to be still calculated with `standHeight`.
For Instance, that can solve problem, that is highlighted here https://openxcom.mod.io/reavers-fixed-hitboxes
I would also suggest ignore unit rotation for more simple solution. Still, it would help to make new enemies more interesting and help in terms of visual improvement of the game in terms of displaying projectile hits.

11
I thought it might be in scope of OXCE QoL improvement - what about adding action on MMB click for line of `_lstStores` text list to open Pedia state if any (like what we have in purchase/sell states)?

12
OXCE Support Y-scripts / [Solved] Expanding UFO tracking lost logic
« on: April 28, 2022, 09:49:48 pm »
I've got an idea and I think it can be used in some OXCE mods.
Currently, we have logic that if UFO gets out of radar range, you lose its tracking. But in some mods, like XCF, for example, we have radars with global range (that is balanced with very small detection chance), so basically, we can't lose tracking. In addition, not tracking chance is scriptable, so we can create interesting features around it.
I think losing tracking and searching for UFO with crafts is a fun mechanic, so I'd suggest some logic for UFO in `time30minutes`, that would give UFO chance to break tracking if chance for its detection is very low. OFC, we can define that "very low" as an integer value in mod, that would be also a feature toggle.

13
Abandon reason: not worth the effort; and not enough interest

Currently, we have rather simple logic to calculate consumed base's living space. That's fine for vanilla, but in OXCE mods we have a lot of pretty different creatures, from tiny AI-controlled drones to giant monsters.
What do you think about adding a new property to define using space? For instance, we could make `requiredLivingSpace: int`, from 0 for tiny drones to 4 for monsters, with 1 as default value.
I think it is not so hard to add  :)

14
From the Ashes / From the Ashes META
« on: April 21, 2022, 06:04:19 pm »
This tread is created for players to share their insights, tips and efficient tactics.
Because FtA has a lot of new mechanics, I think it would be useful not only for players, who want to improve their performance or stuck with a problem, but also for me to take those insights into account for making better game balance!

15
From the Ashes / FtA game engine
« on: April 17, 2022, 09:16:00 pm »


As you might know, FtA uses own engine, that is a fork from OpenXcom Extended repository.
Two years ago I decided to develop my own fork because the goals of my project are different from those of OXCE.
The main value for the FtA project is to provide a completely new gameplay experience within a classic game. In terms of visuals, I'm doing my best to make it seem like my game is some kind of DLC (in the modern sense) to the original game. It would be ideal if a person who hasn't played the original game couldn't tell the difference between the content of the original game and the new one. As for new features - I don't want to stifle source code changes by supporting backward compatibility for other mods.

From a modder's point of view, my engine only differs from OXCE because of the new rollset properties. Although I don't strictly adhere to the doctrine of minimizing unmodified changes compared to vanilla as OXCE developers do, when run with default settings FtA engine is compatible with all OXC/OXCE mods (as far as I know).
All incompatibilities and the most significant features are protected by mod's base property `ftaGame: true` (default false). Turning on this property opens Pandora's Box, implementing new logic and most mechanics. Some properties start working differently than in OXC/OXCE. I maintain detailed documentation on the project, you can find it on engine repository wiki https://github.com/723Studio/OpenXcom_FTA/wiki
There, I highlight every case of non-standard behavior with value `ftaGame: true`. 
Not all new mechanics are blocked by this property. Additionally, I try to regularly merge with new changes in OXCE, making edits when incompatibilities arise (each time praising Yankes's ongoing refactoring crusade, rejoicing at every change in how existing methods work). So far I've been able to implement all the new features from OXCE, but I can't 100% guarantee that this will continue in the future.
So if you for some reason would like to use my engine for your mod - I'm not against it at all, but please note - I'm developing this engine for my project only, other goals will be secondary for me. If you would like to suggest that I create a new feature, you would need to explain to me why I need this feature in FtA and not in your mod.
Also, I'm not very willing to implement general functionality. For example, I developed a mechanic for reinforcements, and then 6 months later a similar feature appeared in OXCE. Now I have to maintain two solutions at the same time, because they had fundamentally different solutions on a fundamental level, and the OXCE solution didn't work for me. The same thing happened with VIP, now I have two types of VIP in my engine, which have very similar names but work very differently...

Although only about 60-70% of what I had in mind is realized, I am proud of the progress I made over these few years (because I started to change the engine code without knowing how to program at all). I want to say a huge thanks to everyone who has supported and helped me - Yankes, SupSuper, Meridian, Warboy and Ohartenstein, as well as to the guys who are directly involved in the development - Buscher, PedroTerzero, Isotop and Drosan. You rock!

Pages: [1] 2 3