XML questions and answers

[ptarth]

Well, it would help if the interpreter is also fussy on, e.g. not reading multi-line comments. I'm losing the motivation to stay up at 1am bug fixing what's otherwise perfectly fine code, except that your interpreter ignores the entire file.

You ain't getting nothing until you make me a proper debug tool.

Have you checked the BulletScriptErrors.txt log? That's usually where I die.

I've been experimenting with how good the angular and time precision is:
I'm trying to make bouncy snakes. Shots that follow each other with tight precision in an S curve pattern that ricochet off walls and then home in on the player. I had given up before because I couldn't keep them in line and thus they deteriorated into a swarm of bees. (Swarm of bees or school of fish shots...). Then my hope was rekindled after the boomerangs. So I tried and failed and then decided to try a precision test.

Procedure
Setup 7 trials, each of which should take the same length of time to complete an 180 degree turn.

Loops # of loops performed
Angle = Degrees change per loops
Time = How long each loop step should take

Code: [Select]

TorchWhite   Loops=1    ANGLE=-179 TIME=1.8
TorchRed   Loops=170  ANGLE=-1   TIME=0.01
TorchEmblazonedYellow Loops=90   ANGLE=-2   TIME=0.02
TorchYellow   Loops=60   ANGLE=-3   TIME=0.03
TorchBlue   Loops=45   ANGLE=-4   TIME=0.04
TorchGreen            Loops=36   ANGLE=-5   TIME=0.05
TorchPurple           Loops=30   ANGLE=-6   TIME=0.06
TorchPink             Loops=25.7 ANGLE=-7   TIME=0.07
Notes:
Loops=25.7 I just noticed I asked for it to loop float number of times. I'm not sure what it did, probably rounded down.
Why 179 instead of 180? 180 could go either clockwise or counter-clockwise. I've had it even happen with values in the low 170s. This seemed to work fine here.
Also, my results may be related to system load or system specs, which means they are only valid for me.

Discussion
Only the 179 turn made it. The 1 degree turn just gave up and went straight. I don't think it is a take_pants_off_head problem.

Trying again with large angles.
Changed to angles 8-14, with respective changes made to loops and time.

Discussion
They do better. After 2 S turns even the 179 degree turn shot stream isn't in single file any more.

Conclusion
Keep angles above 15 and with rotations longer than 1.8 seconds if you really need precision. Tight, high precision bouncing snakes and boomerangs probably aren't going to happen very well. Regular jumping snakes will have to suffice. Invest in bees.

Pictures:
Test 1: Red gives up
Test 2: Everyone is together at first
Test 2: After 2 S curves
Test 2: After more than that S curves

[PokerChen]

 So I went with bouncing, non-curving boomerangs, given that any significant curving is liable to make it collide with something during the frame it is changing angles.

 = = =

.. Is there anyway to make a bullet point in an absolute direction regardless of the orientation of the parent entity AND the player? I want to synch up a particular system when it fires, in terms of the angles from one firing trigger to the next. The blademorphs image is attached (they convert between offensive and defensive depending on distance to the player, updated every ~0.6 seconds or so.) - there's a desynch each time the system fires, but if I leave a bullet pattern on for 30 seconds, it won't die when the parent does. So...

[PokerChen]

<loops>

I've found that the small angle deviations aren't noticeable too, but I'm guessing this is a numerical integration problem, as well as a potential issue with precision.

[ptarth]

So I went with bouncing, non-curving boomerangs, given that any significant curving is liable to make it collide with something during the frame it is changing angles.

 = = =

.. Is there anyway to make a bullet point in an absolute direction regardless of the orientation of the parent entity AND the player? I want to synch up a particular system when it fires, in terms of the angles from one firing trigger to the next. The blademorphs image is attached (they convert between offensive and defensive depending on distance to the player, updated every ~0.6 seconds or so.) - there's a desynch each time the system fires, but if I leave a bullet pattern on for 30 seconds, it won't die when the parent does. So...

I'm not sure what you mean.
<change angle="<number>" speed="<number>" relative="false"/> will make them sync, but I have a feeling that's not what you meant. Another choice is to do a shot that then fires the blades of the boomerangs every X time units, like the Reaper's weapons. You can also do things with with rotation and direction using angle_from_parent="<number>" distance_from_parent="<number">.

I can give something more specific if you can describe it so I can understand it better.

[PokerChen]

 I'm looking at a different creation at the moment, which has permanently spinning blade/shields around itself It should have the following properties:
 1) each arm changes as a function of distance to the player, morphing the shields into blades as the player approaches.
 2) this needs to happen smoothly.

 So, (1) occurs every time I respawn the bullet pattern, using the <bullet>'s min and max distance criterion. Due to this, the speed and starting angle at which they spin needs to sync up with the refresh time so that the new bullet pattern spawns on top of the old one. On the other hand, the three settings of targeting_logic "Direct" "Lead" and "Dumbfire" all give me different initial angles, which are time varying.
 The current workaround I just implemented is to fix the ship orientation completely after spawn, which I can get away with since I picked a circular sprite.

[ptarth]

