3889 replies to this topic

[KieferSkunk]

@arngrim, others who have contacted me about this: while this sounds like a great idea, I'm afraid I'm not going to have time immediately to implement it. I'm starting a new job on Monday and will have limited time to devote to VP, unfortunately.

Also, when I do have time for the DOF integration, I'm going to need to spend some time learning how it works. I'm way behind the times on this stuff.

[ClarkKent]

plunger on kingpin stops working after the first plunge with the new vbscipts
nevermind i have extremely poor reading comprehension skills

That happens here, too. Weird.

[KieferSkunk]

plunger on kingpin stops working after the first plunge with the new vbscipts
nevermind i have extremely poor reading comprehension skills

That happens here, too. Weird.

Please check a few posts back on this thread for a bugfix link.

[fuzzel]

any solution for this?

Have you played around with the drawing order? When a kicker must be rendered the first step is to punch out a hole on the playfield/wall and then render the actual kicker. if the kicker is rendered over another element it destroys the other element a bit.

[ninuzzu]

 

any solution for this?

Have you played around with the drawing order? When a kicker must be rendered the first step is to punch out a hole on the playfield/wall and then render the actual kicker. if the kicker is rendered over another element it destroys the other element a bit.

 

 

Working like a charm !

Just select the wall and the kicker, then right click--->drawing order(select) and move the wall up in the list.

Thanks , I had this problem too and I previously fixed it using a primitive instead of the wall object.

[freneticamnesic]

I had to do it 6 or 7 times before it took hold, i'd change the drawing order, open the table, and it was still the same. finally i closed vp and tried again, did it 3 more times, on the 4th time it worked.... the other side worked the first time (there's a identical kicker and wall on the other side of the playfield)

here I tried to reproduce and it worked on the second time for one, and the first time for the other ¯\_(ツ)_/¯

 

[Swisslizard]

I think Arngrims idea regarding the integration of the controller part into the core vbs files is excellent.

Also from a user perspective this would be quite helpfull. Nowadays the typical workflow when installing a new table on a cab, requires that theatable is loaded and that the script is modified to use the correct controller (typically b2s.server). If the controller object logic would be integrated in the core files, the only thing required would be to set the right controller type once and then it would be ok for all tables.

Thinking one step further, it would maybe even be possible to detect the controller type automatically by checking if a suitable backglass file is present or by checking if the b2s.server object can be instanciated.

Another thing which could probably integrated a well is some logic to switch between normal and silent (no contactors and similar gadgets). If the scripts can deliver some proper indication about the prefered config, DOF could be extended to support this (but that would likely also need a few changes in the b2s.server for which no code is available).

[arngrim]

if availability is a constraint, why just not transpose the existing code in a vbs, and can be extended, improved later, so the call in the script is not affected?
at least for vp10 gamma it would be great to have something
what kind of prefered config are you talking about swiss?

[cyberpez]

 

Alrighty, sorry about that.  Serves me right for trying to strip out debug code at the last second without testing it.  (I tested it this time.  It works now, I promise. )

 

core345-bugfixed-no-really.zip

Thanks, this works fine.

 

 
The kickers raised from the playfield, on a wall, the ball passes through the wall and gets stuck under, work in legacy mode.

 

Thanks

 

Max

 

 

I've noticed this also.  Fall through checked or unchecked the ball always falls through.  If set to legacy it works as normal.

[KieferSkunk]

if availability is a constraint, why just not transpose the existing code in a vbs, and can be extended, improved later, so the call in the script is not affected?
at least for vp10 gamma it would be great to have something
what kind of prefered config are you talking about swiss?

 

That's the thing about software development.  It's not usually so simple as to just take a bunch of code from one spot and copy it to another.  As I mentioned, I don't actually know how this code works, so in order for me to take the DOF code from any table where it's used and move it into the core scripts in a way that doesn't break everyone in the process, I would need to learn more about it so I know that I'm copying the code correctly and also giving the right instructions on how to work with it.  And, given that you want to make it easier to work with - which I agree makes perfect sense - it's not just a matter of copying the code, but rather adapting it for a new use case.

 

