So I finally found where they where hiding those codes...
#1
(Frillis: Is it ok if I create a new section on the forum for the original rollcage games?)

Ok, yesterday I had some spare time and decided to finally get working on a (cheat)code searching program for rollcage/stage2. After writing (and painfully debugging some silly mistakes) I had a C program which would load a file to memory, search for a term (with various strides, and with any kind of startingpoint for alphabetic characters, assuming B=A+1, C=A+2, etc). And I found one match for "billy" in ROLLCAGE.IMG!

Unfortunately, it seem to have been just a random term (just garbage before/after). Then I decided to do what I should have done in the first place: I ran "strings" on the d3d and glide exe files (not the launcher) and searched for interesting stuff. And of course I found the codes. They were there the whole time, as simple strings. Although in reverse.Wink

So, after analyzing some different versions of the games, I can give what I believe is the complete list of codes, including a previously unknown code for stage2:

The D3D and Glide versions all contains the same codes:


ROLLCAGE 1:

Patched and P4 version (with or without patch):
  • jackimflying
  • flymetothemoon
  • bringmebackdowntoearth
  • snar
  • billythewhizz
  • warpspeedmrsulu
  • wreckedonspeed
  • givemescorpio
  • givemetaurus
  • trotters
  • reflections
  • bigandpink
  • networkfun

Unpatched:
the same as above, but with:
  • iamalazybastard

I thoughts I had found a new code, but I think it was just a random string: ba402391 (in reversed form, like the other codes: 193204ab)


ROLLCAGE STAGE II

Unpatched:
  • givemetheguysback
  • metropolis
  • mynameisneo
  • mynameismrsmith
  • inversion
  • wreckedonspeed
  • warpspeedmrsulu
  • itisiwhoammad
  • billythewhizz
  • snar

Patched (NEW!):
  • proceduraltextures

The last one is a new code! Unfortunately, it seems to only freeze parts of the background animations in the menus. I'd love to be proven wrong here, so please try it and see if anything else changes!Undecided

RANDOM FUNNY STUFF
Both games got a string called "ATDCUNNINGDEBUGVARIABLE" (among others). I found it a bit funny... Maybe just me.Big Grin

Also, stage2 had what I think are the playstation codes (but rc did not):

Code:
NOW.THATS.WHAT.I.CALL.RACING.147
PURSUIT,.A.SUIT.MADE.FROM.CATS..
HERE.TODAY,.GONE,.LATE AFTERNOON
IM.OBVIOUSLY.SICK.AS.A.PARROT...
LOOK.OUT!.ITS.ANDY.GREEN........
I.AM.THE.MIRROR.MAN,.OOOOOOOOOO!
IS.IT.COLD.IN.HERE.OR.IS.IT.ME.?
WELL.IF.IT.AINT.THEM.PESKY.KIDS.
YOU.HAVE.A.LOTA.EXPLODING.TO.DO.
WHEELS,.METAL,.ITS.....THE BIN !
I.WANT.IT.ALL.AND.I.WANT.IT.NOW!
MASTERS.IS.AS.HARD.AS.NAILS.MON!


INTERESTING STUFF
There's bound to be more interesting stuff if digging deeper, but here's something worth mentioning in Stage2:

Code:
Game Type :          
League
Time attack
Two Player
DeathMatch
Arcade
OPM Timeattack
Across
Demolition
Soccer
pursuit
race all tracks
survivor
split tournament
knockout
training
combat racing
NetworkFull
NetworkHeadToHead
NetworkTurbo

Notice the mode called "Across"? Either another name for scramble mode or something trashed in the last minutes before release. Also, does NetworkTurbo ring any bells? (I haven't played networked so much so I don't know... Well, anyone up for a match some weekend!Cool)

Also, there's the list of cars to select:
Code:
Pick Cars :
Car body :
1 Taipan
2 Python
3 Diamondback
4 Mamba
5 Krait
6 Boa
7 Racer
8 Viper
9 BlackRat
10 Venom
11 Asp
12 Cobra
13 Amarilla
14 Reaper
15 Funnelweb
16 Ambush
17 BlackWidow
18 Huntsman
19 Wolf
20 Scorpion
Skin :
level :
Notice the unfamiliar names? They probably renamed some cars in the game interface, but kept the old names in the code. Also, they (correctly) refer to them as "Car body" and "Skin", instead of just car and level.
(the "level" part might have to do with track selection)

Well, that's all.

Now, if I could only figure out what that "ROLLCAGE.IMG" file actually is and contains...
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#2
I'd believe the Rollcage.IMG file is the ISO/image/package that contains all the major game content (such as models, textures, etc.) The problem may be that it might be an in-house encryption format (and the extension .IMG is simply a coincidence or deliberately chosen to throw people off successfully decoding it...)

If I knew any more about the game engine I'd probably have more of an idea as to how to decode that file but I don't..


But still ... what you found was interesting. O_O. I already had somewhat encountered all of those game codes anyway (I remember saying I'd got cheats for Stage II) but that new one I haven't seen before... I seem to have Stage II installed, so at some point I will try it. ;]

Grats. lol.
Now I have to go to work :|
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#3
(2012-03-13, 09:24 PM)Slinger Wrote: (Frillis: Is it ok if I create a new section on the forum for the original rollcage games?)

Dude, it's your forum - you don't need to ask!

In the versions I was poking around a year or so ago, it looked like a proprietary compression method was used- but most likely it'll be tied to whatever game-engine was used - rather than being an in-house design.