Ah, rotations. I hate them. So much.
Spawn X (where x = number of arms) infinite undestroyable nonhitboxed shots at 360/X angle around your ship at the distance you want the arms to spawn at (or at 0 and just move the arms farther out to start).
Have those spawn your Arms using dumbfire, straight ahead using X & Y coordinates and relative. The X will vary, Y will always be 0.

[Misery]

Aaaaaand I look back in here, and I have no idea what's even being talked about anymore.

 I sense math somewhere nearby.  A horrible feeling.

[PokerChen]

 Well, here's a rar file to show you what I'm talking about dynamically. The Enemy_Pursuers folder contain the images of ships I reserved earlier that's meant to go into the Ships folder. They're at completion except for the advanced blademorph variant that I'm not sure yet how to turn into an interesting deadly pursuer.

 The test room contains 6 of the normal blademorphs that show you the spinning/player-distance dependent bullet patterns. The whole idea is that at >650 range they're immune to normal bullets so they can actually survive pursuit into ~300 range, unlike all of the other vanilla pursuers. Players are supposed to bait them into attack mode to kill them - they'll open up in stages so that the more timid players can simply take longer to kill them at about 300~400 range.
 Facing any one of these alone in a 5x5 tile room, one should be able to circle kite them all day.

 The Anangu, on the other hand, could be challenging in a maze or many-walled layout where it is difficult to predict the bounce of the sizeable boomerangs. I'm considering reducing the boomerang size a little, but again, faced alone it really shouldn't be any trouble to kill. They even throw purposefully off to one side (unless you're really far away), so I think players would learn fairly quickly to avoid the arm side.
 The remaining problem with this is how to resolve partial hits, since the boomerang is itself 9 bullets, so it could actually hit players multiple times. I think I can simply make the individual parts of the boomerang pass through and damage the player, but the more appealing (reduce difficulty) option is to make the entire boomerang die upon impact. Might not be possible engine-wise.

[ptarth]

• Those are really cool.
• Possible variant idea is to allow the arms to reflect bullets back in friendly fire mode at long range.
• Anangu Shots - Players get immunity after collision for a few seconds, so most of the time if they take a hit, it will allow them to absorb most of the remainder of the shot. There are some attributes? that refer to actions take on parent death, but I'm not sure how well that would work out in this case. It also might only work for ship entities. Although bullets are entities, too. I really don't have a good grasp on that side of the relationship.
• Another option is to have a shot clearing effect on death for the shots, so if one dies, they all die. But that would also clear other shots.
• You made be able to have a system that is added to each shot that causes death on death activation. Misery has a couple of designs that copy systems like that. I've not done anything in that department.

And you've given me a hilarious idea... A pinball machine boss. Using a variant of the blademorph weapon as the flippers, needing to somehow trigger them to launch projectiles back at the boss. Or perhaps something with the player as the pinball, needing to hit "speed up" objects in order to get far & fast enough into the bosses area to do damage before falling back down.

[keith.lamothe]

A pinball machine boss.

Genius.

[ptarth]

A pinball machine boss.

Genius.

Thanks. Its on my list with:

• Train boss
• • The player is on the floor of a giant train station. The railway is laid out on the ground of the room. The boss teleports to tunnel entrances. Roars down it and then teleports when it hits the tunnel exit. The boss is the engine and it has train cars following it with their own weapons.
• Reanimator
• • All those dead hydral mechs have been piling up over the years. Someone has figured out how to rebuild them and guess who wanders into that guy's house?
• Frogger
• • Cross lines of shots that look like cars, trucks, buses, and logs, to get to a safe zone to shoot at the boss.
• Pacman
• • In a pacman maze you have to chase down and kill a ship laying spawning eggs and kill those eggs. If you fail, they grow up into aggressive hungry ships

I need to find something that dinosaurs could work with.

reZHA-I'm trying to parse your code, but its taking me a while, I'll try to get back to you tomorrow when I have more free time.

[keith.lamothe]

Looking forward to seeing those bosses. Assuming the XML doesn't unravel your mind first.

[ptarth]

Looking forward to seeing those bosses. Assuming the XML doesn't unravel your mind first.

The protoype of the reanimator is already in and functional in the SVN. Pepisolo was actually looking for feedback from you guys about what direction to go in, before we develop it much further. Goodness knows there is no hurry and you guys have tons on your plate as it is though. Most of the others are tragically waiting in my notebook, having had all of my time spent on making snakes this week.

[keith.lamothe]

Yea, that's in Chris's ballpark. I'm not generally involved in giving content direction, I just make bad jokes and occasionally code something.

[PokerChen]

 A Train Boss or Pacman could be good fun and a change from the usual boss in one place mode. The current limitation I can think of for the Pac man is some form of a location-based trigger, or on-collision-change-angle-by-90-degrees thing. I haven't quite figured out how to have an entity dodge 90 degrees to one side on trigger, but with a bullet-pattern moving the entity, it would be possible to do a simplified Pacman move system.

 On the boomerang shot: I'd try to make them components shots destroy on AOE again. For a short time on Friday I was playing around with explosive boomerangs, when I copied the player misille launcher into the code (I'm sure gifs of TNT-strapped ones are around somewhere on the internet...)

 I think I'd like to make a 7x7 carrier enemy before committing the set to Misery. If only there's an easy way to make a Free-Space style sweeping beam...?