I don't mean to sound evasive, but I don't want to run the risk of doing a bad job on this when I don't have time to do it properly.  If you know what code needs to be copied, you can do this yourself - creating a separate .vbs file and loading it into your table is pretty easy.  And separating that code out from other more table-specific code would go a long way toward making it easier for others who are new to it to understand.

 

One risk you run when you move something like that into a separate file and just make it a "loadable module" is that people become disconnected from it, and over time they may forget how it works or how powerful it is.  That's why you would want to (a) make it as easy to use as possible, (b) document it well, and © make sure it does JUST that one thing very well.  If it ends up being a mega-class full of extra features, only its core features are likely to get used and all the extra stuff it CAN do will be forgotten over time, and you just end up with a bunch of dead code.  (In fact, there are some parts of the core VBS classes that are already in that boat.)

 

Incidentally, this is also part of why I haven't just put cvpmLightManager into the core.vbs already - in addition to needing updates for VP10 that I haven't had time to investigate yet, it also still needs a considerable amount of polish.

 

One other thought I have here: core.vbs itself is getting to be pretty huge as it is, and it's only going to grow as I implement cvpmTrough and cvpmSaucer alongside cvpmBallStack.  At some point, huge script files like this start becoming a little unwieldy.  In most integrated programming languages, there's a concept of "includes", usually specified at the top of a main script, that lists off all the things that script depends on.  If we were to give you a simpler way to load scripts (there actually already is one in the current core.vbs), would you be opposed to needing to list off multiple support scripts rather than just depending on one big core script?  This has the advantage also of allowing you trim out things you don't need.

 

Something like this:

LoadScript "core.vbs", 3.46
LoadScript "wpc.vbs", 100005332  ' Whatever the WPC version number is
LoadScript "b2s.vbs", 1.0        ' For B2S support
LoadScript "lightmgr.vbs", 1.1   ' For cvpmLightManager
' etc.

Note that this is just a sketch idea, but it mimics how this tends to work in other languages.

 

(One more thought: I think we should probably split script discussions into a separate thread.)

[fuzzel]

 

 

Alrighty, sorry about that.  Serves me right for trying to strip out debug code at the last second without testing it.  (I tested it this time.  It works now, I promise. )

 

core345-bugfixed-no-really.zip

Thanks, this works fine.

 

 
The kickers raised from the playfield, on a wall, the ball passes through the wall and gets stuck under, work in legacy mode.

 

Thanks

 

Max

 

 

I've noticed this also.  Fall through checked or unchecked the ball always falls through.  If set to legacy it works as normal.

 

This will be fixed in the next version together with some other strange physics stuff (hopefully)

[arngrim]

i fully understand your reaction, i'm a developer as well, never rush into integration fully understanding the requirements, technical details, constraints, possible enhancements in the future, so i'm certainly not a vb wizeard, the only code from me is this one:
 
Sub DOF(dofevent, dofstate)
If cNewController>2 Then
If dofstate = 2 Then
Controller.B2SSetData dofevent, 1:Controller.B2SSetData dofevent, 0
Else
Controller.B2SSetData dofevent, dofstate
End If
End If
End Sub

and i surely don't have time to take this task, i'm doing already so much in vp in my free time, i'll wait that a more expert than me implement that the best way

for info, DOF is a plugin of B2S.Server, so DOF alone can't work, the only real command that DOF knows is Controller.B2SSetData num, state (on or off), this command will gives an error if controller is not b2s.server, that's why i check the controller before calling this b2ssertdata in my method

and this method is only used for EM tables, and for certain tables that have issues with some mech elements that has problems, i script an event somewhere in the code which will call the DOF method with a certain number and state.

[Swisslizard]

Arngrims explanation is correct.

 

Just want to add my 2 cents:

• The Controller.B2SSetData does not only accept 0 and 1. It supports the full value range from 0 to 255. So maybe something like the following should be added as well.
  sub DOFVALUE(dofevent, value)
      If cNewController>2 Then
        Controller.B2SSetData dofevent, value
      end if
  end sub
• I'm not sure if this is a good idea, but auto detection of B2S.Server would be rather easy. So no change in the scripts to configure the prefered controller would be needed. The following code would likely do the trick:
  function GetController()
      Set Controller=CreateObject("B2S.Server")
      if isObject(Controller)=false then
         Set Controller=CreateObject("Dont remember the PInmame object name")
      end if
      Set GetController=Controller
  end function
