Just started on the BoP build again

[Ewan Meadows]

After being gobsmacked when I saw the cost of the BoP2 kit I decided
to get off my arse and finish off the BoP build I started some 3 years
ago. Not having a Linux box handy I ended up setting up the build
environment on my Pi, which is actually working out pretty well. The
instructions I wrote for Ubuntu work fine on it (running a version of
Debian) and it takes roughly 80 minutes to compile gcc6809 and about 2
minutes to compile the current BoP build.

At the moment it's still a very basic build, although you can flip the
ball, score points and the shotmapping is pretty much complete. The
'FreeBoP manifesto' I came up with was this:

Utilise the theme of 'building the robot' better:
In classic Python style, he came up with a pretty decent idea but then
didn't really have a great conclusion (Bubbles, Popeye, BoP). In
FreeBoP the player will have to use the whole table to build the
robot, rather than just the shuttle ramp. Also I want to add in in
the concept of adding arms, heart, brains etc, rather than what the
factory ruleset does, which tends to just focus on the changing face.

Format the ruleset towards competitive play:
Again, in the spirit of the TZ build I did, I want to try and make it
as different as possible to the factory ruleset. The reason being is
that after 22 years of playing the same rules can get a bit dull and
I'd love to see it being used more in competitions.


A couple of questions:

1. It seems that coin up is broken on the latest code. It appears
the custom setting is the default and it doesn't let you add credits
properly. I'm guessing it's cruft left over from FT dev.

2. Is there a 'proper' way to only allow 1 ballsave per ball? At the
moment I'm doing a dirty hack in common/ballsave.c under
valid_playfield. As it is, it appears that the ballsave timer gets
reset on each ball serve, so I can just keep on plunging the ball and
draining forever. It looks like it gets reset on every callset_invoke
valid_playfield, which is called every time a ball enters the
playfield from the trough?

3. What's the recommended timer method now? I see that free_timer_*
only supports up to 8 seconds, do I go back to the old method for
anything longer than that?

4. A lot of the test menu text is isn't displayed when using an
Alphanumeric display, whenever it's too long to fit on a line.
Rather than having to go through and edit it all would it be better to
scroll the text if it doesn't fit the screen? Unless you can think of
a better method, that's the way I'll have a go at implementing.


Cheers,

Ewan

p.s I *hate* setting up Visual Pinball. It actually took less time to
patch, compile gcc6809 and setup the FreeWPC environment than it did
to get VP working. It's just one big clusterf*ck of different
software components.

[Cardona, James E.]

Hmmn. That's weird. My ballsave timer works properly and also my coin up works. Never tried to do a single ball saves though. Why would you want that?

Good luck.
Jim

--

---
You received this message because you are subscribed to the Google Groups "FreeWPC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to freewpc+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
-----------------------------------------
The information contained in this e-mail, including any
attachment(s), is intended solely for use by the named
addressee(s). If you are not the intended recipient, or a person
designated as responsible for delivering such messages to the
intended recipient, you are not authorized to disclose, copy,
distribute or retain this message, in whole or in part, without
written authorization from PSEG. This e-mail may contain
proprietary, confidential or privileged information. If you have
received this message in error, please notify the sender
immediately. This notice is included in all e-mail messages leaving
PSEG. Thank you for your cooperation.

[Ewan Meadows]

At the moment the single ball save is just a workaround. It's been
like it for a while as I remember I had to do it for the TZ build.
I'm currently using Brians latest codebase on github. I think the
problem is that it's adding more seconds to the ballsaver than it
takes for the ball to cycle round each time.

I do have other issues as well, with the new free_timer API.
Sometimes it just doesn't work for some reason. The other major bug
is that sometimes, seemingly for no reason, it'll refuse to go to the
next ball after a ball drain and just sits there, refusing to serve
the next ball.

I might try the v1.0 release to see if I'm still having issues.

[Cardona, James E.]

I am running old code from sometime around February and do not have those problems. As to the free_timers, I have not used that.
I have been doing a lot of playing around with tilt, ball save and the end game routine in game.c. There is some logic there that is a bit off that I am trying to hammer down.

[Ewan Meadows]

Ok So I managed to figure out my problem with it never advancing to
ball 2, or at least the reason why it was doing it.

I had four containers defined, the under playfield kicker, trough,
head and skill shot kicker:

[containers]
Trough: Trough Release, trough, Trough Left, Trough Center, Trough
Right, init_max_count(3)

Head: Wire Ball Lock, init_max_count(0), Enter Head, Wireform Top,
Wireform Bottom

UPFKicker: UPF Kicker, init_max_count(0), Under Playfield Kickback

SShotKicker: SShot Kicker, init_max_count(0), Skill Shot 50K

For some bizarre reason, when the ball is released by the trough the
live_balls count goes up to 1. When the ball is plunged into the
skill shot and leaves the live_balls count would increment again,
giving me a live_balls count of 2 when there was only one ball in
play, meaning when it drained the game was still waiting for the
second non-existent live_ball to drain. I've 'fixed' this by not
having the SShotkicker as a container, but it's a workaround and I'm
still not sure where the bug lies. Maybe because valid_playfield is
not set when the ball enters the sshotkicker and is set when it
leaves, the game logic decides to increment live_balls by 1.

Right now I've got most of the stuff done I want playfield wise, such
as loops, jets, ramps, wheel awards, standups etc. Today I'm going to
start looking into writing a driver for the head spinning and start on
a multiball mode.

I've uploaded the latest code to my github, although I'm not sure what
the best way to submit code so it's easier for Brian to pull. Do I
create a new branch that has the later code from Brian?


Another issue I've

[Brian Dominy]

Ewan,

I've been busy this weekend but I have been following the discussion.  I'll look into this issue as soon as I can.

It's not yet obvious to me what's going on here.  live_balls should only go up on a trough eject.

Brian

- Brian