The impression I was left with (I didn't get too far) was that there doesn't seem to be much variation in compression technology - but different methods tweak ordering, buffer sizes, number of bits for indexing, etc.

It'd require a custom bitstream decoder to try various parameters - I saw some strings like "Playe32jd0s" which would be a good place to start, since the next character probably resolves to an "r". But that's a "when I have spare time" project for the distant future.
Reply
#4
Crap. and now I just realised that a lot of my research into the rollcage games was on the old forum. fuuuuuuuuu.

Oh well. I'm sure I can probably just figure it out again. I unintentionally debunked some of my own observations a while ago anyway.
(oh, and Slinger, I know I need to respond to your emails and I'll do so eventually, but there's one point you brought up that I clearly remember being surprised by - both your point, and that I remember something that could debunk it xDD)

But... I had wanted to type more in my original post, only now I forgot what I wanted to say.

So..

The cheats. I can't remember which cheats do what (I know there are working mid-gravity/low-gravity/normal-gravity cheats. I'll probably have to check those later. HOWEVER, I did just check the proceduraltextures cheat and I don't specifically notice anything different in-game, although I should probably try checking with and without it enabled to see if there is a particular difference in graphics.
Also I forgot until I tested the game but I still have it patched with that 'bump mapping fix' patch someone handily posted on the old board. Kinda amuses me that a game that ran on pentium 3/4's and only needed 4MB of graphics memory could use bump mapping. Bump mapping is a shader-model 1.1 thing or something? Rollcage certainly doesn't use shader 2.0 xD

That aside.

What you found out about the cars is definitely interesting - or at least the cars' development names. Most of them seem named after or reference snakes. (heh) It could just be a debugging feature, but it does suggest to me that originally there were no plans on having teams in the games, and they had just expanded the roster of available cars from 7 to 20. Since Yuri's car is on the boxart, it seems possible that they had first worked on a simple extension of the first game engine and setup (just changed the tracks, added more car models) but then over time modified it into what it ultimately became.

Certainly, the lack of a 6th car in-game (whereas both the intro video AND some of the menu tips suggest the game originally featured 6 cars in-game rather than 5) would go along with this. My guess is they removed the 5th AI driver due to issues with stability (the original rollcage did get some slowdown, which was never present on the sequel).
o_o

I think we should use these 'codenames' in ReCaged. At least the name 'Venom' is there.


But seriously now. We really do need to have the rollcage.IMG file decrypted. Considering I've looked EVERYWHERE and found no scope of any other useful data, it goes to suggest that all the 3D models are in that image. That, or they are in the ROLLCAGE.IDX file (which also seems encrypted). If we can get that thing open we could maybe find out some things about the game, namely the nature of the game models. I've attempted to do my own research on it but to no avail. Also despite it being depicted as an ISO file I can't mount it through a virtual drive daemon, and similarly none of my ISO editing tools recognise the file. GTA4's SparkIV program produces the same result, even though GTA4 also seems to use the same manner of protocol (there are several .IMG files containing game models)

Unfortunately, decrypting the file is one thing. Decrypting any contents once we get that far is another (unless all the models just randomly happen to be .obj format or something lol) but we should get to that when it gets there.



Finally - Slinger, two things.

1) I'm presuming Across was the development name for Scramble, so we don't need to worry about that one too much. Besides, Scramble is missing entirely from the list of game modes. Wink

And

2) You said in an email something regarding game physics and things not being realistically simulated. Specifically, you mentioned the car displays no roll when accelerating. Well, I do hope that I'm right and that they didn't actually just deliberately simulate the simulation of this to hide it, but in Stage II whilst attempting to get some sorts of the Vostok Reaper for dimension/layout purposes, I discovered that the car's body does shift its center of mass when it accelerates or brakes. You just don't notice it under normal gameplay but I had unintentionally got the camera panned into 'follow' mode (i.e. crashed) so I ended up driving perpendicular (sideways) to the camera from a standstill... the car exhibited roll. (nose lifted up, tail lifted down).

I'd noticed anyway that the cars lean when they turn. I do know however that this is present only in Stage II, but we all know they had modified the game engine a bit to make the cars more stable. (they had probably just made them heavier)

Also, before I forget - I remember showing you or at least talking about a video where someone had hacked Stage II in-game, and was able to remotely control each wheel individually. The reason for that is probably because in Stage II each individual wheel could be frozen separately by the ice spike powerup, so separate friction values for each wheel was probably necessary. -shrug.- but at the least this does prove that the cars do not have 'fake' wheels in entirety. There is some level of simulation to them o_o

It is probably splines. Would the game engine actually support the method of simulating driving via splines? (it seems even today this method is still used ... I have a feeling Blur uses splines)
At the least it would be a good idea to try it, unless LUA can simulate that closely enough. :]

End of thoughts.

edit

My bad. The car names reference spiders as well. DERP.
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#5
So... managed to create a new sub-subforum, and moved this thread!Big Grin

Frillis Wrote:In the versions I was poking around a year or so ago, it looked like a proprietary compression method was used- but most likely it'll be tied to whatever game-engine was used - rather than being an in-house design.
*drools by the thought of being able to extract the original 3D+textures*

I'm actually not sure they used a 3rd party engine... For instance RC1 used the "reaper" codec for videos: that seemed to be a in-house development ("Reaper '95 Version 1.30, © Paul Hughes" - did he work on psygnosis/atd?). And besides, the engine does seem rather lightweight.Wink

I wish we had any of the original developers on the forum, this would be two excellent questions (engine and img format)! Well, maybe they'll find this site eventually?

It should contain BMP files, though. Judging from strings in rc1:
Code:
ICE.BMP
TW8.BMP
TW7.BMP
TW6.BMP
TW5.BMP
TW4.BMP
TW3.BMP
TW2.BMP
TW1.BMP

Some other stuff, like:
FONT.BMP
conrecdi.dat
HIGH__LEV8_BL6
HIGH__LEV8_BTP
credits.fmv (this should be the one outside IMG)
(many others)



Mac Wrote:(oh, and Slinger, I know I need to respond to your emails and I'll do so eventually, but there's one point you brought up that I clearly remember being surprised by - both your point, and that I remember something that could debunk it xDD)
Don't worry. In fact, don't feel like you have to reply to the emails with email (if you don't want to). Just post on the forum if you remember something.Thumbs Up

Quote:I can't remember which cheats do what (I know there are working mid-gravity/low-gravity/normal-gravity cheats. I'll probably have to check those later. HOWEVER, I did just check the proceduraltextures cheat and I don't specifically notice anything different in-game, although I should probably try checking with and without it enabled to see if there is a particular difference in graphics.
I think all of them are around on the 'net. Except for procedural... I only notice the freeze/unfreeze of the background animations so it might be some debug thing they left? Or maybe not?

Quote:cars' development names. Most of them seem named after or reference snakes.
Quote:The car names reference spiders as well
I really wish they'd left the old "drivers" in, especially Yuri.Undecided

.... I wonder what names the original car would've had? ....Idea

Quote:I think we should use these 'codenames' in ReCaged. At least the name 'Venom' is there.
From now on all new Nemesis cars will be named from the Stage2 codenames! Hmm... "Diamondback"... I was going to call the next car "Piranha", but it might just have changed... Smile


Quote:2) You said in an email something regarding game physics and things not being realistically simulated. Specifically, you mentioned the car displays no roll when accelerating. Well, I do hope that I'm right and that they didn't actually just deliberately simulate the simulation of this to hide it, but in Stage II whilst attempting to get some sorts of the Vostok Reaper for dimension/layout purposes, I discovered that the car's body does shift its center of mass when it accelerates or brakes. You just don't notice it under normal gameplay but I had unintentionally got the camera panned into 'follow' mode (i.e. crashed) so I ended up driving perpendicular (sideways) to the camera from a standstill... the car exhibited roll. (nose lifted up, tail lifted down).

