|
Post by Mystery on Nov 21, 2024 12:11:59 GMT -5
I'm currently fumbling my way through the GCS Menu documentation (the manual and the help pages in the software) and I was wondering about something. I'll just summarize what I've understood so far, stop me if I'm wrong. This is how far I've understood the menu: - We have Events 10-16 in the Dissect function to add additional stuff to the main menu and control it via the event scheduler. So far so good.
- Special Events are #0 (what happens before the menu gets displayed after starting) and #1 (player death) as well as #10 (esc in main menu). Alright.
- We write stuff in Universe Register #127 which gets read by the engine and the value inside is the event# that fires and corresponding event scheduler entry is run.
- Any value larger than 128 in UR#127 fires the event# but also ends the game. This is for having multiple endings I guess.
- Firing any other event lets us use the options in the event manager which are: fade/dissolve/slide in/out, show fli file, return to menu, play midi file, resume game, play wav, force dos exit
- The dissect tool has the following options built in: new game, save game, load game, toggle sound/music/joystick/mouse
Anything wrong or missing? I hope not. Now here are my two questions: - I could swear I've seen it in at least one GCS game, but I might completely misremember. Is there a way to have something like a second menu? A sub menu for "options" for example?
- Is is in any way possible to also access/fire the "new game, save game, load game" etc. "events" from anywhere else but the main menu and dissect tool? Like for example an event# that can be set during gameplay to start a new game or call the load menu without going into the main menu? Or a different method?
That's it from me for right now, thanks for having a look
|
|
chris
Junior Member
Posts: 58
|
Post by chris on Nov 21, 2024 13:59:13 GMT -5
So it's been 20 years since I've messed with GCS Menu, but I don't think there's a way to have a second menu. You can steal the pre-menu system from Santa3D and do some things with that, launch an exe to set some text files or something to be picked up later maybe but that's all I can think of. If you find any games with options I'd be interested to see, but they are probably for Pie in the Sky games or games made using GCSP. Maybe it's possible to steal those menu systems as well.
I don't believe there's a way to jump straight into save/load. Only way I can think to do it would be to roll your own save/load system with batch/qbasic/C etc, and use a PNOCOMP stub to catch it and reroute to that system, then return to the game. The way save/load works in GCS is very simple, it just copies some files from the .SAV directories to the DATA directories and vice versa. You could even have the game "quicksave" during cutscenes with some PNOCOMP stub hackery.
But yes register 127 will either kill you or interrupt the game. Kill you and fade to red if it's under 128, immediately stop and pull up a cutscene if over 128. If no cutscene defined, maybe it jumps straight to the menu and then you can resume by pressing Resume Game? Not sure.
|
|
|
Post by lgb3d on Nov 21, 2024 16:58:30 GMT -5
Yes 127 is special. Death sequence is easy. But things to avoid.
The values used by GCS menu that land on register 127 do not use those values to terminate the game from gameplay as it will interrupt or offset the events scheduled at the register through GCS menu. So yes use the early numbers for death sequences and then leave a void if you need more death sequences they start at numbers greater than those used by GCS menu..
Even if you died with a low value register 127 you can resume game. When game loads screen will fade to red and kick you back to GCS menu since the register value has already been called the cutscene will not play again. And GCS menu appears on screen after screen Fades red.
Let's say you have an animation that terminates the game with a value of 127, if it is set to loop back.. since an animation is calling register 127. If you press resume game that value at 127 is still true, so it will not kill the player a second time. So even if the player died via an animation killing him he can resume the game and continue playing at his exact location. And it might make the animation appear as a glitch where it could be attacking the player but not kill the player or send him back to GCS menu. So when scripting animations that would assign a value to register 127 keep that in mind.
Another way that trip with animation creating register 127 value works..
Higher positive values for 127 can be used for a happy ending or a cutscene if is a cutscene instead of return to menu you select return to game. So after cutscene plays player is returned to exactly location in game.
I don't want to give it all the way but using my own project as example I have TV monitors in the game player approaches monitor gives a positive cutscene, like the players watching a news broadcast. And then it returns to the game and the player is setting in front of the TV. Well the player cannot watch that TV again unless it calls a different value for register 127.
If there is a milestone like hey I entered a level and it calls register 127 and shows the player walking through the door, it's cool if it doesn't show that every time the player walks through that door. It only introduces the level showing the player walk through the door the first time that is cool.
But let's say it is a animation demonstrating something that the player is using or what not that you want the player to be able to use every time demonstrating a cutscene every time they approach or use said item. The animation script is going to at minimum need to use two different values for register 127, the first time it's register 127 value 130, then to animation skips to the next phase where it sets in a loop to check if player is close and if so set register 127 value 131. Then the animation Loops back to the start so the next time player approaches it's establishing a value that is not currently set so if the current value is 131, the next time he approaches it goes back to triggering 130.. That way whenever player approaches that item it will always demonstrate that cutscene, or a varied cutscene a little different but demonstrating that that item always works.
Let's say it is a surveillance system, and the player can watch the monitor to see what is happening. Okay there's a camera watching the warehouse in the bad guys are in the warehouse I want the player to be able to walk up to that TV screen and see that every time so I have to use two different values for register 127 to demonstrate that the bad guys are in the warehouse so that every time he checks that monitor there's always a value of 127 that is not currently active that can be triggered to demonstrate the cutscene. Now let's say the player went through the warehouse and killed all the bad guys and he goes back to the place in the game where that monitor existed that animation is set to Branch to a specific frame if said condition is existing. Now when he looks at the monitor it goes to register 127 value 132, okay he sees the warehouse but there's no enemies, and the animation skips next and sets in a loop where if players close it triggers 127 value 133. In that way a cutscene will always play when the player ask it to.
And my game I have various objects that give cutscenes and return to game, some that only need to be shown once but some such as TV monitors or whatnot that I want the player always to be able to access. As well various animated objects that can kill the player, and I don't want the player to be able to just press resume game and enter the game without the object killing him. So the way that we script animations that call register 127 we have to keep what I said here in mind.
Moral of the story animation that calls register 127 and a set value, if player enters the game and that value is still existing it will not leave the game a second time you have to change the value to terminate the game with a positive or negative outcome. And yes with some cutscene such as demonstrating the player walking into a building yeah you don't want that to be redundant so it's okay if it only calls register 127 and establishes a single value and as long as register 127's value does not change that execution of 127 will not demonstrate to player walking into the building again.
Let's say player walks into building demonstrates cutscene in building he sees TV monitor separate value to 127 okay he exits the building next time he reenters the building since the value of 127 has changed it will demonstrate the cutscene of him walking into the building again. So if that is undesirable you have to script it in a way that animation or platform that established that register value is no longer accessible. Example platform enable only if value equal,
In my game I make heavy use of register 127.. so the way I script things is really important to avoid redundancy in some situations or enable it where it is desirable..
|
|
|
Post by Mystery on Nov 22, 2024 3:00:27 GMT -5
Alright, looks like there really is no easy way to get access to the save screen without going into the menu first. Thanks for the feedback guys. There were still a couple of interesting ideas in here, so I think it was worth exploring
|
|