67b9efe1a7e6d
Forgotten Password
Sign up

Post Reply

Your name:
Subject:
Message Icon:
Verification:
This box must be left blank:

An evil mega-corporation with 3 branches:

Shortcuts: Alt+s to submit/post; Alt+p to preview


Topic Summary

Posted by: sarge945
« on: 13. February 2025, 12:47:47 »

Quote by ZylonBane:
What's not apparent about "Testing a level directly is faster than replaying the entire campaign from the beginning"? That seems, like, super duper apparent.

In his defense, setting up a level in order to test it that way can take a while and seem intimidating, especially to someone unfamiliar with the editor, so it makes sense for people to want to fallback on what's comfortable.

But with time, doing things this way will massively pay off and end up being significantly quicker and easier.
Posted by: ZylonBane
« on: 13. February 2025, 02:16:10 »

What's not apparent about "Testing a level directly is faster than replaying the entire campaign from the beginning"? That seems, like, super duper apparent.
Posted by: RocketMan
« on: 13. February 2025, 01:16:24 »

Ok I'm starting to understand better now... not precisely but well enough.  Part of the problem is that with what I know about how this game works (or more precisely what I don't know), it's not immediately apparent why something so natural to me should be so discouraged.  I don't really need to know the reason to obey the advice but not knowing the reasons makes me more than a little skeptical.  I certainly don't want corrupted levels.  I went through that bullshit with my very first level actually.  1 vertex was preventing the entire level from portalizing and I spent 10s of hours hunting it down.
Posted by: voodoo47
« on: 12. February 2025, 11:19:10 »

if you want to load a save in the editor, you fire up the editor, set game_mode_backup 0, toggle persistent player position, go ingame, hit escape, load the save from the menu, then alt+e to get back to the editor, and then F3 for player and jump there with F8, most likely.
Posted by: ZylonBane
« on: 12. February 2025, 06:34:37 »

Quote by RocketMan:
ZB I get what you're saying about resource caches and cheat codes but sounds clumsy and stapled-together to me.
You can call it whatever names you want, but that doesn't change the fact that it's an order of magnitude faster to hop directly into a level and grab some pre-placed gear than it is to start the game from scratch.

Starting the game from the beginning should be reserved for playtesting. What you're doing now is developing. Trying to smash developing and playtesting into the same activity will just make both tasks slower and less efficient.

Quote by sarge945:
Level transitioning in the editor is disabled by default for a reason - the editor simply cannot handle it.
DromEd can handle level transitioning perfectly well. It's possible to run through the entire game in the DromEd exe without a single glitch. What it specifically can't handle is maintaining meaningful data in editor mode when you do this. As long as the user understands this limitation, all is well. Sometimes it's very useful to be able to test level transitions in the editor.
Posted by: sarge945
« on: 12. February 2025, 04:57:22 »

SS2 is built on top of Thief, which was a game designed to load levels as completely separate maps with no interconnectivity whatsoever. ShockEd is based on DromEd, Thief's level editor.

As a result, changing levels in the editor via play mode is a bad idea and is 100% guaranteed to screw everything up. Do not load one level from another level. Level transitioning in the editor is disabled by default for a reason - the editor simply cannot handle it. The editor is designed to edit one level at a time, and switching between them in the "open map" dialog effectively discards the first one and loads the second one from scratch, which is the only reliable way to switch maps.

The way interconnectivity works in SS2 is via qvars. AFAIK that's the only way for one level to affect another level directly. Which means that, since the editor cannot handle loading more than 1 map independently, you need a way to set those qvars within your map (via editor-difficulty objects) so that you can test it. It's critically important that you think of your campaign as unconnected, independent levels that react to qvars to change things about themselves, with no knowledge of or way to interact with any other levels outside of setting and reading qvars.

While it's technically possible to mess around with saving and loading to move between maps in the editor, and while you might even manage to find something workable by doing so, the chances of running into issues are extremely high, and while adding editor-only objects is a hassle and is annoying, I guarantee you it will be far less annoying than having your entire map get corrupted after 100 hours of editing because of problems with the editor.