I'd noticed anyway that the cars lean when they turn. I do know however that this is present only in Stage II, but we all know they had modified the game engine a bit to make the cars more stable. (they had probably just made them heavier)

Also, before I forget - I remember showing you or at least talking about a video where someone had hacked Stage II in-game, and was able to remotely control each wheel individually. The reason for that is probably because in Stage II each individual wheel could be frozen separately by the ice spike powerup, so separate friction values for each wheel was probably necessary. -shrug.- but at the least this does prove that the cars do not have 'fake' wheels in entirety. There is some level of simulation to them o_o

It is probably splines. Would the game engine actually support the method of simulating driving via splines? (it seems even today this method is still used ... I have a feeling Blur uses splines)
At the least it would be a good idea to try it, unless LUA can simulate that closely enough. :]
This well deserves a new thread of its own. Feel free to create it! (I need to stop writing now)

What I will say is: the tilting and leaning is probably just a visual effect added to the rendering.

BUT: I remember in rc1 (in that island track with the jump just before the finish line) if one bumped unfortunate and got the front up in air and then kept accelerate the car would actually keep its front up for some distance (turning the steering ineffective).

And I think I found that video on youtube. Haven't got time to look, but you can probably find it... I also agree that the cars got right/left throttle!

I'm not sure what "simulating driving via splines" means, but if it's ray-casted (projected, which I call "faked"), then yes, no problem (there's some thread by Frillis where I replied about this somewhere) - just project (using ODE) a ray along the wheel axis and apply forces and render wheels accordingly (as you guessed: it will be implemented through lua scripting. but lua itself got no physics or anything other than being a language; it's going to be through the existing ode functions, exposed to lua through the "recaged library").



You might be surprised I actually agree on the right/left throttle (known as "tank steering/driving"), mention the part in rc1 and even consider adding raycasted/projected/ wheels to recaged cars? The thing is, I don't disagree with any of this. But I also don't believe it disproves my statement.

Why?

Because I haven't actually explained what I mean properly. I really wish I'd have more time now that I write this, but there will be other days (I might post it in the thread about splines instead).

Bottom line: with the term "faked wheels" I mean "projected"/"raycasted". But this is not all I mean when I say it:
* recaged simulated the engine by applying torque (from a simulated engine, through a simulated gearbox, through simulated differentials) to the wheels (which got actual bodies with mass and rotation inertia)
* rollcage[1,2] simulate the engine by applying forces (or just acceleration) directly to the car body (perhaps even offset it or apply some torque to give the front-in-air-handling I mentioned in rc1)
* recaged needs "real" wheels to simulate its engine properly (and apply the forces/torques properly)
* rollcage doesn't need this, so it only got "faked" wheels (raycasted, projected)
* remove the engine (not game engine) from the car in recaged, and the wheels doesn't matter: they could be "real" or "faked", I don't mind. - "real" will probably be easier(!), but we could experiment with the same approach as in the old games
* add a real engine to a car in the old games, and the wheels DOES matter: they must be simulated as in recaged (with a real body with mass and everything)

That, plus the fact that the rollcage cars doesn't turn by turning their front wheels (that's just another effect).

So when I say "faked wheels", I really mean the way the force and torque is applied (which is a lot different from recaged, which doesn't apply force/torque to the car, but instead on its wheels, thus indirectly and through a "realer" simulation).

The fact that someone managed to get rc2 to expose the right/left throttles (plus the magic "face forward" button for beginners) only confirms this: this is a classic example of tank steering/driving, and this is mostly implemented through direct forces to the car body/center-of-mass....


No Moar Time™!
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#6
(2012-03-28, 06:50 PM)Slinger Wrote: *drools by the thought of being able to extract the original 3D+textures*

I'm actually not sure they used a 3rd party engine... For instance RC1 used the "reaper" codec for videos: that seemed to be a in-house development ("Reaper '95 Version 1.30, © Paul Hughes" - did he work on psygnosis/atd?). And besides, the engine does seem rather lightweight.Wink

Paul Hughes has a website, but doesn't list Rollcage among the games he's worked on. Perhaps he just licensed tools to other developers? Or maybe it's a different guy?

As with video - it doesn't usually make sense to implement your own compression algorithm - but it'd be worth it to license an obscure/proprietary archiver just to keep people out.

Probably the simplest way would be just to add a few breakpoints and go through the assembly. It'd be an interesting project, but someone experienced could probably figure it out in a few hours.


(2012-03-28, 06:50 PM)Slinger Wrote: I wish we had any of the original developers on the forum, this would be two excellent questions (engine and img format)! Well, maybe they'll find this site eventually?

The founders are listed here - and most seem to still be working in the industry. Shouldn't be too hard to say hello - I found a couple of linked-in profiles:

http://www.mobygames.com/company/attenti...il-limited

A few years ago I remember stumbling across a website for ex-ATD members to get back in contact - I can't find it now - but I'm guessing that linked-in/facebook solved that particular problem.
Reply
#7
Late reply, but this is just in regard to the 'steering in air' thing Slinger mentioned.

... The cars can't steer if the front wheels are off the ground. O_o; The number of times I have done wheelies on the jump on Daytona and the car has refused to turn ... lol.

I think that if the car is using projected wheels, then the raycasting simulates the wheels as a sphere. I can't really confirm this because I would need a fairly hacked version of the original game (in which I could pause simulation but not camera, and manually force the car into strange positions so I would be able to see how the visible wheel geometry intersects the ground and walls at different angles. The camera never physically gets close enough to any walls for you to be able to see if the wheel is physically right up against the wall (which would suggest a cylindrical shape) or if there is an invisible gap (which would suggest a spherical shape).

I still don't really understand how raycasting works except that it's easier to 'simulate' cars with it, so therefore I don't know how raycast wheels simulate things like handling characteristics. I suppose the only true way to know is if by some miracle another old dev shows up and gives us all the source code/notes/data for the cars, or if we somehow manage to break into it ourselves. I remember the one dev who wrote on the RCX forum saying the track geometry was defined through splines (again, I don't know how those work for creating track geometry) and that the cars had a lot of physical grip. Also I'm assuming that most recent games still use raycasting for racing (i.e. Blur, which I play A LOT OF).

