aliens

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

Pages: 1 ... 26 27 [28] 29 30 ... 33
406
OXCE Support / Re: [Question] Bullet sprites per ammo
« on: March 22, 2020, 01:19:02 pm »
First of all, sorry, I didn’t know that it’s possible to change bullet sprite from ammo item, I should look at ruleset reference closer.
With "could" I meant that I will use it with existing XCF weapons if it's possible (I realize now that it is, thank you!), its good addition for player immersion, but it is not blocking me or anything so I would be ok if its in TODO even at its bottom. Its only 2 weapons in XCF I'm talking about, so it's not a big deal. If something is blocking me, I'm asking in discord or make a forum post with a suggestion, and I'm trying to propose a solution if it's possible to do it with my skills.

But I understand what you mean, I will take forum posts and replies more seriously.

407
OXCE Support / Re: [Question] Bullet sprites per ammo
« on: March 22, 2020, 09:47:59 am »
Bullet sprites per ammo could be very useful!

408
ok, I'm just saying I think it would be good to have separate ruleset design options to restrict having 2 buildings together (no matter they are upgrades or not) and another option to make upgradable unique building

409
because if you really cant build them together, you cant upgrade one to another, it goes to `_disabledFacilities.push_back(rule)`. I would, actually, keep it separate, for you would not be able to build, say Psi gates on your base if you already have, I don't know, Arcana gates. And I like it goes to the disabled list because it does not pass `cantBeBuiltWith`

410
I paste here a simplest test case I can think of:

1. you can build a small radar from scratch
2. you can build a large radar from scratch
3. you can upgrade a small radar to large radar
4. you cannot build 2 small radars
5. you cannot build 2 large radars
6. you cannot build small and large radar together

I hope this is a complete example and can be used for testing, regardless of chosen implementation.

I think all that doable with current OXCE with `maxAllowedPerBase` and functionalities. I'd like to add:
7. you can upgrade small radar to large radar, but there is no possible way to have them both at the same time.
for that, it split these cases, but they must be all true with the same ruleset
7.1 you can place large radar on small radar (currently possible with `buildOverFacilities`)
7.2 you cant build large radar as a separate building if you already have small radar, thus having 2 of them at the same time (solved with `isUpgrade: true`, so you can replace the facility. if it has `maxAllowedPerBase: 1` case solved)
7.3 you cant build small radar if you already have large radar, thus again having 2 of them at the same time (solved with `cantBeBuiltWith`)

411
Is my solution bad? It is really tiny and has no such limitations. It is not making for just XCF, one-day modder will come asking to free him from that. Also, modder will be free from functionality stuff that is also used widely for research and manufacture - and in complex mega mods that can do additional mess

412
Of course no, it just prevents me from building the second building, no matter who comes first. For unique upgradable buildings, we need both, as far I can see.

413
No, we can't.
That functionality is not in OXCE yet.

Ok, but we could, for example, with that

414
That's what I meant too.
All upgrades are currently normal facilities, you can't have a facility which is only an upgrade.

cant we? =) https://openxcom.org/forum/index.php/topic,8022.0.html

415
yes, but then I still can build advanced one next to normal and still break things

416
because without it, as I said, you can build upgrade building not on top of the upgradable, but on another tile. thus, I can build advanced HQ next to normal and have 2 at a same time at the same base. And this is what we want to prevent.
At the same time, if uniqueness constraint will not allow us to build an upgrade next to the original, I can't see how can we allow to make upgrades...

417
Upgrades do not count, I did this rules on pure vanilla (the screenshot was done exactly on that rules I posted), that my radars are not upgrades, but just separate buildings...

418
Regardless of how the problem with facility uniqueness constraint can be solved (https://openxcom.org/forum/index.php/topic,8017.0.html), we in The X-Com Files need another property for our facilities.
See, we want straightway to upgrade one building (say, HQ, or Bio Lab) to its advanced version without permitting the player to be able to build any other copies of that building - in other words, the player should have either normal HQ, or advanced one at a time, without any other options. We also have more such buildings. Currently, if player desire, even with a uniqueness constraint, that I mentioned above, the player can build normal HQ, and then advanced next to it, thus, having both of them at a time.

To solve this problem I would like to suggest this small addition to the code. Proposed syntax:

Code: [Select]
  - type: STR_CYBER_HQ
    maxAllowedPerBase: 1
    isUpgrade: true #default false
    buildOverFacilities:
      - STR_HQ

Here is a solution I can imagine at the moment:

https://github.com/MeridianOXC/OpenXcom/compare/oxce-plus...FinnikXCF:virtualCraft


Additionally, I think, we can check onLoad if `isUpgrade: true` was set, but there are no `buildOverFacilities:` defined. If so, stop loading with error for modder:

Code: [Select]
[21-03-2020_19-25-52] [INFO] Loading rulesets...
[21-03-2020_19-25-58] [ERROR] Error processing 'STR_LARGE_RADAR_SYSTEM' in facilities: Facility has property isUpgrade set TRUE, but buildOverFacilities property was not defined!

I would really appreciate feedback and comments!

419
Yes, I tried that...

Code: [Select]
facilities:
  - type: STR_ACCESS_LIFT
    spriteShape: 2
    spriteFacility: 17
    lift: true
    provideBaseFunc: [funcA]
    buildCost: 300000
    buildTime: 1
    monthlyCost: 4000
    mapName: XBASE_00
  - type: STR_SMALL_RADAR_SYSTEM
    spriteShape: 2
    spriteFacility: 21
    requiresBaseFunc: [funcA]
    provideBaseFunc: [funcB]
    buildCost: 500000
    buildTime: 12
    monthlyCost: 10000
    radarRange: 1695
    radarChance: 10
    mapName: XBASE_04
  - type: STR_LARGE_RADAR_SYSTEM
    spriteShape: 1
    spriteFacility: 22
    requiresBaseFunc: [funcB]
    forbiddenBaseFunc: [funcA]
    buildCost: 800000
    buildTime: 25
    monthlyCost: 15000
    radarRange: 2577
    radarChance: 20
    mapName: XBASE_05



What am I doing wrong?

420
The first motivation here was to provide properties for upgrading unique facilities. Like HQ should be one per base and have an upgrade into Cyber HQ (i want to make the same for intel and bio labs here to make advanced versions of them). So we have rules like this:

Code: [Select]
facilities:
  - type: STR_HQ
    spriteShape: 1
    spriteFacility: 317
    provideBaseFunc: [BIOLAB, INTLAB]
    buildCost: 3000000
    buildTime: 40
    monthlyCost: 20000
    canBeBuiltOver: true
    maxAllowedPerBase: 1
    storage: 25
    labs: 5
    rightClickActionType: 3
    radarRange: 10800
    radarChance: 2
    mapName: XBASS_22
    listOrder: 6830
  - type: STR_CYBER_HQ
    requires:
      - STR_CYBER_HQ
    spriteShape: 1
    spriteFacility: 874
    provideBaseFunc: [BIOLAB, INTLAB, AI]
    maxAllowedPerBase: 1
    buildCost: 4000000
    buildTime: 50
    monthlyCost: 40000
    buildOverFacilities:
      - STR_HQ
    storage: 25
    labs: 10
    manaRecoveryPerDay: 2
    rightClickActionType: 3
    radarRange: 10800
    radarChance: 3
    mapName: XBASS_33
    listOrder: 6832

I tried to use `forbiddenBaseFunc` in different ways, but I can't make it work.

Pages: 1 ... 26 27 [28] 29 30 ... 33