I was creating a quest in 2.50.2 and part of it included a bomb lweapon produced by script. However, for some reason it wasn't setting off the onscreen flag for Bomb (Any). Here's a link to a copy of the quest.
https://www.dropbox.com/s/0hlebo9cx7gvvsk/originsbug.qst?dl=0
The item which gives the bomb ability is a bomb, but you must also have the item labeled morph ball to use it. The screen where this occurred was on map 2, number 55.
that has to do with the bombblast them selves. If it wasn't created by a bomb or sbomb. I don't even think it counts?
Tamamo wrote:that has to do with the bombblast them selves. If it wasn't created by a bomb or sbomb. I don't even think it counts?
Well, it still kind of feels like a bug to me. Especially since other lweapons produced by script (such as the candle flame) do trigger their flags.
it is a bug, let me rephrase what I say.
explosions created by scripts are treated have are different weapon type, or is it ID i forget? from the ones the actual bomb weapon makes. "those are different btw."
Scripts won't be able to differentiate between those though sadly. And I doubt we'll ever officially work on 2.5 anymore now that we've started 3.0
Tamamo wrote:it is a bug, let me rephrase what I say.explosions created by scripts are treated have are different weapon type, or is it ID i forget? from the ones the actual bomb weapon makes. "those are different btw."
Scripts won't be able to differentiate between those though sadly. And I doubt we'll ever officially work on 2.5 anymore now that we've started 3.0
The weapon types that I've seen, are wBomb, wBOOM, and wLitBomb (for normal bombs), and wSBomb, wSBOOM, and wLitSBomb (for super bombs). I'm not sure which is used by sBOMB and mfBOMB though, nor am I sure what LW_BOMBLAST creates, but the scripted bomb should be treated as a wLitBomb, and should do wBOOM when it explodes, despite being created bys cript; so I'll need to figure out where to look for this.
This could be corrected with a slight revision either to bombs themselves, o where combo flags are handled.
I need to find where mfBOMB is handled on the ZC side. There's some stuff for it in maps.cpp, but that's just findtrigger(), and I need to find the specific resource where the mapflag detects the bomb type. zdefs.h has all the enums for mfBOMB and sBOMB, but it's just a mad, mad, maze.
I'm not sure which would be better. Fixing bombs might be, as they could have other inconsistent behaviour, that fixing this on the flags side wouldn't rectify however, fixing the flags is easier. Doesn't matter much at present, as I can't do a flipping file text contents search on this system.
Correcting the combo flags is probably a ten minute fix if I can find them. That's the time-waster.
The thing is, that wLitBomb creates wBOOM. I need to find out what creating LW_BOMBLAST makes (as an internal weapon), if not wBOOM. The real trouble is tracking down all the places that need revision, and the definitions of secretcombo[sBOMB] and secretcombo[sSBOMB].
Sigh.
Tamamo wrote:it is a bug, let me rephrase what I say.Scripts won't be able to differentiate between those though sadly. And I doubt we'll ever officially work on 2.5 anymore now that we've started 3.0
The reason Gleeok and Saffith are now working on 3.0 is because it would speed up the development of 2.5. 2.5 is open source. That means that it is like zscript itself, in that you have a bunch of different versions floating around, and you have to try and combine them if you want them all.
I noted on further testing that the scripted bomb will set off the bomb flag... if it is generated directly on top of the flagged combo. But it doesn't set it off if placed directly above, below to the left or the right.
ywkls wrote:I noted on further testing that the scripted bomb will set off the bomb flag... if it is generated directly on top of the flagged combo. But it doesn't set it off if placed directly above, below to the left or the right.
Do me a favour, and check if this is also true in overhead, or if it is only a bug in sideview mode.
Dimentio wrote:The reason Gleeok and Saffith are now working on 3.0 is because it would speed up the development of 2.5. 2.5 is open source. That means that it is like zscript itself, in that you have a bunch of different versions floating around, and you have to try and combine them if you want them all.
Let me say this again. 2.5 hasn't been open sourced yet. THe current source code 3.0
Tamamo wrote:Let me say this again. 2.5 hasn't been open sourced yet. The current source code 3.0
2.5 is currently in the process of being open sourced. There is even a new set of team members working on 2.5, myself and Zoria included. 2.5 is not dead, it just has a new set of developers and will be going Open Source soon as well.
Tamamo wrote:Let me say this again. 2.5 hasn't been open sourced yet. THe current source code 3.0
This is technically correct. I have no idea why it's a topic for this thread though.
I'm still unsure how best to fix the bombs issue, so I welcome suggestions. Both of you have the code, so instead of debating whether 2.5 is a technically open-sourced thing, energies devoted to that could be directed towards the practical application of solving this...ya know?
To anyone with sufficient privileges of making new 'child-boards':
I'd appreciate if we could have separate bug report boards for, for 2.x and 3.x.
That's going to be mandatory at some point, and we may as well pre-empt it. In fact, I suggest splitting the dev topics board into 3.x and 2.x, directly, or making separate main boards for each. Otherwise, things will become confusing. The archived bug reports can be moved to the 2.x boards, too; as there are a few left unresolved, and I really don't want to forget what they are.
[MENTION=61261]ywkls[/MENTION]
Not a bug, in fact. Your script is the issue.
I just created both bombs and explosions using zscript and it triggered flags. Be sure you have collision detection enabled.
Tamamo wrote:[MENTION=61261]ywkls[/MENTION]Not a bug, in fact. Your script is the issue.
I just created both bombs and explosions using zscript and it triggered flags. Be sure you have collision detection enabled.
Could I see an example script and screenshot to determine what I'm doing wrong? Also, was this test done in sideview gravity?
How about you check your collision detection like i told you to. 😞
All I did was create a scripted weapon with a ffc.
Tamamo wrote:[MENTION=61261]ywkls[/MENTION]Not a bug, in fact. Your script is the issue.
I just created both bombs and explosions using zscript and it triggered flags. Be sure you have collision detection enabled.
This may be a side-view only issue. Did you test that?
Tamamo wrote:How about you check your collision detection like i told you to. 😞
All I did was create a scripted weapon with a ffc.
As far as I know, the only way to turn off collision detection is to do so deliberately and I'm not doing that.
The probable source of the issue is that I'm generating the bomb directly on top of Link, while it is likely you aren't. I have my own specific reasons for doing this, though they don't matter.
A bomb generated on top of a flag will trigger that flag, as I've already stated. However, to do that I'd have to make a separate bomb for any area that had such a flag; since there would no point in making a bombable area where you could pass right through it. Accomplishing things this way seems somewhat redundant.
As far as I can tell, a normal bomb has a certain radius that it can affect. I thought that this included the tiles one tile away from where it is placed, but maybe I'm wrong.
In any case, perhaps it would have been better not to assume I made some kind of mistake. I'm not immune to them, but this is usually due to a lack of knowledge.
ZoriaRPG wrote:This may be a side-view only issue. Did you test that?
No, I haven't done that yet. Though doing so wouldn't be too hard.
It doesn't have to do with sideview and it is not a bug. It's That your creating your bombs on top of link. That will not work. You need to be closer to the flag.
Bickering about this solves nothing: I'll play with radius, and verify if there are any irregularities. If the radius of internal bombs triggering flags differs from script-generated bombs, then it's a bug.
If we're discussing something that is desirable, but not a bug, then it belongs in feature requests, and we can handle that separately. The only thing that I need to know is if the script-generated bombs/explosions do not work in an identical manner to stock inventory.
If there's proof either way, I'll categorise this properly. I should note that this may not be a bug, but it would be a good idea to add a way to trigger these events directly. What I favour here is: TriggerSecret(int secret), and adding in a flag for Explosion combos that are triggered by contact with LW_EXPLOSION.
They should have the same collision size. Bombs have always been finicky. I'm going to take a look at them now see what I can do.
Tamamo wrote:They should have the same collision size. Bombs have always been finicky. I'm going to take a look at them now see what I can do.
Good enough. report what you discover...
I'm pretty sure that they have more tolerance (for triggers) horizontally, than vertically.
Tamamo wrote:They should have the same collision size. Bombs have always been finicky. I'm going to take a look at them now see what I can do.
Good enough: Report what you discover...
I'm pretty sure that they have more tolerance (for triggers) horizontally, than vertically.
That's to match nes behavior I'm sure. Setting the y tolerance to 16 shouldn't cause any problems though. Might actually fix it.
Tamamo wrote:That's to match nes behavior I'm sure. Setting the y tolerance to 16 shouldn't cause any problems though. Might actually fix it.
Believe me, I've considered it. The problem, with changing anything like that, is that someone out there made a quest where that would break something. Usually 'quest difficulty', e.g. 'artificial difficulty'. I mean, we already have a repetitive complaint about fixing the statue shooters from Anarchy. If I make bombs set off triggers an extra half tile, or a full tile away, people might flip out.
The simplest fix would be to expand the bit width of QRs, and add new ones to cover this sort of thing. That's somewhat messy though.
I'm thinking that making the bomb trigger radius a system variable would be better. That way, it can be set both by ZScript, and by an editor prefs pane. Even so, that doesn't allow chained triggers as I believe ywkls, and a few others want. That would absolutely need new flags, and new logic, if it's not fully-scripted. I did toss together a function for checking adjoining combos in circles, arcs, crosses, and X-es for that, but it doesn't check in lines (yet), although it can be used recursively to do that.
I'll probably put it in the standard header if it works, for 2.53. Those are ad-hoc solutions though, for some of the concerns.
If anything it would be a questrule under the NES Fixes category.
Tamamo wrote:If anything it would be a questrule under the NES Fixes category.
We need to restructure QRs, either to expand the number of bits, or change how they are stored. (I'm also of the opinion that making them r/w via script, would be ideal.)
Noe, we're not going to break every quest in existence thank you very much.
Tamamo wrote:Noe, we're not going to break every quest in existence thank you very much.
Actually, yes, we are, if it means fixing this bug.
Dimentio wrote:Actually, yes, we are, if it means fixing this bug.
I'm not going to say anything more. Just going to highlight [MENTION=42714]Gleeok[/MENTION] and [MENTION=38582]Saffith[/MENTION].
Dimentio wrote:Actually, yes, we are, if it means fixing this bug.
That would be a horrendous mistake for 2.5.
Aparently gleeok and I both have come to the agreement that this entire thread is stupid and neither of us give a shit about bomb flags. Have fun fixing what you call a bug that is actually a new feature.