All I know is that all possibilities (tank steering, 'normal' steering, etc, etc) are going to be needed to be accessible through the LUA when it's coded in. I've probably said this before a few times but the more options we have for testing, debugging, etc, the better, because it gives us more scope not only for ReCaged/RCX but also for the other games we might try to code (I plan initially on just doing RollCageX, but I also intend on making a Blur clone at some point).

To be honest I think part of the whole "you can individually control each wheel's throttle" thing is down to two things in the game: the "magic face-forward" button (which needs to control each wheels' throttle individually to get the car to spin round R/C-car style) but also we shouldn't forget that the game is more than aware of when a wheel is airborne, as the game stops applying (apparent) torque output to wheels that aren't in contact with the racecourse (I know this because of the aforementioned wheelies on Daytona, also plenty of times on Low Grav mode I have had the car on two wheels (on either side) and the wheels off-ground would stop rotating).


My main thought regarding the whole raycasting thing is more how it'll make the car react in terms of riding walls, upside-down, etc. The cars in Rollcage were usually very well-behaved when transitioning from ground to ceiling provided there wasn't any overly excessive force involved (such as the car being slammed into it like that tunnel shortcut on the second track). In ReCaged, the much more realistic simulation means the car is usually a twat when anything more than a small slope is involved.. =/
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#8
Interesting observations there! Did you ever play the 4-wheel steering/drive hack I made for one of the earlier builds of RCX? It was fun trying out different configurations.

I'm getting more and more excited about the LUA aspect - anyone could write a script to customise and fine-tune handling. Change which wheels get power depending on cornering, forces, inertia, etc. Let AI race each other with your different configurations to save time, etc.

Also - to help guide search traffic: "Rollcage", "Rollcage Stage II", "ATD", "Attention To Detail".
Reply
#9
And not to forget: each car/vehicle will be using its own script... So different cars can simulate wheels in different way, so it'll be easy to evaluate new ideas without having to change or remove the old.

@Mac: great observations. A theory about the torque: since the wheels probably only spun "visually" (in the simulation they were not spinning, just imitating it), and since the idea of raycasting wheels easily solves the whole problem of determining if the wheels touch the ground... I would guess they just had a variable ("rotation_velocity") for each wheel, and for each wheel just test if it as touching the ground; if so the wanted physics properties would be added through direct torque+forces (steering on front wheel, propulsion on rear), and just taking a simple rotation_velocity=car_velocity/wheel_radius to specify the (visual) rotation of the wheel (and in air, just decrease the speed of rotation until it reaches 0).

At least that's how I'm planing to do it when adding... ahem... "faked wheels"... :p


update: a few thoughts on the img file: if I were to try to pack a bunch of files together, I'd probably just concatenate them, and make a list containing a name string and pointer/index number to where the file would start (plus a size and/or stop pointer). I suspect the "idx" file has this purpose, while the "img" file is the files thrown together.

Of course the file(s) might be compressed and/or encrypted........ But I got inspired to look for that like saying "PLAY*****" you mentioned, Spont........ Look what's also in "ROLLCAGE.IMG":
Code:
00157D90   42 60 18 00  00 55 5F 42  41 C9 EF 52  52 4F 52 40  B`...U_BA..RROR@
00157DA0   F8 14 45 72  72 6F 72 20  53 70 61 77  6E 69 6E 67  ..Error Spawning
00157DB0   20 52 6F 6C  6C 50 04 28  4C 63 61 67  65 AA 4D 61   RollP.(Lcage.Ma
00157DC0   EE 20 4D 65  6E 75 F3 54  72 79 D0 FE  08 41 67 E5  . Menu.Try...Ag.
00157DD0   9E 84 80 00  B8 F6 17 AD  65 75 AC 6C  A8 73 20 64  ........eu.l.s d
00157DE0   65 F8 61 20  67 E9 6E 04  01 A0 4E E9  72 23 69 6F  e.a g.n...N.r#io
00157DF0   B0 64 79 6E  61 6D 69 71  75 65 E5 90  FC 0B 97 20  .dynamique.....
00157E00   04 61 44 40  70 72 A8 63  69 99 6C 63  EB 66 66 65  .aD@pr.ci.lc.ffe
00157E10   1B D6 7A 20  75 6E D4 80  08 71 F4 6E  6F 75 76 65  ..z un...q.nouve
00157E20   D1 F7 74 D7  39 EF 04 BE  30 FD 12 23  02 22 24 50  ..t.9...0..#."$P
00157E30   F3 17 46 65  68 C0 67 62  65 69 6D 34  BC 72 B6 20  ..Feh.gbeim4.r.
00157E40   76 39 10 0A  41 C6 C8 FB  0A 48 61 75  70 74 6D E7  v9..A....Hauptm.
00157E50   FC F3 57 69  65 9C 72 68  E1 24 15 22  F8 D7 53 69  ..Wie.rh.$."..Si
00157E60   8F F8 56 29  02 6E 67 38  F1 18 73 F5  14 71 04 99  ..V).ng8..s..q..
00157E70   D4 75 68 57  0C F8 C9 BA  61 7A 5B E9  76 8B 10 F3  .uhW....az[.v...
00157E80   69 50 F8 10  50 56 F8 ED  52 F6 BF 76  CA 46 FE 72  iP..PV..R..v.F.r
00157E90   65 60 EF 18  14 F2 77 88  DD 62 C2 F7  D5 BB F3 5F  e`....w..b....._
00157EA0   38 F5 11 FA  E8 FC 08 9E  65 F3 D3 F5  72 0F 1C 82  8.......e...r...
00157EB0   2E EE FC D8  ED 1E 52 45  50 4C 41 59  C0 ED 1A AC  ......REPLAY....
00157EC0   70 16 79 20  6F B2 53 C2  7F 86 C7 6B  92 20 5C FF  p.y o.S....k. \.
00157ED0   0E EE ED FE  18 EE 23 3C  F8 6C 0A F0  0C F8 49 67  ......#<.l....Ig
00157EE0   6E 59 F5 FB  DF 37 E1 59  ED 61 40 FF  0C E0 EE 22  nY...7.Y.a@...."

One observation is: if this is supposed to be encrypted of compressed... it's not a very well done job.Tongue But it might still be partially one or the other. For encryption perhaps just some simple xor/modulus maybe using an incrementing variable (this some blocks being completely unencrypted while others being garbage). But I doubt it's compressed, and I suspect the "garbage" to be raw data...

Another is: It seems part of the logic (like menus) is actually described in this file! O_O

and the "GT20" sounds a lot like "go to 20" to me... *trolling*

the "Rollcage.idx" on the other hand is so small and doesn't contain any plain text. It does seem to have a repeating pattern (more on this if it's interesting to anyone), so I'd still guess it's some kind of collection of indices into the IMG file... This also seems the case with the stage2 idx... And it also contains some pure text stuff (but this time I also see the broken words, like "JUMPGAT@***").

