SS2 Randomizer, Is it even possible?

[6741d6236f23bJossiRossi]

I had this working a bit ago, but now can't get back to the functioning version.
I am creating a new Cryo room card, and it spawns, and even has gravity, but falls right through the floor. For a while it would properly collide with the floor and stop. Perhaps there is a Phys setting that's not being inherited from the archetype maybe? I know there's other Phys attributes like PhysState I'd played with some while poking at it. I feel like I am missing something simple.

Code: [Select]

Create -1452 "NewCryoCard"

+ObjProp "NewCryoCard" "ObjName" = "Cryo_Card"
+ObjProp "NewCryoCard" "ObjShort" = "Cryo_Card"
-ObjProp "NewCryoCard" "PhysType"
+ObjProp "NewCryoCard" "Position"
{
"Location" 109.15, 47.50, -3.68
"Heading" 0
}

+ObjProp "NewCryoCard" "PhysType"
{
"Type" "OBB"
"# Submodels" 6
"Remove on Sleep" FALSE
"Special" FALSE
}
I know I can usually tuck a lot of those functions into the Create, but isolated them out while trouble shooting.

[6741d6236f428ZylonBane]

Moving physics objects must be Sphere (or Sphere Hat) physics type. OBB is only for immobile physics objects. If they don't have Location/Rotation control set, they will, as you observed, just fall out of the world.

[6741d6236f67evoodoo47]

use type Sphere/1, that should fix it (this is what should be used for small objects that are meant to fall on the floor and collide with it).

OBB/6 is better used for larger objects that cannot be thrown around, like furniture. then it will also need phys controls/location+rotation set to not fall out of the map.

//too slow.

[6741d6236f7caJossiRossi]

Awesome, worked perfectly right away, thank you both. I read in another thread stating that OBB/6 had to be used and missed that was for static models primarily. Figured sphere was just one of those "it won't work, engine is old and weird" things.

[6741d6236f90fvoodoo47]

you probably remember that oddity where you have to use OBB/6 for any object that already exists, and needs to be moved via dml (as using anything else will result in it having no physics at all).

[6741d6236fb7bKolya]

@JossiRossi Originally in SS2 there are unbreakable versions of a few guns, that are usually hidden or hard to get at. SCP removes their unbreakable status, deeming it an accidental non-inheritance of properties.

I don't think it was accidental, but that's besides the point. These guns added depth to the gameplay when a new player in a tight situation noticed that this gun was special and didn't break. Suddenly you had found a favourite gun. Veterans on the other hand would be homing in on those guns, knowing about their unbreakable status.

I think the best solution would be randomization. Also note that these guns had (and still have, even in SCP) other special properties, like reduced kickback. So going past object placement, there's a whole different level to randomize. And that's object properties. Of guns, replicators, security systems, hackable crates, healing beds, ammo drop amounts, etc.
These actually should be easier to manipulate than object placements and can influence the game a lot.
Anyway, just a thought.

[6741d6236ff4bJossiRossi]

Oooh, I knew that some placed guns were unbreakable but not that they had other unique characteristics as well. I had originally intended to just swap guns around, but I think I might prefer to delete all existing guns and randomize new ones with different stats. The only concern I have is I don't want to intentionally make information obtuse. I'm not super opposed to players learning from trial and error, but want to be careful how hard it is to know what is going on in the game.

My current goal is a fully randomized Medsci1, exploring all reasonable randomized tricks.

The ones I can think of right now are:

• Rearrange Locks (tested) (currently for routing purposes, not randomized)
• Corpse Locations/Contents (tested)
• Keys/Door Codes (tested)
• Camera Locations (initial tests)
• Crate Locations/Contents (initial tests)
• Locked Crate Difficulty (untested)
• Enemy Spawns (untested)
• New! Weapon Stats/Locations (untested)
• New! Replicators (untested)
• New! Drops (untested) (definitely can look at the previous randomizer on this part)

My Current To-Do list:

• Finish drafting routing information for MedSci1. What areas are locked behind what "keys". (started)
• Create list of current/alt corpse locations (started)
• Create list of current/alt camera locations (started)
• Create list of current/alt large item locations. Weapons, etc. (unstarted)
• Create list of current/alt small item locations. Food, Hypos, etc. (unstarted)
• Sort lists into respective "areas" (unstarted)

Once I have this structural and locational work done, I'll move toward expanding what's being randomized when I do the shuffling around.
I'm definitely open to ideas that I can throw into my lists for things to explore. I did a lot of tinkering this weekend just seeing what was possible, so I think I need to step back and do some grunt work of building location lists for a bit, so I don't get too ahead of myself.

[6741d623703d9RoSoDude]