You have been strongly warned multiple times to not do what you're trying to do. It's obviously up to you whether or not you want to continue down that path, but when multiple people who have used the editor extensively all tell you in unison that doing something in a particular way is a bad idea, I recommend taking their advice because they probably know what they are talking about. I'll be the first one in line to call ZB an asshole but in this case he's also right.

Saving in level 3 so you can transition through to level 4 is an excellent way to test your map in the real game, but you can't edit that way. I know RoSoDude tested a lot of RSD by actually playing the maps in SS2.exe. But when it comes to using the editor, the only valid way to test your map is by entering game mode in the actual map you're testing and using editor objects to set the qvars you need to set, and there's no way at all to do cross-map editing.
Posted by: RocketMan
« on: 12. February 2025, 02:29:54 »

Quote by voodoo47:
to answer the question, type set game_mode_backup 0 in the editor command window and hit enter, go ingame, create the save (quick or regular), exit the editor (NEVER save your map in the editor after doing this) and you can load the save with the regular exe.

This explains saving from 'game mode' in the editor, and then apparently loading it in SS2 as if you were an end-user... but I don't get how to re-load it from inside the editor.  Obvious guess would be, enter 'game mode' hit escape, go to load, and load the saved game.  However since we're talking about a pseudo-game inside the editor I can't assume it acts the same way.  Is that how it works?

1. load level of interest in editor (say level 3)
2. ALT-G
3. ESC > SAVE
4. ALT-E
5. Exit editor without saving
6. Re-load ShockEd
7. Load level of interest in editor (level 4)
8. ALT-G
9. ESC > LOAD
10. Load save game

Like that?

Actually the best way I see this working is to save the game in the level prior to the one you're currently screwing with.  So a save game for level 3 would be good if you're working on level 4.  That way, whatever you change in level 4 doesn't get undone when you load the save game.  The save game merely offers an entry point into level 4 that saves you a ton of time getting to. 

ZB I get what you're saying about resource caches and cheat codes but sounds clumsy and stapled-together to me.  Trying to anticipate all the prerequisites for a level and making special secret provisions for them can never be as reliable as actually playing the game up to the point you're working on.  And if something doesn't work, then you just exposed a bug you need to fix, which is a good thing. 
Posted by: voodoo47
« on: 11. February 2025, 16:20:48 »

it's been ages, but I think the save was not quite working right without doing this. would have to check to be sure, but either way, I always do this if I need to work with saves. definitely necessary if you have a save that you want to load in the editor, then do some changes, and save again to create a save that the game exe can then load.
Posted by: ZylonBane
« on: 11. February 2025, 16:08:18 »

Quote by voodoo47:
type set game_mode_backup 0 in the editor command window and hit enter, go ingame, create the save (quick or regular), exit the editor
Why is setting the backup mode necessary? That doesn't have any effect until you exit game mode.
Posted by: voodoo47
« on: 11. February 2025, 10:57:44 »

if I were to build a fm, I would probably just take one of the vanilla unstripped levels and start modifying. whatever needs to be added, would check what IG did, then whether SCP modified it, and then just do that. ShockEd for Dummies can help too.

to answer the question, type set game_mode_backup 0 in the editor command window and hit enter, go ingame, create the save (quick or regular), exit the editor (NEVER save your map in the editor after doing this) and you can load the save with the regular exe.
Posted by: ZylonBane
« on: 11. February 2025, 06:17:11 »

Quote by RocketMan:
I want all the "stuff" that level 3 needs to work properly (from the other levels) to work
You've already been told that this is exactly what qvar-setting buttons are for. But you responded to that with "But what about the potted plants?" Which just ended up confusing everyone because why would you care about things that don't affect other levels?
AND I want to go back and forth to the previous levels and have all of them in a "used" condition, reflecting their already-activated condition. Otherwise my inventory is all fucked, I have no skills, my logs aren't up to date, whatever...
You can deal with that by ubermensching and summoning weapons or pre-placing them in the level, tagged as editor-only. You never noticed all those piles of supplies at the start of command1 and rick1 that are only visible in DromEd?