You Read it, you Can't Unread It! More to come in "Tales Of Interest..... 2"!


update: so I got around actually modify those files... Wink
I'm probably wrong in that the menu logic is in the IMG file (probably just translations), but I tried to replace some clear-text parts (like "play"->"test"), and it seems some parts were affected...
The good news: my game launcher window now has a button saying "Test" instead of "Play", and I have the text "Retest" on the screen when replaying a race. I also changed "Yuri" to ... well, "Test", obviously. But I then noticed I hadn't unlocked the car, and I really can't seem to find the code for unlocking that car... O_o And can't be bothered to replay all leagues just to test this.
The bad news: some menu entries I had changed didn't appear in the menu, but instead no text was displayed (just a 1x1 pixel entry in the menu instead - which could be selected).

I also tried with the IMG from stage2: seems to cause crashes (even though I just replaced text, nothing else - I hope, I just used some crap w32 hexeditor. I'm planing on a more serious attempt with hexedit on my real system). So rc1 discards some modified data, rc2 just crashes on some modified data.

I suspect there might be some attempt on checksumming parts of the content (but not other), but I might just have fscked up this time. Also, not all text from the game can be found, while others can (but not always complete - interestingly often the beginning of words are found, but missing some characters in the end)... So I'm fairly sure some parts are obfuscated while others aren't (or with less scrambling, perhaps some primitive compression?): again some incrementing variable looping around between each block. It's also possible some blocks are thrown around (like interleaved, or just changed place with some pattern) just to throw people of. That might either be really stupid or really ingenious.
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#10
Some more findings (to inspire more people to look):

My working hypothesis:
* idx: a list (each "line" possibly being fixed size) of media files by name (or id derived from name) and index+size/end
* img: uncompressed (but intentionally slightly obfuscated) concatenation of all media files

I had a theory about checksums, but I have managed to mess with the exe a bit by changing the order of tracks in the first league so I doubt there's any -at least fixed- checksums hardcoded into it (was going to try to mixing different files but then "I" screwed it all up, and reinstalling+patching couldn't bring it back. I wont go into details but I blame windows for _both_ - now I'm running it through wine on a second debian install, and everything just works so much better)

Also the text strings seem more tricky than I thought: that "Play" button label didn't change into "Test" (as I claimed above), but into "Pest". And this is despite I changed a string saying "Play" into "Test". So apparently the first/uppercase/something of some strings might be located elsewhere, which is weird...

Finally: the idx file contains a lot of zeroes.... _a lot_ or them. And the bytes seem to have reoccurring patterns (nonzero, nonzero, nonzero, zero, zero, nonzero, zero. something like that), which do change between the beginning and end of the file. I suspect the strings in the exe (all of which often share the same length to the other strings around) are matched to some part of each "line" here, possibly through some checksumming/compression - notice that all names are UPPER CASE and the only non-alphabetic letter is the underscore, "_" - I'm fairly sure this indicates that they limited the number of valid letters so it would be possible to pack them together into just a few bytes (which are then matched to the ones in the idx). As for the lines: I believe they are of fixed size... I might be wrong here, but there's something funny about those zeroes (I tried to change some of them into arbitrary numbers and everything kept working. I also search&replaced all of them which caused a familiar segfault. Either the zeroes are just arbitrary padding and I overwrote a real -non-padding- value in the second test, or they are not and I just was lucky in the first test).

And a list of file suffixes I suspect were used for the original media files:
* .BMP (textures, of course)
* .BTP (something custom? one set of 4 or these are combined into a track)
* .BLP (-"-)
* .BT6 (-"-)
* .BL6 (-"-)
* .BSP (used for one file: TESTLVL_BSP, could be a basic template used for all tracks)
Sound is missing here, but in the IMG file I found:

Code:
00268CE0   31 30 2F 32  39 2F 39 38  20 56 33 2E  31 20 20 20  10/29/98 V3.1
00268CF0   4D 61 67 69  63 3A 20 62  61 34 30 32  33 39 31 20  Magic: ba402391
00268D00   50 43 20 53  6F 75 6E 64  20 45 66 66  65 63 74 20  PC Sound Effect
00268D10   46 69 6C 65  20 20 20 20  20 20 20 20  20 20 20 1A  File           .
00268D20   3F 00 00 00  00 00 00 00  EA 6C 00 00  00 00 00 00  ?........l......
00268D30   22 56 00 00  00 00 00 00  10 01 01 00  FF FF 53 46  "V............SF
00268D40   58 5F 45 4E  47 49 4E 45  31 00 00 00  00 00 00 00  X_ENGINE1.......
00268D50   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00268D60   00 00 00 00  EA 6C 00 00  92 7E 00 00  00 00 00 00  .....l...~......
00268D70   40 1F 00 00  00 00 00 00  10 01 01 00  FF FF 53 46  @.............SF
00268D80   58 5F 54 55  52 42 4F 00  00 00 00 00  00 00 00 00  X_TURBO.........
00268D90   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00268DA0   00 00 00 00  7C EB 00 00  EA 50 00 00  00 00 00 00  ....|....P......
00268DB0   22 56 00 00  00 00 00 00  10 01 00 00  FF FF 53 46  "V............SF
00268DC0   58 5F 53 4B  49 44 5F 54  41 52 4D 41  43 49 4E 49  X_SKID_TARMACINI
00268DD0   54 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  T...............
00268DE0   00 00 00 00  66 3C 01 00  C8 1B 00 00  00 00 00 00  ....f<..........
00268DF0   22 56 00 00  00 00 00 00  10 01 01 00  FF FF 53 46  "V............SF
00268E00   58 5F 53 4B  49 44 5F 54  41 52 4D 41  43 00 00 00  X_SKID_TARMAC...
00268E10   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00268E20   00 00 00 00  2E 58 01 00  FE 24 00 00  00 00 00 00  .....X...$......
00268E30   11 2B 00 00  00 00 00 00  10 01 00 00  FF FF 53 46  .+............SF
Is it possible there's some audio codec loaded from the img file?! Probably not, so it's interesting they seem to have stored the audio in a package which also contained some metadata (time of creation, "magic" id, description)... And for some reason this (fairly long list which continues a bit) doesn't seem obfuscated at all... O_o

Also: I'm a complete noob here, I'm just driven by my interest...
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#11
Let's crack this.

BEWARE! SPECULATION!

I'm going to have a poke around today to see what else I can find. Any compressed data in the IMG file should be a bit-stream, so only about 1/8th of the text would be 8-bit aligned.

The "Play" -> "Test" == "Pest" find is really interesting. It suggests the "lay" string was supposed to go into the compression buffer, but your edit meant that "est" went into the buffer instead. So you didn't change the menu entry directly, but another instance of the word "Play", and the menu entry in the IMG file would then just be "P" + index into the compression buffer. The next step would be to locate that "P" - by comparing the bits after "lay" and the bits after "P", you could probably deduce the method used to store+retrieve data from the compression buffer.

Also, the find of the uncompressed sound file is significant -- I had assumed that the entire IMG file was compressed in one blob.. but if it's an archive containing multiple files - some compressed, some not, then we should be able to separate it into individual files. Once we can compare two compressed files side-by-side, then we could squeeze out more details by examining the headers.
Reply
#12
Working from Rollcage Stage II demo -- so details will differ, but findings (SPECULATION!) should remain valid...

ROLLCAGE.IDX

Code:
00000000  00 00 00 00 69 1e 00 00  8c 69 00 00 03 00 00 00  |....i....i......|
00000010  69 1e 00 00 e7 1d 00 00  98 69 00 00 03 00 00 00  |i........i......|
00000020  50 3c 00 00 2f 1f 00 00  d0 6a 00 00 03 00 00 00  |P<../....j......|
00000030  7f 5b 00 00 9d 1e 00 00  2c 61 00 00 04 00 00 00  |.[......,a......|
00000040  1c 7a 00 00 ae 1e 00 00  2c 61 00 00 04 00 00 00  |.z......,a......|
....

This looks to be a 16 byte entry for each file. It looks too easy. First four bytes are the locations, next four bytes are the size. Next 8 bytes seem to be meta data of some sort. Ignoring those for now - let's extract the data.

save this as extractIMG.py, in the same directory as ROLLCAGE.IDX/ROLLCAGE.IMG

Code:
import sys
from struct import *

with open("ROLLCAGE.IDX", "rb") as f:
  total = 0
  
  offset = unpack('<L', f.read(4))[0]
  
  while offset != "":
    size = unpack('<L', f.read(4))[0]
    total = total + size
    
    print offset, " ", size, " ", total
    
    # who knows?
    f.read(8)
    
    offset = unpack('<L', f.read(4))[0]

Then this is somewhat clunky, but it's a one-time process so meh :-)

Code:
$ mkdir -p img; python extractIMG.py | awk 'BEGIN {i=0} {print "head -c " $3 " ROLLCAGE.IMG | tail -c " $2 " > img/" i; i++}' > f
$ . f


Let's see what we've got...

Code:
$ hexdump  -C img/0 |head
00000000  47 54 32 30 8c 69 00 00  03 00 00 00 00 00 00 00  |GT20.i..........|
00000010  00 00 00 00 50 49 4e 50  00 a0 10 00 10 53 90 65  |....PINP.....S.e|
00000020  55 00 7c 16 08 00 08 29  00 29 4a 00 4a 73 00 73  |U.|....).)J.Js.s|
00000030  94 00 94 bd 80 80 10 42  00 bd de 00 de ff 00 fe  |.......B........|
00000040  18 00 00 39 fd 5a fd 7b  fd 9c fd 44 44 08 21 e7  |...9.Z.{...DD.!.|
00000050  e9 fd e9 21 fb 42 fd 63  fd 1c 82 08 01 84 48 ff  |...!.B.c......H.|
00000060  0b ff 10 ac 31 31 d0 cf  84 e6 ad ad 00 d6 22 0a  |....11........".|
00000070  10 02 d6 ea ff fc f7 de  de c6 bd b5 94 ff 73 ff  |..............s.|
00000080  4a 52 4a 40 08 08 00 31  42 39 21 31 29 a2 d6 e3  |JRJ@...1B9!1)...|

Code:
$ hexdump  -C img/1 |head
00000000  47 54 32 30 98 69 00 00  03 00 00 00 00 00 00 00  |GT20.i..........|
00000010  00 00 00 00 50 49 4e 50  00 a0 10 00 10 53 90 65  |....PINP.....S.e|
00000020  56 00 88 16 08 00 08 29  00 29 4a 00 4a 73 00 73  |V......).)J.Js.s|
00000030  94 00 94 bd 80 80 10 42  00 bd de 00 de ff 00 fe  |.......B........|
00000040  18 00 00 39 fd 5a fd 7b  fd 9c fd 44 44 08 21 e7  |...9.Z.{...DD.!.|
00000050  e9 fd e9 21 fb 42 fd 63  fd 1c 82 08 01 84 48 ff  |...!.B.c......H.|
00000060  0b ff 10 ac 31 31 d0 cf  84 e6 ad ad 00 d6 22 0a  |....11........".|
00000070  10 02 d6 ea ff fc f7 de  de c6 bd b5 94 ff 73 ff  |..............s.|
00000080  4a 52 4a 40 08 08 00 31  42 39 21 31 29 a2 d6 e3  |JRJ@...1B9!1)...|

Sweet! Two similar (but not identical) headers..
Reply
#13
Minor update to make hex dumps of all the files:

Code:
$ cd img
$ mkdir -p hex; ls -1 [0-9]* | awk '{print "hexdump -C " $1 " > hex/" $1}' > f
$ . f

Also, that PC sound file format (file 289 in my version) is just 40 bytes fixed length name, 4 bytes offset + 4 bytes size. Seems to embed wave files - should be simple to extract + test, but I haven't tried.
Reply
#14
I just found this:

http://wiki.xentax.com/index.php/Rollcage_2_IMG

DERP
Reply
#15
Wait ... what? Seriously?

Someone already figured it out?


... so does that mean we can actually rip the game models, maps and textures from it? (to be honest for the sake of figuring out dimensions and stuff we really do need to be able to get hold of the individual game files and convert them into .obj format to run in rcx...)


edit

In case you have any better luck than me; that website suggests a program to download and use that already has support. Said program doesn't work because the site it needs to download files on is down.

Though since it explains on that site how to decode the .IDX and .IMG file then I suppose it'd be possible to write a script to decode it anyway... something out of my knowledge though. I'm just hoping the files it dumps are easy to edit and not some other weird proprietary format.


Also we need to figure out if the compression format is the same for both Rollcage games. I'd rather have a track like Daytona to test stuff on.
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#16
Oh dear lord... Spont, you are a god!!! Thumbs Up

As for the xentax wiki entry... Well, we've lost some of the fun now, but ultimately it'll help progress the goal... It does make me wonder: who found out all this? The history page reveals just an ip - is it possible someone from atd decided to go Santa here (I mean, that thing got compression info as well)?

Too bad I have little time to work on this atm, but the next step would be to write a program to both extract and decompress/unpack the files (or just unpack what you extracted). Two (open) questions: could the "Additional Information" mentioned on the wiki be the name (matching the strings in the exe), and is this format the same for the original game?

Now assuming the models are not compressed any further this should give the raw BMP files (easy to test for with a simple file/identify loop for all extracted) and 3D models... WHich are probably not easy to automatically detect, but since they probably went for something simple (for both dx3d and ps1) one could look for <number of cars> files of similar size (alignet together) and try to just find out if it use indices, if it's interleaved, etc... Big Grin

... I can't believe this is actually happening. O_O
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#17
I'm guessing from the experience I've had with cracking GTA4 that the organisation of the data within the ROLLCAGE.IMG file will be the same.

Basically - it will just be a list of files, and shouldn't have any sub-directories. So yes, we should end up with a bunch of textures (BMP I assume), audio (engine sounds, collision sounds, ground sounds etc) and 3D models (cars, weapons and maps).

I could be wrong but this is an assumption based on experience. Also bear in mind that like I said on that page there's a link for a program that seems able to unpack the IMG file but it doesn't work because the site is down due to bandwidth issues.

Though it might work for you, I dunno.
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#18
Bump.

I got that program working; however ... I'm left with a little bit of a dilemma.

As I will demonstrate:

[Image: jack20.png]

As far as I can tell that's the actual contents of the ROLLCAGE.IMG. Either this program is imperfect or the files were never actually packed with any file type specified (there are 290 files. half of them are somewhere between 8 and 20 kilobytes in size (are 16x16 bitmap textures able to fit in that sort of data size? I can't remember) whereas most of the other half are all 200-300 kilobyte files. There's also one big 2 megabyte file at the end.

