1394 replies to this topic

[petercobra666]

Got some bugs with latest build (v.698). Monster Bash: When ball hits Frankenstein, hes just shaking and doing nothing. In prev version when I hit him Im getting body parts - any ideas whats going on?

Edited by petercobra666, 01 November 2013 - 01:06 PM.

[koadic]

Found another issue that I believe is related to what was fixed in rev601... not that the fix broke anything, just that it seems all the related issues weren't resolved. If I try to rotate by a fractional number, such as 1.5, it rotates by 15 disregarding the decimal point

[jpsalas]

Found another issue that I believe is related to what was fixed in rev601... not that the fix broke anything, just that it seems all the related issues weren't resolved. If I try to rotate by a fractional number, such as 1.5, it rotates by 15 disregarding the decimal point

I can rotate by 1,5 and 1.5 (using a , or a .) and it rotates fine, ramps and walls, usng the latest build.

Edited by jpsalas, 02 November 2013 - 02:11 PM.

[koadic]

That's weird, when I try rotating a ramp it doesn't work correctly. I even tried using a comma, but the result was the same.

[jimmyfingers]

I have fractions / non-integer values as a result of some script calculations and have not seen any problems in the primitives movement as a result for me either.  I don't know Koadic if you were just referring to the entries within the editor but it doesn't appear to be a problem for me on my main test / MOD WIP table at least via script values.

[fuzzel]

I know what you mean koadic, but it's a windows mystery for me. It only happens in the editor. I think it has to do with the language settings of Windows. I have to goggle around for a way to fix this.

[koadic]

I was messing with a table and tried rotating a ramp in the editor by 11.5 degrees and didn't get the result I was expecting. I could rotate by 11 or 12 and get close, but 11.5 was way off of what I was trying to achieve. Remembering back to a previous bug where there was an issue trying to rotate an object if the center point had a decimal point in it, basically causing something like 238.76 to act like 23786 and effectively causing the object to disappear from the table unless you zoomed way out, I tried rotating by 115 and got the same result as when I tried 11.5 which makes me think it was part of the same bug but didn't get fixed. The notes only mention a fix for translating and the center point when scaling or rotating, but don't explicitly mention anything about rotation amount.

Edit: lol, you responded while I was trying to compose my message fuzzel. I believe that was the same cause of the previous bug too, and those not running windows with U.S. language and localization settings aren't experiencing the issue.

Edited by koadic, 02 November 2013 - 02:53 PM.

[fuzzel]

well I don't have this issue if I use a comma instead of a point (11,5 works but 11.5 I get the same result as you do). The old issue came from the fact that I tried to fix this in the code like if you enter 11.5 I converted it to 11,5 but that didn't work on systems with different localization settings

[fuzzel]

Ok the reason for the comma instead point or vice versa is that it depends on your system locale setting. The type conversion is needed to align the data in a way that the COM interface can handle them. I didn't find any way to circumvent this behaviour, so I guess you have to deal with it.

 

Another small update: With rev 699 you can disable the lighting on ramp textures (uncheck 'Enable Lighting for Image'). This setting is only valid for ramps with a texture assigned to it.

[koadic]

And I updated to rev 700 to remove the last instance of decimal to comma conversion (added in 592). The rest were removed in 601, so figured there was no harm in removing the last one as it fixed my issue.

(talking about this part inparticular...)
 

   for( unsigned int i=0;i<strlen(szT);i++)
   {
      if( szT[i]=='.') szT[i]=',';
   }

After looking at the code and checking back, I realize that it was only an issue if the OK button was pressed, but it was fine if the apply button was pressed first.

Edited by koadic, 02 November 2013 - 10:00 PM.

[fuzzel]

[jpsalas]

I think I may have found a bug in rev700, but it may be just my system. It looks like there is a memory leak, since sundenly the editor became very slow. I took a look at the task manager and VP didn't use the cpu, but the memory usage was huge, about 3,3Gb and I guess it was reaching the limit. Quiting VP and loading the table it went back to using about 300Mb which is more normal. But as I said, it may be my system, but it has done that twice.

[fuzzel]

hmm did you work with primitives when you encountered that huge memory usage? I have to run VP through a stattic anaylzer to find such problems...

[unclewilly]

I'm having the same issue jp stated. It started for me with rev 700. But I did miss the previous rev.

It always occurred fir me when working with the primitives.

It was also causing vp to crash occasionally.

[jpsalas]

I mostly copy/pasted lights to convert the lights from using alpha ramps to lightmap lights (I used the AFM table). I can reproduce the error by simply adding more and more lights until the memory fills up. But I do have several static primitives, used as pegs and skrues, but it was while working on the lights that I noticed the used memory growing up fast. For each light I add I can see the memory growing by 1Mb or more. I guess I need to try it on a new table.

 

Edit: I tried adding a lightmaped light to an emty table and copy that light many times and the memory was ok. So it may be possible it has todo with the primitives added.

 

Edit 2: It is strange since it also eats memory if I simply press the CTRL Z key

 

Edit 3: I have go back to prev revisions and they all seem to do the same (I have gone back to rev 640)

Edited by jpsalas, 03 November 2013 - 01:25 PM.

[toxie]

rev 701 introduces per-table region updates and region optimizations, so that table authors can force one or the other in case of visual bugs, and users in case of some tables running faster than others with different settings..

[krille81]

Nice!! Do you think you can do the same thing with the option with software fxaa?? I'm an win7 user So i will be very happy with that option

[fuzzel]

I mostly copy/pasted lights to convert the lights from using alpha ramps to lightmap lights (I used the AFM table). I can reproduce the error by simply adding more and more lights until the memory fills up. But I do have several static primitives, used as pegs and skrues, but it was while working on the lights that I noticed the used memory growing up fast. For each light I add I can see the memory growing by 1Mb or more. I guess I need to try it on a new table.

 

Edit: I tried adding a lightmaped light to an emty table and copy that light many times and the memory was ok. So it may be possible it has todo with the primitives added.

 

Edit 2: It is strange since it also eats memory if I simply press the CTRL Z key

 

Edit 3: I have go back to prev revisions and they all seem to do the same (I have gone back to rev 640)

There are memory leaks in VP for sure...Let's see how much I can find and fix

[unclewilly]

Is there any way to fix vp flipping Meshes on import.

[randr]

hey guys. Im no expert but something is broken after version 628. very odd behavior when running from frontend pinballx. i thought it was frontend but tried all other versions of that and still had issue. 

 

Problem is some tables crash, wont take credit or dont start. i was running latest and downgraded to 628 and now all works normal. Any ideas?