361
The X-Com Files / Re: Dossiers wanted!
« on: July 30, 2020, 11:10:29 pm »
Hm, usually you'd better keep careful taking Firaxis XCOM content...
Welcome, Guest. Please login or register.
Did you miss your activation email? April 29, 2024, 05:22:07 pm
Did you miss your activation email? April 29, 2024, 05:22:07 pm
News: If you can't login, please contact us with your username and e-mail so we can fix it.
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.
362
Resources / Re: Unit Battlescape Reference Sheet
« on: July 27, 2020, 02:00:27 pm »
I wish one day we could have some automation tool that would help us drawing these sprites with compressing it to a unit... 
363
OXCE Suggestions DONE / Re: [SUGGESTION] item category check for y-scripts
« on: July 26, 2020, 06:48:21 pm »
^ _ ^
364
OXCE Suggestions DONE / Re: [SUGGESTION] item category check for y-scripts
« on: July 26, 2020, 12:33:21 pm »
Pretty much, as I said, it is a QoL for a scripter, so you don't have to assign the same tags over and over again adding a weapon to some custom category mechanics, but use data you already imputed.
365
OXCE Suggestions DONE / [DONE][SUGGESTION] item category check for y-scripts
« on: July 26, 2020, 01:51:29 am »
I would like to share my first tiny step into coding y-scripts. Many thanks to Yankes for inspiration and guidance!
https://github.com/MeridianOXC/OpenXcom/pull/72
The point here was to add a little QoL for a scripter that is working with many items. If you want to add some specific behavior to all items it one category, with that you do not have to add repeating tags to any item in the category, but add a single category check in the script itself. Let's say, we want to mod all our sniper rifles have some special behavior. Instead of adding tags to all of them defining it as a sniper rifle, you can use already most likely defined category item property.
So, an example of a script:
UPD: method renamed to `hasCategory`
https://github.com/MeridianOXC/OpenXcom/pull/72
The point here was to add a little QoL for a scripter that is working with many items. If you want to add some specific behavior to all items it one category, with that you do not have to add repeating tags to any item in the category, but add a single category check in the script itself. Let's say, we want to mod all our sniper rifles have some special behavior. Instead of adding tags to all of them defining it as a sniper rifle, you can use already most likely defined category item property.
So, an example of a script:
Code: [Select]
extended:
scripts:
damageUnit:
- offset: 1 #test category script
code: |
var ptr RuleItem itemRuleset;
var int check;
damaging_item.getRuleItem itemRuleset;
itemRuleset.hasCategory check "STR_SNIPER_RIFLES"; #returns 1 if defined category found in item's arrey; else returns 0 if the item does not belong to this category
if eq check 1;
debug_log 2 723;
# do our stuff
end;
return;
UPD: method renamed to `hasCategory`
366
Offtopic / Re: Footage of real XCom ufo interception.
« on: July 25, 2020, 12:09:35 am »Self replicating robots, especially ones produced with the advancement in genetics engineering, will produce exponential growth. On galaxy scales. Surpassing previous industrial and computing revolutions. Or maybe humanity lives its last days. Since modern technologies are very dangerous, and could be used to wipe out everyone, when used by stupid people for minor gains. I.e. even minor scale terraforming can potentially lead to large scale destruction. For example, USSR managed to wipe out whole sea from the face of Earth as part of its terraforming project: https://en.wikipedia.org/wiki/Aral_Sea once a beautiful and rich region is now a desert.
A several decades ago computers were very big, expensive, inconvenient, available only to big universities and large corporation. These computers cost several millions of USD. Computing time had to bee booked.
Now everyone has in his pocket a smartphone, which is more powerful than any of these computers.
Even more, such smartphone offers far more value and has a far more diverse set of applications, than these older computers.
Literally today's people are millionaires in some sense, and have access to something, even billionaires of the past had no way of getting.
Now imagine you can own a personal star. There are a lot of stars in the observable universe. Enough for everyone.
Or take computers graphics for example. In a few decades it evolved from simple few polygon scenes to photo-realistic scenes. Latest advances in AI allow real-time graphics like following
367
The X-Com Files / Re: Alien Embassies
« on: July 12, 2020, 09:49:14 pm »
When coming to old it spawns much fewer missions, but they're still a chance
368
The X-Com Files / Re: Alien Embassies
« on: July 12, 2020, 08:14:37 pm »
There are 2 clinic types, each with own reward, you need both
369
The X-Com Files / Re: Alien Embassies
« on: July 12, 2020, 05:53:52 pm »
Infiktration is signing a secret pact, its not about democracy and public opinion...
370
The X-Com Files / Re: Alien Embassies
« on: July 12, 2020, 02:37:17 pm »
Yeah, I know. But what about alien base construction? It was always fun for me when aliens make a survey with small ships first, and then build their base no matter if xcom destroy all their battleships, that covering mission, so the player just farming this mission. I think, more natural if aliens would decide that this site would not fit for their secret base =)
371
The X-Com Files / Re: Alien Embassies
« on: July 10, 2020, 01:39:54 pm »No, the code doesn't allow that.
hm, I thought we can define if aliens would like to cancel their mission because some ufos were shot down, can be done with `interruptPercentage` property in `waves`, I believe.
And also it wouldn't be very sensible, if a country wants to ally with the aliens, shooting some vessel wouldn't make them change their mind.
I personally count its fair to me as a player and I always play with some % of interrupting in alien base and infiltration missions in the form of my personal submod to basically any mods or vanilla I'm playing. Though, I remember we talked about already, so not like I'm pushing anything...
372
OXCE Suggestions OK / Re: Jumping movement type
« on: July 08, 2020, 02:28:13 am »If I understand your clip well, then it's something very much like jump movement from 40k - not true flight, but close enough.Yep, that is pretty much what I want it for FtA. Though it's a part of the code that scares me a lot, so I don't really want to make it exclusive to FtA, besides the idea may have consumers in other OXCE mods.
This simple solution does not fit the case where we want monsters to jump on the roof where you hiding, as this allows us to draw a complex path trajectory. Still, I wanted to show how I imagine players or AI choose tile for the end of such a movement.
373
OXCE Suggestions OK / Re: Jumping movement type
« on: July 08, 2020, 12:29:43 am »
That is a very dirty hack to the code that could more or less demonstrate what I want to achieve. I can perform pathfinding like I'm flying, but I can't stay in a floating state, forced to end movement on the ground. This is not ending solution OFC, as I just changed one line in void Pathfinding::calculate
As it is working on the demo is more like what I personally want for my mod, as don't want the player to cheat melee enemies too much, and it would not fit general solution as is, as for most cases people would like to see jumping it should not allow such a complex trajectory. But this is what I meant for defining the endpoint of a jump.
There is much more work needed here, as even in the demo it was shown that if I have not enough TU I will still stay floating, this case as many others need to be handled, I can understand that.
Code: [Select]
126 while (canFallDown(destinationTile, _unit->getArmor()->getSize()) ) //&& _movementType != MT_FLY
As it is working on the demo is more like what I personally want for my mod, as don't want the player to cheat melee enemies too much, and it would not fit general solution as is, as for most cases people would like to see jumping it should not allow such a complex trajectory. But this is what I meant for defining the endpoint of a jump.
There is much more work needed here, as even in the demo it was shown that if I have not enough TU I will still stay floating, this case as many others need to be handled, I can understand that.
374
OXCE Support Y-scripts / Re: More ModScript examples
« on: July 07, 2020, 07:15:56 pm »
For now, I was only using tag loads, things like getting an attacker unit or damaging item. Now sure how expensive those operations are.
375
OXCE Support Y-scripts / Re: More ModScript examples
« on: July 07, 2020, 05:11:53 pm »
I've always wondered how noticeably y-scripts can affect game performance? After all, some are called quite often (each frame). Are there any recommendations about this, restrictions? Say, if my y-script will consist of 5 thousand lines of calculation code? Or 10? Could there be a difference between hooks?