• There is also another way to control DOF from scripts. A DOF com object is in the works. Code is finished, but needs a little testing on my cab. However this object is only partialy usefull, since it can not be used if a table does use the b2s.server, since this would lead to 2 DOF instances at the same time. I doubt that it will be of much use in VP tables, but it can be used to control DOF from any piece of VBScript and most other languages.

Edited by Swisslizard, 07 June 2015 - 10:23 PM.

[KieferSkunk]

Can you back up just a little and briefly explain to me what B2S and DOF are?  I vaguely understand that these are concepts for bridging the gap between Visual Pinball (and/or other virtual pinball systems) and physical hardware (eg. real DMDs, etc.).  But beyond that, I don't really know a thing about them - they came about much more recently than when I was last in the scene, so all I can see are some scriptlets here and there that I don't really understand without broader context.

[arngrim]

b2s.server is the software that plays the backglass files when we play a table controlled by b2s.server instead of vpinmame.controller.
b2s uses lamps and solenoids from vpm to emulates lights in the backglass.
but it does not only benefit from these plug and play events from the roms, we can also script events using b2ssetdata so it is transparent from a user pov whether an effect comes from the rom or the script.
DOF is a plugin of b2s.server which listens to the rom and b2ssetdata events to link these to an external mapping which will trigger toys from a controller like a ledwiz.
that's all i know

[KieferSkunk]

b2s.server is the software that plays the backglass files when we play a table controlled by b2s.server instead of vpinmame.controller.
b2s uses lamps and solenoids from vpm to emulates lights in the backglass.
but it does not only benefit from these plug and play events from the roms, we can also script events using b2ssetdata so it is transparent from a user pov whether an effect comes from the rom or the script.
DOF is a plugin of b2s.server which listens to the rom and b2ssetdata events to link these to an external mapping which will trigger toys from a controller like a ledwiz.
that's all i know

 

Gotcha.  I think I'll have more questions later, but for now all I can really say is that I don't see myself getting to this in any depth for at least the next week or two.  Just now finished cvpmTrough and tested it with BoP and TZ, and I still have cvpmSaucer to write (not gonna happen tonight).

[hauntfreaks]

I dont think this had been brought up... in the "audio options" as in VP9 you can pick where the sounds will come from and where the music will come from... in VP9 this separation seems to work perfect, but in VP10 it doesnt seem to work at all, is this a VP10 thing or a VP10 table authors thing??

 

i'm not really a fan of bumping a post , but i never did get an answer.... and there is noway i'm the only one that noticed this and/or wants it to work like it did in VP9x

[fuzzel]

rev2044 is up:

 

- core.vbs updated (by KieferSkunk)

- kicker physics fixed. The ball should behave physical correct now. ATTENTION: you have to set the hit accuracy from 0.3 to 0.7 or higher!

- ball physic updated

 

Some words about this update:

We have changed the ball physics and collision tests a bit. Please test this build if you encounter any new strange behaviors.

The hit accuracy for the new kicker behavior must be set to 0.7 instead of 0.3. Be aware that if you set the accuracy too low the ball never reaches the point where the kicker fires the hit event and the ball gets stuck and could produce slow downs because the collision detection tries to compensate this.

 

I dont think this had been brought up... in the "audio options" as in VP9 you can pick where the sounds will come from and where the music will come from... in VP9 this separation seems to work perfect, but in VP10 it doesnt seem to work at all, is this a VP10 thing or a VP10 table authors thing??

 

i'm not really a fan of bumping a post , but i never did get an answer.... and there is noway i'm the only one that noticed this and/or wants it to work like it did in VP9x

 

I haven't taken a look at the sound stuff and if there is any difference to VP9 so I can't say anything about that. The reason for not answering some question is simple: no time or overlooked the questions/bug report Therefore the best thing you can do is to create a bug report and we can check it when we find the time and we won't miss it because of hundreds of other posts in this thread

[toxie]

but you did two commits regarding that (rev 1940 and 1941)..  

[fuzzel]

ah thanks for the heads up. The changes were made because exporting of samples which were tagged to be played through the backglass sound device couldn't be exported anymore. Maybe something is broken since then...anyway a perfect entry for the bug report

Edited by fuzzel, 08 June 2015 - 02:57 PM.