There's a reason Irrational designed most quests to be self-contained within a single deck. With the exception of the really big plot quests, you can start any deck in the game from scratch and complete all its quests.
Posted by: RocketMan
« on: 11. February 2025, 04:42:58 »

Quote by voodoo47:
are you aware there are rules to follow (and if not followed, pain will ensue)?

Yeah... been askin for those rules off and on for years.  The basic tutorials aren't cuttin it.  Please paste rules.

How is it even possible to 'edit' a level from inside game mode?  Of course I'm doing my editing in 'edit' mode.  Or I have no idea wtf you guys are talking about.

It seems perfectly natural not to treat every level as completely isolated and independent from each other.  Flick switch in level A, door opens in level B.  Go to level B and go through door.  Flick another switch.  A monster appears in level A.  Go back to level A and kick his ass and take his key.  Pretty old hat.  Level interdependencies are all throughout SS2.  Buuuttt... I have a feeling someone is going to "correct" me again for not understanding something.

Before everything gets out of hand... all I wanna do is save my game in ShockEd, no different than I would if I was just playing the game.  If I have constructed 3 out of 10 levels I want to load up level 3 and chip away at it and each time I go into game mode I want all the "stuff" that level 3 needs to work properly (from the other levels) to work AND I want to go back and forth to the previous levels and have all of them in a "used" condition, reflecting their already-activated condition.  Otherwise my inventory is all fucked, I have no skills, my logs aren't up to date, whatever...  Is this weird or something?
Posted by: voodoo47
« on: 10. February 2025, 17:36:22 »

maybe it's time to ask - are you building a (fan) mission? are you aware there are rules to follow (and if not followed, pain will ensue)?
Posted by: ZylonBane
« on: 10. February 2025, 17:15:53 »

Can't say it occurred to me that he's using game mode to edit missions. I really, really hope it's not true.
Posted by: sarge945
« on: 10. February 2025, 08:35:51 »

Quote by RocketMan:
But this button just saves quest data?  What if I want the placement of the potted plants to be just where I threw them?  Wouldn't I need a proper save to capture everything?

I would highly recommend using the editor tools to place things rather than doing it in game.

Quote by RocketMan:
Like when you're playing the vanilla game and you get to say engineering and you save the game, you have medsci1, medsci2 and engineering in the save folder with a file size that doesn't match the original so I'm assuming whatever you did in those levels before leaving them (killed some monsters, relocated some items, opened some doors, etc) is saved in some sort of state data in those mis files right (or maybe it just re-saves the mis file when you leave it)?  So that's what I want to do from the editor, so that when I warp into level 3 or whatever, and I decide to go back to level 2, everything is just as it was when I left it.  Otherwise, I would think that starting in level 3 and going back to a fresh level 2 might break a bunch of stuff that isn't necessarily related to quests.  I can't be more specific because I've been replaying the game from scratch every time so this hasn't been an issue.

Your best bet is to save the game (in the standard game, not the editor), then open the save in the editor, export the objects as dml, then reimport them into the actual map file.

But the question is why?
Posted by: ZylonBane
« on: 08. February 2025, 22:09:14 »

WHY? Why are you doing that? The normal way to use DromEd is to work on or test ONE map at a time. Not the entire campaign. When you're in map X, the state of map Y, or any other maps, should be completely irrelevant.

And if you do keep saves around for other maps, they would only be valid for the specific version of the map they were created with. Loading an old save on top of a revised map WILL screw things up.
Posted by: RocketMan
« on: 08. February 2025, 21:26:54 »