Funny coincidence, I just went through the maps an hour ago and removed the special recoil/degradation stats from all weapon pickups for my own mod. It looked like a holdover from an unfinished feature for me -- there's already enough variation from ammo count, weapon condition, and even modification level to add meaningful and readable depth without hidden stat variation. Some of it is absolutely ridiculous too -- an Assault Rifle that never breaks (fixed in SS2Tool/SCP), a Pistol with no recoil, a Pistol with 1/5 degradation rate, and so on. In any case, if anyone wants to know all of the weapon pickups that have special stats, they'll be tabulated in 1.02 of my mod.

I actually think it's a great idea to use an external script to initialize the randomization -- this means that you can potentially scramble resources or even key items between maps (with some care) with proper tracking. If you want, I can offer some help with custom squirrel scripts for replacing items in the maps -- I have one that can replace weapons while also setting their ammo, condition, and status to custom values. This could be easily expanded to other properties (e.g. stack count) as desired. ZylonBane also just created an improved script for putting objects in containers, which is a lot more robust than moving corpses around via DML (which turns off their physics IIRC)

[6741d62370ae5JossiRossi]

Funny coincidence, I just went through the maps an hour ago and removed the special recoil/degradation stats from all weapon pickups for my own mod. It looked like a holdover from an unfinished feature for me -- there's already enough variation from ammo count, weapon condition, and even modification level to add meaningful and readable depth without hidden stat variation. Some of it is absolutely ridiculous too -- an Assault Rifle that never breaks (fixed in SS2Tool/SCP), a Pistol with no recoil, a Pistol with 1/5 degradation rate, and so on. In any case, if anyone wants to know all of the weapon pickups that have special stats, they'll be tabulated in 1.02 of my mod.

I'll keep my eye open for that list of unique weapons, I'm still really fresh to the engine, so a lot of my work is looking at existing items for inspiration. It would be very helpful.

I'll admit I am a little partial to the idea of weapons that just "act different" as a thing a player tries to keep an eye on, but it is really good to know that I might be able to randomize plenty of more visible variables, in case I pull back from something that's less transparent.

I actually think it's a great idea to use an external script to initialize the randomization -- this means that you can potentially scramble resources or even key items between maps (with some care) with proper tracking.

Yeah, as I've gotten more used to Dark Engine I think it really should be possible to direct players through say R&D before Medsci2 for instance. It's going to shred the Shodan stuff, but I'm actually thinking that maybe I ought to gut most of the plot triggers for this particular mode. If you are playing a randomizer you probably know the plot, like Polito's been dead the whole time!!!. The goal would instead to be to "get to the Rickenbacker". Or to find some kind of middle ground between the two concepts.

If you want, I can offer some help with custom squirrel scripts for replacing items in the maps -- I have one that can replace weapons while also setting their ammo, condition, and status to custom values. This could be easily expanded to other properties (e.g. stack count) as desired. ZylonBane also just created an improved script for putting objects in containers, which is a lot more robust than moving corpses around via DML (which turns off their physics IIRC)

Right now placing items is super simple via dml. I very well may push up against some internal limit if I'm not careful, but I'd like for now to stick with dml, just because it is something I can wrap my brain around. I'll happily share any information I build up though, and will hopefully have the MedSci1 prototype done, and that might be a better time to look at what the simplest methods actually are and refinements to the process? Regardless I super appreciate the offer and definitely would be happy to look into that once I... actually know what I am doing... Still very in the dark trial and error here.

[6741d62370de9ZylonBane]

Moving physics objects must be Sphere (or Sphere Hat) physics type. OBB is only for immobile physics objects.

I misspoke a bit here. To clarify, freely moving physics objects must be Sphere, but constrained moving physics objects (doors, elevators) can be OBB.

[6741d62370f91JossiRossi]

More data. These kind of diagram helps me boil down the routing logic to only the things that matter. Where are the locks, and what does unlocking give access to. Then I'll be able to determine what areas are viable for placing keys for those locks. This map I think includes all areas and locks for Medsci1 and 2. (Arrows don't mean anything)

[6741d62371204JossiRossi]

Did some code refactoring and finagling some things, like using a csv to store relevant data for the corpses for instance. Went diving into starting to set up the location database for things. Corpses got a little bit of progress, as did cameras.

I want to make this project as mod friendly as possible. I know there's not a whole lot I can do on that front, but any suggestions on best practices? Should I strive to move objects more than recreate them? With the corpses I just deleted all the existing ones and now plop down new ones in their place in different locations. Let's me have a nice list like this:

I can just keep adding to it, and then choose around 25 of them randomly. Then fill them with items, etc. etc.