I can't read from the XentaxWiki as to whether the Rollcage.IDX file is supposed to tell us what the files are supposed to be for, so provided this program read the IMG properly then at the least we have the contents... however useful that is. If there's some way to identify each individual model then that will be really useful.

Also, as far as I can tell there was no compression involved so it was just a standard sort of file cabinet/locker/fuck you, you're not ripping our game data :-) thing, on behalf of Psygnosis/ATD. xD

Well played.

If you guys want the (I'm presuming to be) extracted files, I'll winRAR them and upload them for you to look at. If you figure out a better method of understanding the data (especially what the file formats involved are because NONE of these files have file types specified and that isn't going to get us anywhere) then please tell me because I really want to know what's what in all this crap :/


edit

The 2MB file is actually the only one that seems to have legible text in it ...

"01/04/00 16:20:34 v4.11 000003D6 PC Sound Effect File"

I just ripped it in Audacity. It seems that every single sound effect is actually in there, though it sounds a little bit distorted so I reckon the game played the individual pieces a little slower in-game..
Triple bump.

There seems to be a recurring string in the larger files, alternating between "GFXM" and "BTP .... <random garbage> ... VRAM Bitmap" Also the majority of the first 80 files (what I'm assuming to be the graphics textures begin at file 81) begin with the string 'PINP'. The last sixty or so files all have the string "BM6" at the start

... There is also this recurring theme of there being a 'GT20' at the end of each file ... are ATD trolling us? Confused

If anybody has any idea how to open something that could potentially be a 'btp' file then please say. well, to be honest if anybody can make more sense of all this stuff than me, then please say.
http://www.animechatforums.com/mac/RCX/rollcage.rar

Uploaded. Enjoy.
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#19
Those files seem to be the uncompressed versions of the ones Spont managed to extract (without any tools, just knowledge and python scripting!).

update: Upon closer inspection: those are not decompressed versions of the files Spont extracted: They are incorrectly unpacked files.

The files should have a header starting with "GT20" (confirmed by both Spont and that wiki). Furthermore, they are not decompressed (as they still got traces of the header). Which explains why they are unnamed (and, together with the fact that they are faulty, explains why they aren't recognized).

I have a theory that (some or all of) those files got a name as a variable-length string in the fifth field ("Additional Information"), so if one of us write a tool to decompress the blocks ourselves, it should be possible to name the files based on this string. But anyway, you really don't need any file suffix to determine the file type! Just use "file" (a program you will have installed by default in your gnu/linux system):
update: again, ignore this, since the files are borked.
0) boot into gnu/linux
1) mount the windows partition (you probably know how to do this already with some graphic tool)
2) open a terminal and cd into the dir where you extracted the files
3) run something like "file *" (the wildcard will expand into all files, and "file" will check all of them)