Like when you're playing the vanilla game and you get to say engineering and you save the game, you have medsci1, medsci2 and engineering in the save folder with a file size that doesn't match the original so I'm assuming whatever you did in those levels before leaving them (killed some monsters, relocated some items, opened some doors, etc) is saved in some sort of state data in those mis files right (or maybe it just re-saves the mis file when you leave it)?  So that's what I want to do from the editor, so that when I warp into level 3 or whatever, and I decide to go back to level 2, everything is just as it was when I left it.  Otherwise, I would think that starting in level 3 and going back to a fresh level 2 might break a bunch of stuff that isn't necessarily related to quests.  I can't be more specific because I've been replaying the game from scratch every time so this hasn't been an issue.
Posted by: ZylonBane
« on: 08. February 2025, 05:51:59 »

No, the button setup wouldn't save quest data, it would set quest data. That's why it uses the"QB Set" entity.

Are you talking about the positions of tossed items in the current map, or in some other map?
Posted by: RocketMan
« on: 08. February 2025, 02:09:33 »

But this button just saves quest data?  What if I want the placement of the potted plants to be just where I threw them?  Wouldn't I need a proper save to capture everything?
Posted by: ZylonBane
« on: 07. February 2025, 19:02:25 »

"Programming structures"? Do you mean data structures?
Quote by RocketMan:
if there's a way to save your game in the editor and load it up again, that would probably be ideal.
No, it would be awful. First, you'd have to maintain a collection of savegame folders with whatever quest states you wanted to test. Second, you'd have to manually tick Allow EndGame and delete the contents of the Current folder every time to allow level transitioning to work correctly. Third, when returning to editor mode the state would be a scrambled mess and you'd have to reload the mission you were working on, losing any unsaved work.

Just put a button in your level linked to one or more QB Set traps. Add Difficulty: Permit: 0 to the button. Takes like five minutes to set up. That's what Irrational did (see the command1 elevator).
Posted by: RocketMan
« on: 07. February 2025, 16:49:20 »

I don't have a solid grasp of exactly what programming structures would be adversely affected from starting a later level without completing the previous ones so if there's a way to save your game in the editor and load it up again, that would probably be ideal.  I don't mind trying to save the game if it doesn't break anything but the editor has been so temperamental with how I've been using it that I'm afraid to try new things unless I know you're supposed to do that.
Posted by: sarge945
« on: 07. February 2025, 03:42:10 »

Quote by RocketMan:
Well isn't that something.  Ok while we're on the topic, is there a way to save an editor game so if you want to debug something in a later level you don't need to go through the whole game to set up all the mission/plot states and stuff?

Can't you just use Save Game in game mode? (Ctrl-G)

I don't actually know because I have only loaded games using game mode, but surely saving would work too?

But, you might want to do what SCP does and have some extra switches/toggles/etc to trigger quest variables, set to "Editor" difficulty, so that they don't appear in a real game.
Posted by: RocketMan
« on: 07. February 2025, 02:39:17 »

Well isn't that something.  Ok while we're on the topic, is there a way to save an editor game so if you want to debug something in a later level you don't need to go through the whole game to set up all the mission/plot states and stuff?
Posted by: Nameless Voice
« on: 06. February 2025, 11:06:49 »

You always put a player factory on every level.  They do that in the original missions.

The ones in later levels just don't get used during the normal course of the game, because it uses the level transition systems and markers instead.  They are only for testing.
Posted by: sarge945
« on: 06. February 2025, 09:21:04 »

Welcome to yet another reason why singletons and the factory pattern are awful programming techniques.
Posted by: RocketMan
« on: 06. February 2025, 03:53:10 »

Then I would say it's a miracle that I've gotten anything to work at all.  But I thought since the finished game only needs it once on the first level, you're not supposed to put it in every level.  Needless to say I'll be putting it all my levels from now on before debugging anything else.
Posted by: ZylonBane
« on: 06. February 2025, 00:07:14 »

Shaking the player is actually done by PlayerScript. ShakeYourBooty just sends a message to the player telling it to shake. But unless there's a PlayerFactory link to tell the engine which archetype to use to spawn the player, the in-game player won't have PlayerScript, or any of the other properties set on The Player.

