Ah, my only computer with even relatively capable graphics card (Radeon X700 ) died so I haven’t been able to continue working on the game. (déjà vu anyone?)
The Dawisch: You assume wrong
FunkyWyrm: Thanks for the advice. I tried to set mouse speed to the maximum but that didn’t cause me any more problems though.
mr_yeahman: gamecompany? Never heard.
AD-Edge: Hah, so finally someone who didn’t come at me yelling the last level’s totally broken. I haven’t tried the .exe method but it has worked flawlessy within blender on all the machines I tested. No mouse problems. blenderplayer is a totally another thing…
kernel_script: Does it give any (python) error messages if you run it within console? If you select TOUR there shouldn’t be hole selection at all.
Chris1977PL: Noo! Don’t die! :eek:
curlystraw: Simply by casting a ray up and down from the ball (actually only one ray) relative to the current normal to check if there’s a magnetic surface to be found. Then, if the ray hits a mag-surface I set the surface normal to be the new “up” vector of the ball and move ball to the ray hit position and align camera base to the vector. After that, I need to re-aim my velocity vector, which I do by calculating a projection vector of the velocity vector on the mag-surface, then normalize this projection to get a simple direction which I then multiply with the original velocity vector length to get the new velocity vector length. Of course it’s not that simple in the actual implementation as I needed to do some adjustments and cheats to avoid certain glitches but that’s the basic idea. Take a look at the assets/ball/ball.blend/BallPhysics.py. (My terminology may not be totally correct)
I don’t know if these are errors. Take a look on the attachment.
And i get stuck in both TOUR and PRACTICE screens right before enter the gameplay, and the only way to exit the game on TOUR mode is by doing a “xkill” (it’s a GNU/Linux command to kill a buggy window).
I’m doing something wrong? I tested it in a Windows installation too and i get stuck in the same way.
I can see only deprecation warnings from SuperFont.py which is normal but I guess this image does not contain all the output there is? I think the more interesting stuff is in the end.
I managed to replicate the bug with blender-2.49a-linux-glibc236-py26-i386. It seems it’s missing some messages/subjects which causes the HoleSelectControl.py not to run properly.
2.49 works fine so give that one a go.
Hmm… 2.49a with python 2.6 won’t even run in Windows, do I need some new C++ Runtime or something? Had similar problems with RC builds compiled with python 2.6.
No news at the mouse department.
But… here’s an old cg piece of mine which I based the game setting at.
Thank you very much for your patience and support supersocks. You are right about the Blender version. I installed Blender 2.49 for GNU/Linux with Python 2.5 again and it not only plays your game properly but the performance are far superior than my Blender 2.49a for GNU/Linux installation.
About the 2.49a on Windows, i had the same issue, but the install wizard warned me about it and suggested to download a recent version of that C++ Runtime or something and pointed me to the website for download (i don’t remember the exact name, i don’t use Windows as OS, so I’m not familiar with these dependencies). You compiled your Blender 2.49a from source on Windows? There was not a warn about these dependencies on the text files? Or you installed the .msi? I installed that one and it warned me about the dependencies. Also, it suggested Python 2.6. and pointed me the the website for download. After all that, my Blender 2.49a for Windows could run, but your game was with the same problem as it was in my Ubuntu intallation. Weird that on Windows there was not a performance issue with Blender 2.49a, on Ubuntu there was, but with Blender 2.49 there was not
Man, your game is indeed beautiful and fun, really, amazing job, keep up the great work!
By the way, what PAR[+0] mean? I got no score with it
The picture shows where it is stuck. The camera just slowly rotates around the course with no hint that something has gone wrong, except that no key has any response.
The last lines in the console are:
Particle system initialized. Found 96 floating particles.
Initializing HUD control...
Preparing player turn...
Any idea what the problem is?
For those who are wondering, I have no GLSL and it still looks quite impressive. (OpenGL 1.5)
SuperSocks: I can’t get past that loop spot. I see what I have to do, I have to drop down from one to the other, but when ever I do it rolls be away and I can’t get there (confusing I know)
That last hole is almost impossible, but I got lucky once while in practice mode and was able to beat it.
Just noting, it seems as if the game has got the stroke names backwards:
+2 the game calls an eagle.
+1 the game calls a birdie.
Par is okay.
-1 the game calls a bogey.
Hole in one is okay. (of course)
All round a great game and I had zero glitches during game play.
I think someone has finally gotten my vote…in several categories.
My brother has been poking around in the files for Megagolf and he figured out how to create a course. It’s a little rough, but he’s built a second 18-hole course for the game. Should I tell him to clean it up a bit and then post it here?
ionee: There is
JESUSFRK14: Use your instincts.
Littlebob: Whoops :eek:
PhantomMoose: Sure, go ahead. Just make sure all paths are relative and try not to put any modified files outside the courses/ directory so it makes a neat download package people can just unzip.
Discovered the cause of 2.49a missing messages. In 2.48a and 2.49 a list item existence check like following works fine but in 2.49a it always returns False.
subjects = message.getSubjects()
prev_hole = "PreviousHole" in subjects
A simple workaround I thought about would be to convert the list into a string and then search that
prev_hole = "PreviousHole" in str(subjects)
Strange. Wonder if that’s supposed to be normal behaviour?
) died so I haven’t been able to continue working on the game. (déjà vu anyone?)
