Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Extra2, how I loathe thee
Today's question/rant is brought to you by the letters 'E', 'x', 't', 'r' and 'a' and by the number 2.
Before I get into the main rant, does anyone know whether it is possible to combine extra2 values 1-5 (indicating colour weakness) with extra flags 1000-1200? (One would naively assume... well, (sigh) one could very naively assume a lot about this game, but we won't go there )
...Anyway... I am naively hoping it is a bit field, but assuming it probably isn't. After all, if it were even a measily 16 bit number, you have easily got room for the 200 extra2 flags (8bits worth with 56 values wasted). Then, even using individual bits for each of the 5 weapons (which would be much better way than the current system as you could then say exactly which colours do hurt the sprite), you still have 3 bits left we could use for my request for a solution to the below problem.
So - the problem:
I have some sprites and they are not solid I want them to disappear when somebody flicks a switch (or blows something up, if that has to be done, I don't care too much, but would rather it was a switch). Unfortunately, they don't because (as the manual clearly states), sprites with a solid state of 0 or 1 don't get removed when you trigger an extra2 link - instead they get made black (woo-hoo, they already are) and have their script removed (woo-hoo again, they already have no script).
I figured I could work round this by using solid type '2' which is still effectively not-solid for what I care about in this instance. The manual doesn't actually document what happens to those sprites when they have their extra2 links triggered.
The answer (as I'm sure you're all dying to hear) was rather unexpected. If you trigger by blowing something up, solid-type 2 behaves like 0 and 1 - i.e. turns black. Nothing fancy, but disappointing as I wanted it to behave like 3/4.
If triggered by a switch on the other hand, the entire level turns black, and everything on it becomes not-solid. I seem to remember reading about this somewhere else, though I forget whether it was someone trying to work out how it happened or had found out why. Ah well, if the former, here's why.
(Edit - misdiagnosis - I think I must have fallen into the "switch called 'Sprite' trap" whilst testing - it appears now that switch extra2 links don't do anything at all to any solid-type sprites as had previously been mentioned)
Does anyone know of a way to fake up what I want to happen? The only way I can think of to make it work is to have all the non-solid sprites by children of another 'enemy' sprite which itself has an extra2 link to something further away I can blow up. It works in theory too - but unfortunately, the area of the child sprites is too large, so they get culled when the parent goes off-screen
If not (question to the beta testers out there) - is there any reason why the game can't change extra2 links to player type objects to remove as if they were enemy/solid?
Or better (but more work) would be to add (shock, horror) another flag which if present, overrides the default behaviour concerning what happens to a sprite after its extra2 link is activated. Overriding is obviously important so that it doesn't break anything in existing maps. Again, see suggestion with extra2 above.
If you're still reading, thanks for putting up with my ranting
(edited for typos)
This post has been edited by Crono : 24 February 2007 - 12:25 PM
When the whole level turns black, the switch made the sprite change black/not solid. The sprite's was probably Sprite, and so the rest of the level, so I believe that because the sprite turned black/not solid, also all the other sprites named "Sprite" turned black/not solid. Also, no, it is not posible to keep the Extra2 of which color hurts it at the same time as Extra2 1XXX. I think the BETA testers should add this to the list. Other than that, I don't know the rest, but would like to. -FF
This post has been edited by FireFalcon : 24 February 2007 - 12:03 PM
@firefalcon, on Feb 24 2007, 05:02 PM, said in Yet another editor question:
Ugh - I'm was fairly sure that the switch wasn't called "Sprite" because I had given them all names to test the removing feature. That said though, I couldn't reproduce it so I guess it must have been.
Apologies for the misdiagnosis.
@crono, on Feb 24 2007, 04:59 PM, said in Yet another editor question:
Hm, what happens when the objects are the childs of the switch?
I'm not really understand this. You want Extra2 links to do the same to player sprites as to enemy or solid sprites, right?
@freq245, on Feb 24 2007, 05:56 PM, said in Yet another editor question:
It would probably work, but it doesn't matter since the area covered is too large for any parent/child link to work due to culling.
I was suggesting (as a quick-dirty hack/fix) that player (2) acts like enemy (3) (when you destroy and extra2 link) in that the sprite is removed completely (or made invisible and not solid, and/or moved to layer 10 or whatever means is used to do this) when the extra2 link is activated.
Much better though would be to have flags which govern what happens.
For example, things that one might want to toggle are
solidity (or even "change solid-type to 'n'") visibility (or even change transparency to 'n') AI on/off (or even "change AI to 'x'")
However, that is starting to use many more flags and number-ranges, and hence would probably be better done with different AI's to handle transitions (assuming one could make ones own AI's).
So just the basic flags as to whether to independently toggle each of those (hence three flags) would be great. As I was saying, it looks like there ought to be space in good old extra2 for those three.
This post has been edited by Crono : 24 February 2007 - 01:23 PM
For the color-vulnerability + extra2, what I did in Shooting Gallery is to have the shootable sprite be color-specific, and then have a child sprite with the desired extra2 link.
For the rest, if I understand what you're saying correctly, it looks like the same issue I had with Obstacle Course Circuit Challenge. Currently, extra2 links to solid sprites make them solid and black IF they are within culling distance when the link is triggered, and not solid/invisible IF they are OUT of culling distance. I'm told the latter behavior will only work on doors in 1.01, though (see the thread I linked).
@cheleball, on Feb 24 2007, 06:43 PM, said in Yet another editor question:
True, that's my current work-around too, but it is hacky and involves me having to keep naming lots of child/parent pairs which is annoying.
Nope, my point is the I have sprites A, B, C, D....ZZZ which are all not solid, black, and have no script to begin with. Regardless of how I trigger their extra2 links (i.e. whether it is by switch, pick-up or blow-up of a related extra2 sprite) they always remain not solid, black and have no script. It makes no difference whether the trigger happens when they are culled or not.
(sigh) Thanks for the suggestion though. And I missed that course somehow! Must try it at some point. I think that you had taken the link away quite a long time before it was finally available to download
@crono, on Feb 24 2007, 11:18 AM, said in Yet another editor question:
Any single parent-child link. I suspect that you could set it up with some-odd dozen parent sprites, none of which is more than a couple hundred pixels from any of its children.
Still, the lack of options for Extra2 links (and of the ability to combine vulnerability to a color and an Extra2 link) is somewhat annoying. Given the number of digits possible in the Extra2 field, I don't see any reason why it couldn't be turned into some form of flag field (seven flags, up to ten options each?). With a few modifications to the editor, this could be done completely transparently.
Edwards
@edwards, on Feb 24 2007, 07:19 PM, said in Yet another editor question:
That is an excellent idea. Why on earth didn't I think of it?! Many layer-10 parents all with the same extra2's that are enemies/doors and hence get deleted by extra2 link. It's hacky and is going to be really annoying due to the sheer number of children... but...
indeed.
Okay, I have another question.
Is it possible to change the layer that the player's sprite is in?
From what I can work out through experiment, it seems to be effectively in layer 1.5 (i.e. hidden by layer 2 objects), whilst the bullets seem to be in '2.5', and the thruster effect in 3.5, shield blink for when you are hit in 4.5.
Are any of these configureable in any way? I don't really want to dynamically change it, thought that in itself would be neat - but I'd really like to be able to have 2 'background' layers
There are currently bugs with some Extra2 behaviors, especially when triggered by switches, that are fixed for 1.0.1, so I don't recommand looking too deep for the precise (weird) behavior, because many of these behaviors are bugs (for those who know about it, much like the ShipColor issue in EV Nova 1.0.7, we played with that for the pleasure of figuring out…). Especially consistency has been enforced most everywhere (there is one exception, in that the behavior can be different with a switch name link and an Extra2 link, it is on purpose for having more options available).
Oh, and both Extra1 and Extra2 (contrary to what we are used to in Nova, i.e. 16-bit integers) are 32-bit integers. I can distinctly hear you scream from where you are at the merciless waste of bits and information caused by this limiting Extra2 system…
@zacha-pedro, on Feb 24 2007, 08:51 PM, said in Yet another editor question:
Oh, and both Extra1 and Extra2 (contrary to what we are used to in Nova, i.e. 16-bit integers) are 32-bit integers. I can distinctly hear you scream from where you are at the merciless waste of bits and information caused by this limiting Extra2 system
:huh:
GAAAAAHHHHHHHHHHHHHHH!
But actually, this isn't too bad - it means that in v2, it can have a top bit act of an extra value act as a flag (0) brain-dead, 'my first 6-year-old's very first computer program, ever' storage mechanism and (1) vaguely sensible bit-field.
That way we can have prehistoric compatibility
TBH, I thought that maybe a value for the AI might actually stored in the other 'wasted' extra2 bits along with whether the sprite should act like a 'switch'. Just goes to show the naive assumption thing again.
(sigh)
Now... tell me that during the game, it at least makes a hash of the sprite names and just does numerical comparison when checking switch names... or creates a parent/child and switch/door/other tree in memory...
Please tell me it doesn't do 'strcmp' everywhere all the time?
I'm beginning to have a sneaking suspicion as to why triggers slow the game down a lot...
@crono, on Feb 24 2007, 01:03 PM, said in Yet another editor question:
That's odd. In a quick test I just did, the player's ship, shields, and Missiles are layer 3.5; the thrusters and every shot except the Wave are layer 2.5; and the Wave is layer 7.5. This matches what I found while building up all the layers used to get the One Page looking right (for example, the edges of the paper are in layer 2, but don't hide anything).
@crono, on Feb 24 2007, 10:05 PM, said in Yet another editor question:
Don't worry, the internal game architecture is perhaps limiting, but not inefficient, I don't know the details obviously but I know for a fact there is a parent-child link parser that creates these links when a map is loaded. As for the triggers, I don't think that's the reason they slow down things (unless you can show me a Shark sample proving this), more like because of their force field/triggering/etc potential effects at least I hope so
Oh, and by the way, on top of these two Extra values, there is an entire 32-bit flag field (only used for the tiled flag right now).