You've apparently been testing with a bare-bones "default" player with none of the necessary scripts and properties for any of the game systems to work correctly other than just walking around and clicking things.
Posted by: RocketMan
« on: 05. February 2025, 23:40:59 »

I did... must have removed it.  [shaking works now].  Good news is it doesn't seem to require a lot of height when dropping the player into the level, to trigger this effect, which is good.

Let me guess.  The playerfactory code initializes a bunch of stuff on the player object, including stuff like shake stim or scripts that would do the same?

When you have a multi-level game you only put the start marker in the first level right?  Because the set-up on the player persists between levels?  So then how do you properly design your subsequent levels without putting the marker on them and then having to go back through later and delete them all so you can play the game in its entirety properly?

I guess this pretty much ties in with a larger gap in my knowledge where I keep having to replay the whole game to check a change I made 3 levels later because I don't know how to make the editor think I'm just resuming a previous save game.  Whenever I warp in, everything's broken unless I play through the whole game from the beginning.
Posted by: ZylonBane
« on: 05. February 2025, 16:22:36 »

Hold up...

Do you not have a PlayerFactory marker in your level?
Posted by: voodoo47
« on: 05. February 2025, 15:28:29 »

it's a vanilla script.
Posted by: sarge945
« on: 05. February 2025, 15:27:08 »

just a really dumb question/observation.

Don't you need to actually load NVScript.osm as part of your map (or via DML) for it to actually work?
Posted by: ZylonBane
« on: 05. February 2025, 14:44:47 »

"in the base game"
Posted by: RocketMan
« on: 05. February 2025, 07:31:37 »

{ ShakeYourBooty; NvSpy; ; ; TRUE}

Putting the script on a door didn't do anything.  Does it have to be in my level or did you mean the vanilla game?
Posted by: ZylonBane
« on: 05. February 2025, 03:18:37 »

Select the Scripts entry on the marker, click the copy button, then paste it here.

Also try adding ShakeYourBooty to any door in the base game then walking through the door.
Posted by: RocketMan
« on: 05. February 2025, 03:05:45 »

By intensity you mean Shake Strength?  Rick2 didn't do that but I did anyway. I gave it 10.  NVSpy says BeginScript on Marker 149 from 0, Sim on Marker 149 from 0, ObjRoomTransit on Marker 149 from 0, TurnOn on Marker 149 from 118 ----> that's the one ----> EndScript on Marker 149 from 0 and Sim on Marker 149 from 0.
[Capture.PNG expired]
Posted by: sarge945
« on: 04. February 2025, 17:20:09 »

Why not post the map?
Posted by: ZylonBane
« on: 04. February 2025, 14:07:27 »

Did you give it an intensity?

Have you verified the marker is actually receiving the signal?
Posted by: RocketMan
« on: 04. February 2025, 06:30:41 »

Sorry, something's messed up here.  I see it works in medsci1 and in rick2 but it doesn't work when I do the exact same thing... I drop the player and let him run around a bit, then he crosses a tripwire which fires a signal to a marker with the script on it and nothing happens, every time. 
Posted by: ZylonBane
« on: 04. February 2025, 01:57:59 »

There isn't always an initial fall if the player spawn markers are positioned correctly. But yes, falling a a couple feet does seem to initialize things so the shake works. See for example the start of rick2.

SCP works by also shoving the player forward so they don't have to fall as far.
Posted by: RocketMan
« on: 04. February 2025, 01:02:26 »

So... you got it to work in SCP but if I recall, the player can just choose not to move after they're dumped in the level. I know their's always an initial fall of a few inches but is that's all that's needed to get the shaking to work?
Posted by: voodoo47
« on: 03. February 2025, 09:38:07 »

Quote by RocketMan:
2002?  I'm checking the vanilla unstripped medsci1 and I don't see a 2002
yeah, this is SCP, it's always SCP by default.
Posted by: RocketMan
« on: 03. February 2025, 08:52:13 »