But if anyone did something like a "corpses sometimes spawn worms" mod or what have you, chances are I'd have broken that. While had I just moved existing corpses, and altered model details/poses, then in theory a mod that altered the existing corpses would be have compatibility maintained.

I'm not familiar enough with existing mods to have a good grasp of what may or may not make things incompatible and if there were any guidelines I'd gladly follow them even if it means a little more work my side.

[6741d6237131eZylonBane]

Why would you delete and recreate corpses instead of just moving them? What's the point of making the engine do more work?

[6741d6237145aJossiRossi]

A clean slate to work off of seemed nice at the time, since I'll already be altering poses, models, contents, etc. Altering things felt like it'd run the risk of unintended carry overs mucking things up. Fortunately since I already have all the data I can easily pivot it to just alter existing items

[6741d623715b2voodoo47]

generally, you want to remove vanilla objects and spawn new ones as little as possible, because yeah, the more you do it, the higher the risk of breaking compatibility with other mods.

basically, don't do it unless there is absolutely no other way around.

[6741d62371799JossiRossi]

I think deciding how much to move vs. creating new will be something I fight to balance. Like I would enjoy giving players the chance to find some interesting equipment early. Like a recycler early on might be a neat thing to sometimes run into, but I'd be spawning that fresh based off the archetype. But whenever possible I'll move items over making new ones from now on. Fortunately, was an easy fix to just warp around corpses and change their models to ensure that the slight difference in models positions based on their pose won't cause corpses to sometimes spawn in the floors or away from walls.

In the testing it has been kind of fun to see things slowly getting more varied. New camera placements for instance makes things a little more tense. (also altering the response time of the cameras randomly, so you can't always be sure that dashing at the thing will be a gimme like it usually is)

[6741d62371895ZylonBane]

This is starting to sound more like SS2 Rogueifier.

[6741d623719c8JossiRossi]

Could be an interesting thing to try, but don't really want to go too hard on too much randomizing. The camera reactions are just to make cameras a possible threat since they simply aren't to even a casual player. Might spin that off into a minimod though instead. Let players decide.

[6741d62371b86Joe]

If you get this working, how will it differ from Zygo's Randomizer? Is it possible to just randomize container contents (one playthrough, you find a hypo on a particular corpse, the next, you find some bullets) and/or replace a particular item spawn with a randomized one?

[6741d62371dc1JossiRossi]

I actually need to sit down and play with Zygo's Randomizer to get a good feel for what it does that I like. Just haven't had a whole lot of time and have spent what little I have building location databases.

I believe that Zygo's system uses map editing to get things swapped around into preplaced locations. So a power cell can be in 1 of 3 places as an example. With the system I've been setting up, a script will know what areas a player has access to, and all the potential spawn locations within those areas and generate a .dml file for that map. So, a needed key card could be in a crate, on a corpse, or in any of the possible item spawn locations that a player has access to. So, running the script will give you a new .dml file that will change what items spawn, where the spawn, randomized items on corpses, etc. It will in the end eventually have players exploring the ship in non-vanilla game paths, looking for items to further unlock areas.

Part of that is having large pools of item locations. Right now Medsci1 has 3x as many possible corpse locations as corpses. So each new version of the randomizing will give corpses in different places. A big task will be increasing the general item spawn locations by about 3 times as the current as well.

The goal is something akin to the Zelda: A Link to the Past Randomizer, where the items and keys are all swapped around, giving players a unique challenge.

[6741d62372169voodoo47]

Is it possible to just randomize container contents

yes, as long as you can write a new squirrel script. you could get the contents spawning upon level start, or player frob, etc. the script would probably have to have a couple of flags that would restrict the level of items/item list that could be spawned (as you probably don't want fusion ammo on medsci), but it shouldn't be that hard, once you get into squirrel coding.

I actually really wouldn't mind such a mod (basically, container ammo and consumables fully randomized).

[6741d623722b6Joe]

Yeah, I'd *totally* be down for randomized supplies. Randomized objective items are okay, but I think randomizing supplies would spice up each playthrough. I wonder if it's possible to randomize hand-placed items.

[6741d62372405voodoo47]

especially if you know the game like the palm of your hand - I pretty much have pet names for my grenades now.

placed items also squirrel doable, but not without an accompanying map dml.

[6741d6237257dJossiRossi]

The way I'm doing things makes it easy to move/add things, it's dml only but requires running a script. For this project you can go two routes, only move around.existing items, or also generate new ones. I might make two systems, one that does shuffling and another that makes every item possible in every location (with.some weighting to keep nanites still populous for instance) and make it a toggleable setting. Some might want to keep the general level contents, others might like to see obscure ammo mixed in early on.

A hands off version would be pretty neat though and more generally usable.