Page 13 of 18
Posted: 03 Aug 2010, 21:20
KDL
Re: Re: Request: WolfR4 always on top option
I think it's (win)API : setWindowPos()
flag: TOPMOST or something
in .NET (C++, C#) it's almost automatically
it's useful for car makers (changing car data while runtime)
_
I think shortcuts would be better (keyboard:winapi as I heard from huki)
_
ah btw, Thanks for WolfR4, it launched Re-Volt automatically in Vista (from rv house)
[I'll try to see what the error when exiting form frontend]
Posted: 04 Aug 2010, 01:41
Huki
Re - Unlock All Feature
I think it is better to use the existing program "Re-Volt Xtender" that you can get from [url=http://revolt_f1.webs.com/rvtoolshed.htm]This Site..[/url]
Re - WolfR4 always on top
I don't think this will work when re-volt is running in full screen. A full screen program always has topmost priority and is above all other programs. In Windows7 it is even particularly taken care that no program can interfere a running full-screen program.
If re-volt is running in window mode, you can just use the winapi function
SetWindowPos (hwnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE) ;
SetForegroundWindow(hwnd);
Well, even if wolf is "always on top", you would have to click on the wolf window or use alt-tab to make it active. So how can you use keyboard shortcuts in wolf, even if it is on top? Or do you think you can make wolf get all the keypresses directed towards re-volt?
Request - Make mouse pointer visible in Re-Volt
The mouse cursor is visible in re-volt only in Frontend. Can it be made visible even after a track is loaded? This will help minimize re-volt in windowed mode (currently that works only in frontend) and also help to switch between programs.
Posted: 04 Aug 2010, 06:22
jigebren
KDL @ Aug 3 2010, 04:50 PM wrote:[I'll try to see what the error when exiting form frontend]
I don't know if you're actually talking about the bug when quiting an online race, but in the later case, feel free to add any info, as I currently have no idea about the reason of this bug (and unfortunately not much time to spend on it).
Re: "Unlock All" Feature
Ok, I have not used "Re-Volt Xtender" a long time ago, and after trying it again, I have to admit it does so well what it does that I don't feel like implementing any of its features in WolfR4.
Re: WolfR4 always on top
So I don't think an "always on top" feature would be very usefull.
About keyboard shortcuts, I meant "global" shortcut, so that it works even when WolfR4 has not the focus.
But I don't think I will ever implement global shortcut, because I don't know if I can do it properly, and I don't want to interfere with re-volt.
Re: Request - Make mouse pointer visible in Re-Volt
Well, after spending some time to understand how the cursor is managed, I was about to try to patch it when I discovered that this feature is already implemented in the DEV version (can be set in the DEV panel).
Posted: 04 Aug 2010, 08:11
Abc
There was a big delay before I can play the level, and when I quit the ended race (1 lap), revolt crashed. But I had not set the compatibility mode, that could be the cause.
On my pc with windows xp sp3 there is about a 1-2 minute loading screen if the compatability isnt set, so you can probably rest assured that the delay was the compatability.
revolt always crashed after racing online, unknown cause. afaik no one has been able to find out why it crashes, or stop it from crashing.
lol
there's no way to stop that, it does that because is looby special mode. it only happens while using revolt launched by rvhouse also the crc check is perfomed when using looby mode
Posted: 04 Aug 2010, 19:42
jigebren
Re: Frontend load screen not shown in Vista/7
@Huki (or others...)
As I can't test myself, can you please just confirm or invalidate that neither using the -doublebuffer command line nor activating/deactivating the V-Sync option in re-volt have any effect on the "can't flip display buffer" message, or any effect on the missing loading images when using the -sli commmand.
Crash when quiting a lobby race
I think I have finally found the reason why re-volt uses to crash after a lobby race session (ie. when launched from RVHouse).
This new bugfix will be added in the next WolfR4 release so that it can be more thoroughly tested, but at first sight it seems to work nicely.
Posted: 04 Aug 2010, 21:23
arto
KDL @ Aug 3 2010, 04:50 PM wrote: ah btw, Thanks for WolfR4, it launched Re-Volt automatically in Vista (from rv house)
[I'll try to see what the error when exiting form frontend]
Alright cool... anyone know if it works both in 32-bit and 64-bit versions? Anyone tried with Windows 7?
If it will work just by using WolfR4, maybe I can add to RV House web-page a FAQ item about how to get it working in Vista/Windows 7 - just install Wolf
.
Posted: 04 Aug 2010, 23:12
urnemanden
arto wrote:anyone know if it works both in 32-bit and 64-bit versions?
Well, it works just fine on my Windows Vista 64-bit as the registry entries are redirected to the Wow6432Node folder automatically. I suppose it does in WIndows 7 as well, but then again I'm not sure that's the case when using Windows XP Mode.
I'll test the new Wolf out soon, thanks for the release, Jig.
Posted: 05 Aug 2010, 00:37
Huki
Re: Frontend load screen not shown in Vista/7
-doublebuffer does not fix the display buffers problem after load screen or the
problem of loading bitmaps not showing. Vsync on/off has no use either.
I was thinking that updating some function calls which have alternate code for -rgb or -mmx might solve the problem. Like,
IDirect3D3 *D3D; D3D->EnumZBufferFormats(...);
IDirect3D3 *D3D; D3D->CreateDevice(...);
IDirectDraw4 *DD; DD->CreateSurface(...);
Unfortunately, i don't know directx programming as of now. And searching for these functions on msdn was of no use.
Re: Crash when quiting a lobby race
I think I have finally found the reason why re-volt uses to crash after a lobby race session (ie. when launched from RVHouse).
Wow, really? Care to share with us why it happens?
Posted: 05 Aug 2010, 21:35
jigebren
arto @ Aug 4 2010, 04:53 PM wrote:If it will work just by using WolfR4, maybe I can add to RV House web-page a FAQ item about how to get it working in Vista/Windows 7 - just install Wolf
.
I think it should work quite easily (in a normal scenario) as the -sli command line is set by default when Vista (or later) is detected, and all other default settings should be ok in most (all?) cases.
The Win98 compatibility mode is not modified, but it can be set easily from the "Bugfixes" tab.
And by default, the windowed mode is selected. Even though it could be disturbing as it's not the regular re-volt setting, it can be very helpful the first time you try to play online, because you can see the request/messages sent by eg. your firewall.
Re: Frontend load screen not shown in Vista/7
Too bad... The last thing I'm wondering is: Does
everybody have to use the -sli command to make it work under Vista/7? Or is there some Vista users that don't need the -sli command?
I'm not really sure that following the -rgb lead can help us to understand this issue. But the real fact is that I don't know anything about directx...
From a video that Urnemanden sent me, I see the DDERR_INVALIDPARAMS directx error message, which could suggest that there is a used parameter unsuported in Vista. But maybe it's more complicated... it could also be another bug that made re-volt send an unwilling parameter, something that made no sense for the directx function.
Posted: 06 Aug 2010, 01:05
Huki
Everyone with vista/7 have to use -sli or run in windowed mode. In my windows7, sometimes if i am lucky, i can get to frontend by repeatedly pressing enter to the display buffers error. Then I don't have problems till the end of the next loading screen..
About invalid params, both the parameters to Flip() are valid.
Jig wrote:
I'm not really sure that following the -rgb lead can help us to understand this issue.
Maybe you're right, but this display buffers error is just one of the 3 known problems re-volt has with vista/7. Since -sli already fixes the display buffers problem, working on it again is probably a waste of time.. but fixing all problems with vista would be worth considering...
Posted: 06 Aug 2010, 02:05
jigebren
Huki @ Aug 5 2010, 08:35 PM wrote:In my windows7, sometimes if i am lucky, i can get to frontend by repeatedly pressing enter to the display buffers error. Then I don't have problems till the end of the next loading screen.
I was thinking about simply trying to skip the popup message, I'm just curious to see the result in that case.
Maybe I could send you a patched re-volt version without this message so that you can test it in win7.
About invalid params, both the parameters to Flip() are valid.
Yep, at least it seems. That's what is weird here. Because there has to be a reason for the DDERR_INVALIDPARAMS message, and we have to find it to solve this issue, I think.
Maybe it's another bug that indirectly messes with memory/stack...
this display buffers error is just one of the 3 known problems re-volt has with vista/7. Since -sli already fixes the display buffers problem, working on it again is probably a waste of time.. but fixing all problems with vista would be worth considering...
What are the 2 other Vista bug? The loadfront/loadlevel images not displayed? (for me this one is the same one than the displaybuffer message).
EDIT:
Huki @ Aug 4 2010, 08:07 PM wrote:Re: Crash when quiting a lobby race
I think I have finally found the reason why re-volt uses to crash after a lobby race session (ie. when launched from RVHouse).
Wow, really? Care to share with us why it happens?
Well, they were deallocating some memory areas that have allready been deallocated, wihout testing it before. Apparently, windows doesn't like...
Posted: 06 Aug 2010, 08:06
Huki
jigebren @ Aug 6 2010, 02:05 AM wrote: I was thinking about simply trying to skip the popup message, I'm just curious to see the result in that case.
Maybe I could send you a patched re-volt version without this message so that you can test it in win7.
Yes, you can. I wonder why I never thought of this o_O
Posted: 06 Aug 2010, 12:51
KDL
What's RGB?
rgb: (RGB emulation mode) is the way to transform each pixel to color [that more CPU more than GPU] (looks more like software side of Dx to me... it's extremely slow )
theory: Loadfront/LoadLevel
(my theory: load front/ load level) I think the API used in Picture is "bitblt" which isn't compatible anymore with vista and its sons [library:GDI]
Theory proved? No, but in google many people having the same problem w/ Vista and 7
note:(GDI is *almost* dropped by Ms to GDI+ [I mean inactive, not throwing it away])
Posted: 06 Aug 2010, 14:16
Huki
Hmm as far as what i see, Blitting is used only for windowed mode.
Posted: 06 Aug 2010, 18:50
jigebren
Re: Frontend load screen not shown in Vista/7
Yesterday, I had a Win7 system available, so I was able to do some tests myself.
Here are the results of my investigation:
[I ran re-volt with Win98 Comp. mode activated on a laptop with a dual-core under Win7 64bits.]
- With or without -sli, in
windowed mode I have no display buffer error message, and no loading screen images (but the blue frame around the image is displayed, and the progress bar is displayed too).
It corroborate what Huki said, ie. that the hidden loading screen images issue is not a consequence of the -sli command, there is 2 distinct issues.
(For completeness, I should also mention that I get an error message about 3D sounds in windowed mode.)
Also, when restarting a race, the loading screen images are displayed properly. But when going back to frontend, still no loading images. Then if I reload the same track from frontend, the loading images are still not displayed.
--> Loading images (and track info) are
only displayed when we restart a race.
- In
fullcreen mode, the loading screen is exactly the same than in windowed mode (same description than above).
The only difference I see is that without -sli, we have the "Can't flip display buffers" messsage (also giving the DDERR_INVALIDPARAMS directx error message), and using -sli, we can get rid of the "Can't flip display buffers" message.
--> The -sli comand does not change anything about the loading screen images.
Now, if we look at the source code, the EnableLoadThread() procedure [main.cpp] is responsible of drawing the loading images, with the blue frame and the text (loaded track informations), while the LoadThread() procedure draws the proress bar at the bottom of the screen (with the name of the last loaded file).
The reason why the "// draw pic" part (and other "// show level info", etc.) doesn't work in Vista while "// draw pic spru" is ok (as we can see the blue frame) is above my understanding.
And let's not forget the weird fact that it does work when restarting a race, which means that it
can work in Vista, at least in some cases.
As far as I'm concerned, I'm done with this issue. I have spend a lot of time on it, so unless I see a fresh new idea, I'm giving up.
about -sli
And just for info, as you can't find it in the source code, the action of the -sli command is to always execute the "FlipBuffers();" command in the LoadThread() procedure [main.cpp].
Code: Select all
if (FullScreen) //§DIFF the -sli command line action is here
FrontBuffer->Blt(NULL, BackBuffer, NULL, DDBLT_WAIT, NULL);
else
FlipBuffers();
Posted: 07 Aug 2010, 01:40
Huki
Jig - Load Pic wrote:
And let's not forget the weird fact that it does work when restarting a race, which means that it can work in Vista, at least in some cases.
It could be because of delayed loading of the pics as Urne said. We see the image while restarting since, now, it is already loaded.
I don't know about the loading spru, but isn't the same function used to draw menu sprus? Something must be different with it..
Posted: 07 Aug 2010, 03:22
jigebren
I don't think it can be just a simple a question a delayed pid loading, as it would not explain why the track informations (and the re-volt logo) are also not displayed when loading a track.
Moreover, the loading of the 4 textures ("// load bmp's") is simple to locate in the EnableLoadThread() procedure, and it's clearly before the texture display ("// draw pic"). As loading and display both occurs in the same procedure, there is no way their order can get reversed.
Also, I'm not sure we can consider that the texture are already loaded when restarting a track, as the textures are freed just after they are displayed ("// free bmp's")
And yes, the function used to draw the loading spru (blue frame) is the same than for the menu (at least I think), but... well, for example, it's likely that the track infos are also displayed with the same function used to display the last loaded file (in the progress bar), and it works in one case while it fails in the other...
Posted: 07 Aug 2010, 12:35
urnemanden
Thanks for looking into it, Jig.
Jig wrote:(For completeness, I should also mention that I get an error message about 3D sounds in windowed mode.)
I can confirm that this error occurs on Windows Vista Home Basic x64 as well.
Jig wrote:I was thinking about simply trying to skip the popup message, I'm just curious to see the result in that case.
As far as I remember, I have displaying bugs when getting past the popup message (of course, now I can't get past it at all).
EDIT:
Re-Volt Bug: Black car only after explosion while having bomb
It happens if you for example drive into a fake pickup and explode while having a bomb as weapon. all kind of bomb-animation will dissapear (with the exception of the blackyness) and the bomb sound will continue being played till you explode. It's not a huge problem, but it's a bug I thought I wold report now I noticed afterall. =)
Oh, and I guess you already considered implementing the texture re-sizer into Patcher tab aside to the 512patch? I just wanted to hear your opinion about that.
Posted: 08 Aug 2010, 01:08
jigebren
Jig wrote:I was thinking about simply trying to skip the popup message, I'm just curious to see the result in that case.
I just think I won't even try this, now that we're quite sure that the -sli fix the display buffer issue, and that it has nothing to do with the missing loadlevel images.
Re: Re-Volt Bug: Black car only after explosion while having bomb
You're right, Urne. In fact, they are managing the car bomb and the clone pickup separately, but unskillfully share the same variable for the car state. So when the car explode with the pickup, its "bomb" state get reset.
It would be easily fixable in the source code, but I have not enough place in the binary code to try to add a patch for this, unfortunately (or it would be too complicated).
Urne wrote:Oh, and I guess you already considered implementing the texture re-sizer into Patcher tab aside to the 512patch? I just wanted to hear your opinion about that.
Yep, but I won't do it, because it would complicate the WolfR4 source code, and overload the interface wihtout a real benefit. Adding my paches to WolfR4 was having a sense, because it was better to have a common tool for all patches. But for now, I believe that the RV Textures Resizer has better to stay a standalone tool.
A good intermediate solution would be to make them working jointly (WolfR4 could call RVTR), but I'm not sure I'll ever do it.
Posted: 08 Aug 2010, 01:12
Huki
jigebren @ Aug 6 2010, 06:50 PM wrote: about -sli
And just for info, as you can't find it in the source code, the action of the -sli command is to always execute the "FlipBuffers();" command in the LoadThread() procedure [main.cpp].
Code: Select all
if (FullScreen) //§DIFF the -sli command line action is here
FrontBuffer->Blt(NULL, BackBuffer, NULL, DDBLT_WAIT, NULL);
else
FlipBuffers();
But isn't it the FlipBuffers() function which is causing the problem? If what you say is true, it is the Blt that is causing the error in vista?
Posted: 08 Aug 2010, 02:40
jigebren
Huki @ Aug 7 2010, 08:42 PM wrote:But isn't it the FlipBuffers() function which is causing the problem? If what you say is true, it is the Blt that is causing the error in vista?
Yep, the issue actually occurs in the FlipBuffers() procedure (not verified but it's quite sure), but not necessarily in
this call. I also had some difficulty to understand it at the beginning, but that's a fact.
It could be the Blt called in the load thread that prevents another FlipBuffers() call in the main thread to be conduced properly (at least that's what I imagine).
Let's keep in mind that whatever is called (FrontBuffer->Blt or FlipBuffers()), the flip buffer error message rather occurs at the end of the track loading, not right at the begnning, so it means that
several calls have been successful before the error occurs. I mean that the error propably occurs under a specific circumstance only (not at every call).
About another subject, can someone please confirm that the shortcut button to set the Win98 compatibilty mode actually works in
Win7, I mean that if you look at the property of revolt.exe, this setting is changed when using the WolfR4 button.
It didn't seem to work yesterday when I made some tests under Win7 (for info I was running revolt from a USB flash drive).
Also, I had to run WolfR4 in administrator mode to be able to launch revolt in Win7. I'm not very accustomed to Vista/Win7, but if someone can clarify it, maybe I should mention it in the WolfR4 help?
Posted: 08 Aug 2010, 04:21
Huki
Setting Win98 Compatibility in Win7 from Wolf works, (the option changes in properties window). I don't have to run wolf as administrator either.
But Vista and 7 have a feature called User Account Control. It has been a huge pain for me when i first started to use Vista, so the first thing I ever did after installing Win7 was to disable UAC. Most computers with vista or 7 would have UAC on, and this might require you to run wolf as administrator and prevent you from changing the exe properties.
Posted: 08 Aug 2010, 13:23
urnemanden
Possible WolfR4 Bug: No Custom Detection at Refresh
Today I tested out some of hilaire9's beta custom tracks, but was only able to load Dali correctly. The rest either didn't show any sign of being custom or had stock objects floating around instead (even tho Nebula-girl looked custom in the start). Here is the WolfR4 log:
WolfR4 Log wrote:09:03:29. WolfR4 startup. (release: 2010-07-28)
09:03:29. Frequency of the high-resolution performance counter: 14318180 (recommended shifting value: 4)
09:03:48. << Re-Volt is launched.
09:04:00. Reverse Track detected: Venice
09:04:00. Reverse Track detected: Rooftops
09:04:00. Reverse Track detected: Quake!
09:04:00. Reverse Track detected: PetroVolt
09:04:00. Reverse Track detected: Luigi Raceway
09:04:00. Reverse Track detected: GBA Rainbow Road
09:04:00. Re-Volt track loading detected: Frontend
09:04:18. Re-Volt track loading detected: WR4_DALI
09:04:18. Loading Custom Track data: WR4-Dali
09:09:46. Re-Volt track loading detected: Frontend
09:09:46. Unloading Custom Track data: WR4-Dali
09:11:32. Re-Volt track loading detected: WR4_NEBULA
09:16:07. Re-Volt track loading detected: Frontend
09:17:39. Re-Volt track loading detected: WR4_INTERSTEL
09:22:45. Re-Volt track loading detected: Frontend
09:34:32. Re-Volt track loading detected: WR4_TERMINUS
09:39:15. Re-Volt track loading detected: Frontend
Quitting the game and restarting WolfR4 fixed the problem, but I will try reproduce this bug, to see if it wasn't just a coincidence (which I believe it isn't). To your information, I was in frontend everytime I pressed the
Refresh User Tracks button, to make the next track appear (I installed them one-by-one).
EDIT:
Ah, thanks for clearing things out for me. I didn't press the track info button too, forgot it because it was on another tab. =P
Posted: 08 Aug 2010, 14:18
Huki
Refresh User Levels will make re-volt (while running), detect the new tracks.
Refresh Track Info is the option that makes Wolf detect new tracks and Full Custom tracks.
So you need to click both these options for the wolf-track to work correctly.
Request - Uninstall Multiple Tracks
I see that selecting multiple tracks and uninstalling only uninstalls the first track. Maybe you can implement this feature..
Posted: 08 Aug 2010, 17:38
jigebren
@Huki, about Vista and Win98 Comp.
Thanks for the test and the clarification, Huki. UAC was the word I was trying to remember (I had already read something about it, but it went out of my mind). I should have to add a notice about it in the WolfR4 doc.
Re:No Custom Detection at Refresh
Yep, Huki's anwer [FIXED: I had written "Urne's anwer"...] is totally right. I understand it's not very clear, but Refresh User Levels acts only on re-volt.
Maybe I could link it to the Refresh Track Info button. But I'm not sure it's possible, I remember having allready considered it, but it was not my priority at the moment...
Re: Request - Uninstall Multiple Tracks
Ok, I'll check it soon. Maybe it was linked to the same bug that Huki reported (about Track Packer and multi tracks selection), in that case it would be already fixed. I'll see.
EDIT: It was another bug, because the code was not designed at first to support multi-tracks selection. I'm fixing it. In fact, I'm modifying the Track Packer and Uninstaller code so that we only get prompted once to confirm the action for all tracks, instead of being prompted for each track.
Posted: 09 Aug 2010, 13:59
urnemanden
Jig, I was wondering how you inform people about a new update, if you release one? Does WolfR4 have any kind of update notifier? Afterall not everybody is in the e-mail chain you're running now that it's possible to download WolfR4 directly from your website (I am not saying that's a bad thing
).
Posted: 09 Aug 2010, 18:35
jigebren
@urnemanden
Well, I'll do exactly like for the beta version. I mean, I'll notify it here in this topic and I'll (probably) send an email to all beta testers.
If someone want to be informed by email, he can still send me a message to be added to the beta tester mailing list.
I won't add any update notifier to WolfR4, because I don't feel like spending time on this feature (I have not a single idea about how it has to be done...), and also (and mainly) because I don't like apps that try to connect themselves to internet while there is no obvious reason to do so. Of course, update notifier could be an obvious reason, but I mean WolfR4 is not an internet application... Well, it could sound a bit "oldschool", but that's the way I feel about it...
Posted: 10 Aug 2010, 06:24
jigebren
A new update for WolfR4, and a quite great one...
I have fixed the 3 WolfR4 bugs that have been reported by Huki, Miro and Urne.
Following Urne's question, I have also modified the "Refresh User Levels" so that it refreshes the track info in both re-volt and WolfR4.
2 new re-volt bugfixes have been added:
The 1st should prevent re-volt from crashing when quiting an online lobby race session.
The 2nd to be able to race normally after a "Host Started Game With Unknown Track!" message, when the host has loaded a track you don't own.
I have reworked several feature in the Tracks tab.
"Track Packer" and "Uninstall Track" have been modified to ask for confirmation only once at the beginning when several tracks are selected.
When using "Track Packer", the 7zip console is shown to see the progression of the compression in real time (but the result is not added to the WolfR4 Log anymore).
The "Track Packer" can now create the archive elsewhere than in the re-volt directory, as Huki requested several times.
And also, as some features like "open .inf file" or "delete custom.ini" could be usefull but I didn't feel like adding a button for each of these features, I have now added a pop-up menu to the tracks list (accessible with a right click). Check in the changelog below the features added to this menu.
* Rel.10-08-10
Fix: Fixed a bug when using "Track packer" on several tracks.
Fix: When using "Pause on car preview", once you have selected a user car, if
you decide to select another user car the selected car is not refreshed.
This bug is now fixed.
Add: A new re-volt bugfix:
Re-Volt should not crash anymore when quitting a online race in lobby
mode (eg. when using RVHouse).
Add: Another re-volt bugfix:
During a multiplayer race, when the host launches a track that you
don't own, the "Multiplayer Game Terminated!" message won't bet displayed
anymore. You'll only see "Host Started Game With Unknown Track!" blinking
on the screen. But you should be able to get back in the race when the
next track is loaded, and the blinking message will disappear.
Notice that it won't work if the host load an unknow track right at the
beginning of the session.
Fix: Fixed a bug when using "Uninstall Track" on several tracks.
Add: Using "Refresh User Levels" button should now also refresh the tracks
info and custom.ini content (acts as if the "Refresh Track Info" button
is also pressed).
Mod: The "Refresh Cars Info", "Refresh Player's car" and "Refresh User Levels"
buttons are now disabled when re-volt is not running.
Mod: "Track Packer" and "Uninstall Track" have been reworked to ask for
confirmation only once when several tracks are selected.
Add: The "Track Packer" can now create the archive elsewhere than in the
re-volt directory (Use the new "..." button to set this directory).
Add: A pop-up menu has been added to the tracks list (accessible with a right
click) with new features:
Set as current track: same as double-clicking the track, but doesn't
launch re-volt automatically.
Open custom.ini file: same as the corresponding button, but doesn't
allow to create a default custom.ini.
Open .inf file: self-explanatory.
Open track folder: similar to "Open Track Folders", but opens only the
main track folder (the one in the ".\levels\" directory).
Get files list: displays the list of directories and files used by a
track (in the Log tab). For example, this is the list used when
creating an archive of the track, or when deleting a track.
Delete custom.ini file: self-explanatory.
I hope I haven't introduced too much new bugs, as I have modifed/added a bunch of stuff in the code.
I'll wait a little to see if there is no particular issue with this releease before updating the link on my webpage (so keep up with reporting feedback).
EDIT:
Here is the link to the last release file, for those who are not in the beta tester mailing-list:
WolfR4 - Rel.10-08-10.zip
Posted: 10 Aug 2010, 16:01
arto
jigebren @ Aug 10 2010, 01:54 AM wrote: The 2nd to be able to race normally after a "Host Started Game With Unknown Track!" message, when the host has loaded a track you don't own.
Just a quick thank you for the continued work on this excellent tool.
I was especially pleased about the above new fix.
Posted: 11 Aug 2010, 10:26
Huki
The new version has no bugs and some interesting features/fixes. I think you can release it already..
---
Re-Volt Multiplayer Bug - Bad Start
When someone crashes or quits an online race, and the next race is started, some people immediately get the GO sign and can race, while others wait as usual for the countdown. Every session, someone keeps crashing (what can you expect from P2P), and this bad start is a stressful bug.
I think this is caused because
all players check if all other players are ready. CheckAllPlayersReady(); is executed for everyone in a session. But microsoft seem to have modified this, so that only the host checks if all players are ready.
Gameloop.cpp wrote:
if( IsServer() ) //$ADDITION -- only server checks if all clients are ready
CheckAllPlayersReady();
Do you think there is enough space to add this test? Or maybe another way to fix the bug...
Vista-Revolt Stuff
Well, I am back at this topic
There are 4 loading bitmaps that are joined together and displayed during loading. How are they joined? I'm guessing the 4 bitmaps are Blitted onto a single surface. And at the end of loading screen, the surface is flipped. Now, if this blitting procedure fails, there will be no surface to flip, thus giving an "invalid parameter" to Flip function. When -sli is used, Blitting is skipped, and things work correctly.
Crazy idea eh? Though i would mention it anyway...
Posted: 11 Aug 2010, 19:56
jigebren
Ok, I have updated the WolfR4 webpage with the new release (only the download link, not the docs...).
Re: Re-Volt Multiplayer Bug - Bad Start
I believe it won't be simple to find the real source of this bug...
Yes, they have added the " if( IsServer() )" test in gameloop, but if you look carefully, they have removed it at the beginning of CheckAllPlayersReady():
network.cpp wrote://$REMOVED
// if (!IsServer())
// return;
//$END_REMOVAL
So the result is the same without the xbox modif, the procedure is already skipped for non-host players (I have also checked in binary and the above test exists).
Maybe the glitch could come from the ProcessCountdownStart() [network.cpp]. It seems that if the client has already received a proper sync reply, the countdown time is corrected to start in sync with the host. But the calculations seem correct...
Or maybe it's because some clients never get a proper sync reply, thus don't apply the correction. But it would mean that the correction would be greater than severals seconds (with lower delay, the bad start bug wouldn't be perceptible), and I don't know if that can happen.
Or in the SendCountdownStart(), I don't know if the SendMessageGuaranteed() could get some delay when sending the message to all players. But I doubt it could get more than 5 seconds delay...
Posted: 11 Aug 2010, 20:34
jigebren
Re: Vista-Revolt Stuff
Well, I can't really tell more about it...
The only thing I can do for now is adding these infos about the loading bitmaps.
The 4 loading bitmaps are displayed in EnableLoadThread() [main.cpp] with 4 calls to:
D3DDevice->DrawPrimitive(D3DPT_TRIANGLEFAN, FVF_TEX1, DrawVertsTEX1, 4, D3DDP_DONOTUPDATEEXTENTS); (after having properly filled the DrawVertsTEX1 array)
FVF_TEX1 is defined by:
#define FVF_TEX1 (D3DFVF_XYZRHW | D3DFVF_DIFFUSE | D3DFVF_SPECULAR | D3DFVF_TEX1)
The texture is set with:
D3DDevice_SetTexture(0, TexInfo[RenderTP].Texture)
Posted: 12 Aug 2010, 06:44
jigebren
In case it still interest somebody (I began to wonder, seeing the lack of anwser/feedback/support here,...), I'm currently working on a quite complex new feature: I'm trying to implement the support for user Stunt levels.
It seems quite promising for now...
WolfR4 will detect Stunt levels when a file with a defined name exist in the track folder. Then I was able to add the possibility to choose the track even in Stunt mode. And only the Stunt tracks will be selectable in that mode. Additionally, stunt tracks will be properly hidden when choosing a track in an other race mode.
And last, the stars progression should be keep for each stunt track independently (in a file placed in the track directory).
The track could have any number of stars (from 1, up to 64 I think).
Posted: 12 Aug 2010, 11:28
urnemanden
Sounds very promising to me, I'll gladly test that out when you're ready for the next release.
The latest version of WolfR4 is working just fine btw, I haven't had a single crash when exiting an online race yet. Unfortunately I still have spontaneous crashes pretty often while being online host and when Dr. Watson pops up it tells that the process left memory so early that it couldn't attach any information other than a Windows error code. I think the crashes are connected to the bomb weapon and exploding animation, but I cannot come up with any theory due to my not-so-wide knowledge about Hex and such.
Posted: 12 Aug 2010, 17:53
jigebren
Bomb bug in multiplayer
urnemanden @ Aug 12 2010, 06:58 AM wrote:Unfortunately I still have spontaneous crashes pretty often while being online host and when Dr. Watson pops up it tells that the process left memory so early that it couldn't attach any information other than a Windows error code. I think the crashes are connected to the bomb weapon and exploding animation [...]
Fortunately, I played re-volt recently with a friend in LAN at home, and re-volt crashed when I was just about to transmit the bomb to the other player. I said
fortunately because I was able to save the Dr. watson log file.
Urne, just to be sure, can you confirm that you're also talking about the firecracker bomb (not the water bomb)?
And also, can you say if it crash
only when you're giving the bomb to another player, or have you already noticed a crash when receiving the bomb from another player (or in any other condition)?
Posted: 12 Aug 2010, 20:26
Juicy J
jigebren @ Aug 12 2010, 01:23 PM wrote: Urne, just to be sure, can you confirm that you're also talking about the firecracker bomb (not the water bomb)?
And also, can you say if it crash only when you're giving the bomb to another player, or have you already noticed a crash when receiving the bomb from another player (or in any other condition)?
If I can answer, as I hosted many sessions I think most of the time it happens when a host is about to blow up (at least for me). Also I must say it doesn't happen on every map, only Ndahood1 and maybe Ghost Town 1 are crash happy.
Posted: 12 Aug 2010, 22:35
jigebren
Juicy J @ Aug 12 2010, 03:56 PM wrote:[...] I think most of the time it happens when a host is about to blow up (at least for me). Also I must say it doesn't happen on every map, only Ndahood1 and maybe Ghost Town 1 are crash happy.
That's weird, for me it clearly happens when transmitting the bomb to another player. But I agree on one point, it doesn't happen on every track, and that confused me for a while.
I can clearly reproduce the bomb bug that way:
- I launch a multiplayer race (I tried in LAN) with the
nhood1 track, when I get the bomb pickup, as soon as I touch the other player's car, re-volt crashes (on my computer only, the other player has no issue).
- If I start with the market2 track, it doesn't crash.
- If I start with the market2 track, get the bomb pickup at least once, and I restart the race with the nhood1 track, then it doesn't crash anymore.
- But if I start with the market2 track, then I restart the race with the nhood1 track (without having gotten the bomb pickup in market2), then it will crash in nhood1.
As you can see, it's quite weird.
I have clearly located the bug (I mean, where the crash takes place), but I don't understand the real source of the bug.
So I can't write a real fix to this issue, but at least I can
prevent re-volt from crashing when the bug occurs. In this case, the bomb will act strangely: It may not be transferable to other players, or the player will get the bomb but your car will also explode... but I think this drawback is still better than a re-volt crash...
Posted: 13 Aug 2010, 01:17
Huki
jigebren @ Aug 12 2010, 10:35 PM wrote: I can clearly reproduce the bomb bug that way:
- I launch a multiplayer race (I tried in LAN) with the nhood1 track, when I get the bomb pickup, as soon as I touch the other player's car, re-volt crashes (on my computer only, the other player has no issue).
Yes the crash happens when you touch another player's car not when you're about to explode. But you say it happens everytime? Not here..
1)started nhood1 with 6 players-->got bomb many times, no one crashed.
2) Another new session: started market2 and immediately restarted nhood1. Got many bombs, transfered them, no crash.
3)restarted ghost1. Got 2 bombs, but we couldnt transfer it in time. At the end i get another bomb, transfer it to Urne and I crashed. My car was still black when icrashed, and his car was normal. But he actually got the bomb and nothing unusual happened. Only I crashed.
From what i see, there is so pattern or way to reproduce this. Sometimes it happens, sometimes not.
---
And another thing is that SADIST (All Weapons cheat) doesn't work online. So it took a long time for these test. Can you enable it online too?
Posted: 13 Aug 2010, 01:22
Huki
Re: Re-Volt Multiplayer Bug - Bad Start
jig wrote:So the result is the same without the xbox modif, the procedure is already skipped for non-host players (I have also checked in binary and the above test exists).
Hmm, but all players see Waiting for: <other players who havent loaded yet>
We dont just see Waiting for: Host. Even after the 10sec timeout, revolt freezes. Some players' freeze ends quickly and they get 3-2-1-go countdown. Others get frozen for along time and then start then. There must be some confusion here..
Posted: 13 Aug 2010, 07:46
jigebren
Huki @ Aug 12 2010, 08:47 PM wrote:And another thing is that SADIST (All Weapons cheat) doesn't work online. So it took a long time for these test. Can you enable it online too?
That's what I did (with a quick and dirty patch directly in the debugger). But I can't/won't add this option in WolfR4, as it could be used to cheat online...
Yes the crash happens when you touch another player's car not when you're about to explode. But you say it happens everytime? Not here
For me, it clearly happens everytime. But as I was able to force the bomb pickup selection, all my tries were very similar to each other: I start a race, select the bomb pickup, touch the other player's car and see what happens.
Tonight, I have raced with a friend, and it seems that my last "bomb patch" seems to work as expected, ie. sometime the bomb transfer doesn't work or weirdly, but at least it doesn't crash re-volt and the race can continue.
Posted: 13 Aug 2010, 08:16
Cat
it's me or the MP3 playback doesn't works with custom tracks?
Posted: 13 Aug 2010, 08:50
Huki
Cat @ Aug 13 2010, 08:16 AM wrote: it's me or the MP3 playback doesn't works with custom tracks?
It's you.
Jig wrote:That's what I did (with a quick and dirty patch directly in the debugger). But I can't/won't add this option in WolfR4, as it could be used to cheat online...
You can add this in DEV panel. Or atleast send me the patch so i can see what is different. Because for me and everyone else in rvhouse, bomb crashes happen randomly and also rarely these days. The bomb crash is all luck for us.
Posted: 13 Aug 2010, 18:45
jigebren
Huki @ Aug 12 2010, 08:52 PM wrote:Re: Re-Volt Multiplayer Bug - Bad Start
jig wrote:So the result is the same without the xbox modif, the procedure is already skipped for non-host players (I have also checked in binary and the above test exists).
Hmm, but all players see Waiting for: <other players who havent loaded yet>
We dont just see Waiting for: Host. Even after the 10sec timeout, revolt freezes. Some players' freeze ends quickly and they get 3-2-1-go countdown. Others get frozen for along time and then start then. There must be some confusion here..
Well, I'm not sure I get it... Are you suggesting another idea, or is it a simple statement here?
Huki wrote:You can add this in DEV panel. Or atleast send me the patch so i can see what is different. Because for me and everyone else in rvhouse, bomb crashes happen randomly and also rarely these days. The bomb crash is all luck for us.
I have another idea, I can temporarily include an option that will force only the bomb pickup. You won't need the SADIST cheat, and nobody can cheat with such an option...
I have to implement it, then maybe I can email it to you. You'll also be able to try the new Bomb bugfix...
Enable Battle Mode for User Tracks
I'm also thinking about adding the possibility to have
user battle tag tracks.
I mean, they would be added to the list of Battle tracks,
without having to overwrite any of the 4 stock battle tracks. I would previously have thought it was impossible, but in fact, it was less complex than adding support for user stunt tracks....
But I need some user battle tracks to try it. Is there any already available somewhere?
Posted: 13 Aug 2010, 19:16
arto
jigebren @ Aug 13 2010, 02:15 PM wrote: But I need some user battle tracks to try it. Is there any already available somewhere?
http://rvzt.zackattackgames.com/main/tr ... ory=battle
Related to Wolf, I'm in the process of adding support for submitting Wolf tracks to RVZT. Anything else that I should take into account than having the submitter be able to give the "WolfR4 id" (or is there a better term for it?) of the track, and checking there is not duplicate entry. I remember it's 5 letters?
I hope to have it done in a quick and dirty fashion today, but we'll see if I have enough beer for that.
Posted: 13 Aug 2010, 19:42
jigebren
Ok, thanks for the link, arto. I was not able to find the battle category when I tried yesterday (too much beer, probably...).
Is there also a "stunt" category?
And thanks for adding Wolf support to RVZT...
About the folder in the '#' directory, it's up to the track maker to choose the number of letters. 5 letters are recommended, but less can be used. Even more than 5 lettters could also be used (as long as no path exceed the max. allowed lenght).
But if you want to automate the "wolfr4 ready" track detection process, maybe you could just check for the "custom.ini" file in the main track folder.
Posted: 13 Aug 2010, 20:26
MOH
Ive recently tried Wolf and first impresssions are that its really impressive!
not sure if its been said already, but in time trial mode with the ghost car, it only loads the ghost cars texture, for example here, im driving cougar, against a ghost of toyeca, but cougar has toycea's texture
http://s267.photobucket.com/albums/ii30 ... xtures.jpg
other than that im very impressed! thanks
Posted: 13 Aug 2010, 21:54
jigebren
Thanks, MOH.
Abou the ghost car texture issue, it's weird...
I can't remember that anyone has already reported that.
So I have just tried with the same cars in the same track, and it was ok.
I don't know what was wrong for you...
Posted: 14 Aug 2010, 00:02
Huki
jigebren @ Aug 13 2010, 06:45 PM wrote: Huki @ Aug 12 2010, 08:52 PM wrote:Re: Re-Volt Multiplayer Bug - Bad Start
jig wrote:So the result is the same without the xbox modif, the procedure is already skipped for non-host players (I have also checked in binary and the above test exists).
Hmm, but all players see Waiting for: <other players who havent loaded yet>
We dont just see Waiting for: Host. Even after the 10sec timeout, revolt freezes. Some players' freeze ends quickly and they get 3-2-1-go countdown. Others get frozen for a long time and then start without the countdown. There must be some confusion here..
Well, I'm not sure I get it... Are you suggesting another idea, or is it a simple statement here?
You say that re-volt already checks if the player is server before checking if all players are ready. But revolt seems to check if all players are ready, even if you are not the host. The player's who are not ready (including people who crashed) appear in the Waiting For: list for everyone, not only the host. At the end of the Waiting For: countdown (10sec with wolf), if there are players who had crashed, revolt freezes for some players. What happens after that is a little confusing..
So now i had another thought, why freeze? I think the problem would be solved if re-volt can immediately cut the connection for players who are not ready after the 10sec instead of freezing up leading to bad start.
@MOH: You have custom HUD. Was it activated by Wolf using a custom.ini or did you do it manually? Maybe it screwed up the ghost textures..
Posted: 14 Aug 2010, 00:50
arto
jigebren @ Aug 13 2010, 03:12 PM wrote: Ok, thanks for the link, arto. I was not able to find the battle category when I tried yesterday (too much beer, probably...).
Is there also a "stunt" category?
And thanks for adding Wolf support to RVZT...
About the folder in the '#' directory, it's up to the track maker to choose the number of letters. 5 letters are recommended, but less can be used. Even more than 5 lettters could also be used (as long as no path exceed the max. allowed lenght).
But if you want to automate the "wolfr4 ready" track detection process, maybe you could just check for the "custom.ini" file in the main track folder.
Not the fault of the beer this time, unfortunately. Quite a while ago, I got to pruning the menu so that it would contain only the mere minimum for clarity's sake. Some options therefore are not visible anymore, yet are accessible for those who know the magic words (or can check them from the source).
Is there also a "stunt" category?
No. There hasn't been enough stunt tracks to warrant that. I think I've seen only one or at most a couple stunt replacement tracks.
About the folder in the '#' directory, it's up to the track maker to choose the number of letters. 5 letters are recommended, but less can be used. Even more than 5 lettters could also be used (as long as no path exceed the max. allowed lenght).
Well okay... I don't quite understand what's the maximum length, so I put it to 16 letters. Should be enough.
But if you want to automate the "wolfr4 ready" track detection process, maybe you could just check for the "custom.ini" file in the main track folder.
That would be nice. But unfortunately it will be track approver's manual job to check the submission is correct
. The problem is unpacking a track on the server side. Not many servers allow to do that, I'm not sure if Zach's does or not. Even if it did, many track makers fail to pack their tracks correctly, so the tracks often require manual effort for investigating and repacking anyway.
Anyway, I had enough beer and RVZT pages are updated for WolfR4 support. I know Hil at least has some tracks that he has Wolfified, so I'll talk to Hil about getting them to RVZT soon. I also put WolfR4 link to more prominent place in the page, at least for now, so that everyone visiting RVZT should get a good look at it.
Will be posting later a bit more to more appropriate topic about the changes, but if there's anything you see there that needs altering, let me know. it was a quick and dirty job becase I didn't want to put too much effort into it as Zach's proper rewrite is coming. But I think it's important to have RVZT supporting Wolf tracks right now as Wolf's become publicly available.
Posted: 14 Aug 2010, 04:07
jigebren
Huki wrote:You say that re-volt already checks if the player is server before checking if all players are ready. But revolt seems to check if all players are ready, even if you are not the host. The player's who are not ready (including people who crashed) appear in the Waiting For: list for everyone, not only the host. At the end of the Waiting For: countdown (10sec with wolf), if there are players who had crashed, revolt freezes for some players. What happens after that is a little confusing..
Ok, I see what you mean now.
Well, in fact, as far as I have understood, the server checks if all players are ready, and when it's done, it send the MESSAGE_COUNTDOWN_START to all players. Others players don't really "check" if other players are ready, but they simply wait for the MESSAGE_COUNTDOWN_START message from the server.
But it's true that as long as this message is not sent by the server, each player displays the list of non-ready players by testing the "ready" status for each players (check "// waiting for network players?" in [panel.cpp]).
huki wrote:So now i had another thought, why freeze? I think the problem would be solved if re-volt can immediately cut the connection for players who are not ready after the 10sec instead of freezing up leading to bad start.
Unfortunately, I think I have not a single idea about how to proceed for now... I'm slowly understanding more and more things in the source code, but there is a still lot of stuff that are out of my understanding
Arto wrote:QUOTE
Is there also a "stunt" category?
No. There hasn't been enough stunt tracks to warrant that. I think I've seen only one or at most a couple stunt replacement tracks.
That's true. At least I have found "zipper stunt", and after some little modifications, I was able to load it in re-volt (without modifying the original stunt level). Well, I think the stunt mode could deserve more tracks, as it can be quite fun too...
arto wrote:Well okay... I don't quite understand what's the maximum length, so I put it to 16 letters. Should be enough.
It's not very complicated, only explaining it is complicated...
If you look in a custom.ini file, for exemple the "#\?????\lantern.m" line, it's written "19 characters allowed". So it doesn't matter if you use "#\trk\lantern.m" or "#\my_own_track\lt.m", but the line has to be shorter than 19 chars.
But you can see that if you use a too long name for the sub-folder, the name of each file will have to be very very short, and that won't be practical. So, using a lenght of 5 chars for the sub-folder will be appropriate for most cases.
To conclude, 16 letters will be enough for sure...
arto wrote:jigebren wrote:But if you want to automate the "wolfr4 ready" track detection process, maybe you could just check for the "custom.ini" file in the main track folder.
That would be nice. But unfortunately it will be track approver's manual job to check the submission is correct sad.gif. The problem is unpacking a track on the server side. Not many servers allow to do that, I'm not sure if Zach's does or not
I'm quite sure Zach's server can unzip files, as I once asked him about zip or 7zip format, and he told me roughly "ok for zip, not sure for 7zip".
Anyway, I had enough beer and RVZT pages are updated for WolfR4 support. [...] But I think it's important to have RVZT supporting Wolf tracks right now as Wolf's become publicly available.
Ok, thanks for all your efforts, arto, that's nice (except the typo: Wolf4R instead of WolfR4
). And of course I agree that it's a good thing to have RVZT supporting WolfR4. It will help to let re-volt users and track makers know that WolfR4 exists, and it will greatly help to spread good wolfed tracks like Hil's ones.
PS: I won't be here during this week-end...