Quote by ZylonBane:
Huh, I just noticed rick3 has a nonfunctional ShakeYourBooty script on button 111. The actual shaking is done by the script on marker 603.

You mean I found a thing?   yayyyyy....

I thought one of the trailers for the shock project showed a couple guys in a room that starts to shake... maybe my memory is faulty though, it often is.  I just thought I'd seen it done before without any particular movement going on prior.
Posted by: ZylonBane
« on: 03. February 2025, 06:34:29 »

Huh, I just noticed rick3 has a nonfunctional ShakeYourBooty script on button 111. The actual shaking is done by the script on marker 603.

Anyway, the script function that shakes the player (actually just makes the player "lean" in various random directions) doesn't work unless the player has fallen or walked a certain distance first. Probably something to do with fully initializing the player's movement model.
Posted by: RocketMan
« on: 03. February 2025, 03:36:59 »

I must have loaded up an SCP build then because the ground shook when the array hit.  In any case I found the button that launches you into the many and it has the script on it.  However when I reproduce that in a test level it doesn't work.  I mean I didn't include everything like the outbound switchlinks or the schema or objlook but I'm assuming you don't need any of that.  I'm assuming that pressing the button itself invokes its own scripts, which are basebutton, shakeyourbooty and it's set not to inherit so that's what I did.  Nothing.  I was going to say I want this to work on a tripwire rather than a button but I guess one thing at a time since I can't reproduce the behaviour yet.  I do have all my OSMs loaded btw and the test is in a room brush.  I put a level start marker in too.  Nothing.

Also when I jump into Rick3, the button ALSO doesn't shake anything.  Could this be because I'm doing everything in editor mode?
Posted by: ZylonBane
« on: 03. February 2025, 01:46:11 »

Vanilla SS2 doesn't shake the player when the dish impacts, surprisingly. It does shake the player when they launch into the Many. To find where a script is used in a mission, go to Object Hierarchy -> Export -> Export All. Search the generated file for the script name.
Posted by: RocketMan
« on: 03. February 2025, 01:08:47 »

2002?  I'm checking the vanilla unstripped medsci1 and I don't see a 2002.  At least Edit>Find doesn't return one.
Posted by: voodoo47
« on: 03. February 2025, 00:55:39 »

I would check medsci1 marker 2002 and.. just do that. all it needs is a TurnOn signal.
Posted by: RocketMan
« on: 03. February 2025, 00:35:04 »

Trying to do this "shake the screen" effect, which I've heard in the past has something to do with a script called ShakeYourBooty?  Of course I can't find documentation for it.  Then after 30 seconds of trying, ZylonBane descended from above in a booming voice and told me to do it how Irrational did it.  Luckily this time I knew where in the game that actually happened... because it happens in the first 30 seconds when the array blows up.

So I'm looking at 50 frickin red cubes in dromed, trying to figure out which one of em shakes the screen.  After a while of that fun, I concluded it must be a TweqTrap which is receiving a signal from somewhere, which has an EmitTweq on it and that emits a HE Explosion.  So I check HE Explosion in the hierarchy and it has a ShakeStim on it.  Ok.

So the first thing I do is copy-paste what Irrational did.  I make a TweqTrap, put the Emit Tweq on it with all the same parameters, and I send it a switchlink signal from a nearby tripwire.  All that did was produce a fireball directly in front of me when I crossed the tripwire but no shaking of the screen... I dunno, maybe some other ingredient is missing?  I've got the brush in a room and recompiled the level... can't really think what else I didn't do.

To be honest I'd rather not use an HE explosion if I don't have to.  That sounds like the wrong way to do it since I don't want a fireball or any noise, just the shaking.  I figure there must be a way to just enable the shakeyourbooty script?
Contact SMF 2.0.19 | SMF © 2016, Simple Machines | Terms and Policies
FEEP
67b9efe1aa7be