You already got the audio figured out (some distortion could also be from the headers being embedded), as for the rest I'd say we will find at least (copy&paste from earlier):
* .BMP (textures, of course)
* .BTP (something custom? one set of 4 or these are combined into a track)
* .BLP (-"-)
* .BT6 (-"-)
* .BL6 (-"-)
* .BSP


btw: One thing we MUST do at some point is extract the img from the P4 version or rc1 (you know, the one with the higher-def 3d models)! Wink

update: btw2: are you able to use some other archive? I'm able to extract this using the non-free "unrar" program, but I'd prefer something like .7z (or even better: .tgz/.tar.gz)... Tongue



update: just ignore below, since the files turned out to be faulty.
update2: ok a quick check with "file" and ("identify" not posted here) doesn't reveal so much useful:
Code:
File 000001: data
File 000002: data
File 000003: data
File 000004: data
File 000005: data
File 000006: data
File 000007: data
File 000008: data
File 000009: data
File 000010: data
File 000011: data
File 000012: data
File 000013: data
File 000014: data
File 000015: data
File 000016: data
File 000017: data
File 000018: data
File 000019: data
File 000020: data
File 000021: data
File 000022: data
File 000023: data
File 000024: data
File 000025: data
File 000026: data
File 000027: data
File 000028: data
File 000029: data
File 000030: data
File 000031: data
File 000032: data
File 000033: data
File 000034: data
File 000035: data
File 000036: data
File 000037: data
File 000038: data
File 000039: data
File 000040: data
File 000041: data
File 000042: data
File 000043: data
File 000044: data
File 000045: data
File 000046: data
File 000047: data
File 000048: data
File 000049: data
File 000050: data
File 000051: data
File 000052: data
File 000053: data
File 000054: data
File 000055: data
File 000056: data
File 000057: data
File 000058: data
File 000059: data
File 000060: data
File 000061: data
File 000062: data
File 000063: data
File 000064: data
File 000065: data
File 000066: data
File 000067: data
File 000068: data
File 000069: data
File 000070: data
File 000071: data
File 000072: data
File 000073: data
File 000074: data
File 000075: data
File 000076: data
File 000077: data
File 000078: data
File 000079: data
File 000080: data
File 000081: data
File 000082: data
File 000083: data
File 000084: data
File 000085: data
File 000086: data
File 000087: data
File 000088: data
File 000089: data
File 000090: data
File 000091: data
File 000092: data
File 000093: data
File 000094: data
File 000095: data
File 000096: data
File 000097: data
File 000098: data
File 000099: data
File 000100: data
File 000101: data
File 000102: data
File 000103: data
File 000104: data
File 000105: data
File 000106: data
File 000107: data
File 000108: data
File 000109: data
File 000110: data
File 000111: data
File 000112: data
File 000113: data
File 000114: data
File 000115: data
File 000116: data
File 000117: data
File 000118: data
File 000119: data
File 000120: data
File 000121: data
File 000122: data
File 000123: data
File 000124: data
File 000125: data
File 000126: data
File 000127: data
File 000128: data
File 000129: data
File 000130: data
File 000131: data
File 000132: data
File 000133: data
File 000134: data
File 000135: data
File 000136: data
File 000137: data
File 000138: data
File 000139: data
File 000140: data
File 000141: data
File 000142: data
File 000143: data
File 000144: data
File 000145: data
File 000146: data
File 000147: data
File 000148: data
File 000149: data
File 000150: data
File 000151: data
File 000152: data
File 000153: data
File 000154: data
File 000155: data
File 000156: data
File 000157: data
File 000158: data
File 000159: data
File 000160: data
File 000161: data
File 000162: data
File 000163: data
File 000164: data
File 000165: data
File 000166: data
File 000167: data
File 000168: data
File 000169: data
File 000170: data
File 000171: data
File 000172: data
File 000173: data
File 000174: data
File 000175: data
File 000176: data
File 000177: data
File 000178: data
File 000179: data
File 000180: data
File 000181: data
File 000182: data
File 000183: data
File 000184: data
File 000185: data
File 000186: data
File 000187: data
File 000188: data
File 000189: data
File 000190: data
File 000191: data
File 000192: data
File 000193: data
File 000194: data
File 000195: data
File 000196: data
File 000197: data
File 000198: data
File 000199: data
File 000200: data
File 000201: data
File 000202: data
File 000203: data
File 000204: data
File 000205: data
File 000206: data
File 000207: data
File 000208: data
File 000209: data
File 000210: data
File 000211: data
File 000212: data
File 000213: data
File 000214: Alpha u-code object
File 000215: data
File 000216: data
File 000217: data
File 000218: data
File 000219: data
File 000220: data
File 000221: data
File 000222: data
File 000223: data
File 000224: 8086 relocatable (Microsoft)
File 000225: big endian ispell 3.0 hash file, 8-bit, no capitalization, 26 flags
File 000226: i386 COFF object
File 000227: data
File 000228: data
File 000229: data
File 000230: data
File 000231: data
File 000232: data
File 000233: data
File 000234: data
File 000235: data
File 000236: data
File 000237: data
File 000238: data
File 000239: data
File 000240: data
File 000241: data
File 000242: data
File 000243: data
File 000244: data
File 000245: data
File 000246: data
File 000247: data
File 000248: data
File 000249: data
File 000250: data
File 000251: data
File 000252: data
File 000253: data
File 000254: data
File 000255: data
File 000256: data
File 000257: data
File 000258: data
File 000259: data
File 000260: data
File 000261: data
File 000262: data
File 000263: data
File 000264: data
File 000265: data
File 000266: data
File 000267: data
File 000268: data
File 000269: data
File 000270: data
File 000271: data
File 000272: data
File 000273: data
File 000274: data
File 000275: data
File 000276: data
File 000277: data
File 000278: data
File 000279: data
File 000280: data
File 000281: data
File 000282: data
File 000283: data
File 000284: data
File 000285: data
File 000286: data
File 000287: data
File 000288: data
File 000289: data
File 000290: data
Just a few false-matches.
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#20
I'll have to remember to put it into .7z format next time; I did this on Windows so I didn't really stop to figure out how this would all pan out on Ubuntu.

Also like I said ... there seems to be no compression involved in the IMG file itself (they were all just stored ... well, the data anyway. file formats and that are bleh'd). I don't have any knowledge of scripting so I fucked about with getting this 'game extractor' tool to work (listed on the xentaxwiki) and that's what I got.

At some point I'll try that "file" thing in Ubuntu (maybe later today) although I'm not anticipating too much. Also I was planning to run this on Rollcage 1 but I haven't even got it installed :l so I'll have to find where I put the downloaded ISO for it and grab the IMG file from it. There's no data on that wiki about the original Rollcage IMG but the format is probably the same so we'll see what we get out of it whenever one of us gets round to decompiling all these unnamed files.
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)