kingsal

If its useful at this point, I did exactly this in volta 3. All the codes are randomly generated and included in a few readables. I did run into an issue with the text limits on the readables but maybe joebarnins script bypasses that.

Excellent idea! This is gonna be very helpful.

Ah okay.. We need to set "triggered" "1" on those info_portalsky or the engine will just set whatever sky comes last in your map file as the first skybox. Also we need to clear curr_skybox = "" to let the location system update it. This should work now. No need to trigger the skyboxes in the map file or anything like that. skybox_edit2.scriptskybox_edit2.map

Actually this should be inside a zone wrapper so you can do other things when changing zones (set fog, trigger sounds, ect) This will also activate any targets the you have on the location entities. The debounce part is important since it will prevent zones from getting triggered too fast and causing errors. If you do get weirdness like the wrong skybox appears or the location entity triggers its targets twice, let me know. Might need to bring the grace period down from 0.4 - 0.1 or 0.2. string curr_skybox = "portalsky_night"; // <<define starting skybox void change_skybox(entity zone) { entity skybox = zone.getEntityKey("skybox"); if (curr_skybox != skybox.getName()) { sys.trigger(skybox); curr_skybox = skybox.getName(); } sys.println(" [SKY] Sky set to " + curr_skybox); } entity __last_zone = $null_entity; float __last_zone_time = -9999; void setZone(entity zone) { float now = sys.getTime(); // Debounce if (__last_zone == zone && (now - __last_zone_time) < 0.4) { return; } __last_zone = zone; __last_zone_time = now; // do stuff if (zone.getEntityKey("skybox") != $null_entity) { change_skybox(zone); } // Drive one-shot triggers zone.activateTargets($player1); } skybox_edit.map skybox_edit.script

@Bikerdude You forgot the first part I posted (which defines the string) EDIT: see below

You can just trigger them like you have but they need to be called as an entity: string curr_skybox = "sky_city_night"; // whatever your starting skybox entity is called void change_skybox(entity zone) /passes the location ent { entity skybox = zone.getEntityKey("skybox"); if (curr_skybox != skybox.getName()) { sys.trigger(skybox); // just trigger it curr_skybox = skybox.getName(); } sys.println(" [SKY] Sky set to " + curr_skybox); } You don't need a call on exit since this will check to see if there is change. Use spawn arg on the location entity : "skybox" "yourSkyBoxName" Give this a try and see if it works, might need some tweaking...

@BerganteVery nice! I appreciate you finding a secret way to finish the mission. Awesome to see. I might suggest using less music? Or fading the music out after each section? It might make the video more appealing to people who want to experience a little of the mood of the mission. Thats really my only suggestion/ feedback. Well done!

@BikerdudeNo im talking about them rendering weird in the lighting preview mode, not the texture editor.

@func_klausIs this what you are looking for? My configs in appdata Yeah I hear ya, no need for portals skys to render the sky (that would be rad but not necessary). It would be great if they render black or transparent. Anything but white because its really distracting. The parralax texture also do not need to actually parralax, but right now they render totally black which looks weird. As a side note: Im not sure what should and should not be shown in lighting preview, but the widgets are a great start. It would be nice down the line if we can see editor materials (clip, visportals, ect) as an option and maybe other stuff too.

I think im having the same issue from time to time. I basically always stay in noclip mode and I dmap from DR (via the game connection) edit: I don't use an exec config and im not sure what that is tbh. But I do have custom commands in my TDM shortcut such as - con_noPrint "0" and map mymap.map to jump into the current mission.

@func_klausBtw it looks like scripts will load from roaming/DarkRadiant/3.10/scripts/commands/ However any hotkeys I assign to those scripts are still getting nuked on re-opening DR. Am I putting the scripts in the right place?

Nice! I don't recall if it had any plans, but it always felt like a cool feature with a couple usability issues. There are two more texture issues 6705 - Portal sky materials render as white boxes which is crazy annoying - Parralax textures render black. It would be great if these just rendered like any other texture, no need for real parralax support here imo.

@func_klausThank you for the script hotkey plug, thats gonna really speed up script usage. Here is something else that might be worth looking into: 6704 The lighting preview mode is great, but it would be more usable if we could see widgets and whatever brush/ entity we have highlighted. ( I tried to photoshop this up below) It would be rad to just work right in that lighting preview mode. Im sure others could chime in with ideas here as well or if this is even viable. I know lighting preview has some other issues but I can't recall where @OrbWeaverand/ or @greeboleft off with it.

That def looks pretty good, here are some additional spawnargs you can mess with to get something you like: "draws_weapon" "0" "bone_focus" "Head" // This is where they aim from, pretty specific but could be useful for monsters "unarmed_ranged" "1" "fire_range" "700" "def_projectile" "atdm:projectile_bloater" // see tdm_projectiles for a list "attack_cone" "70" "attack_accuracy" "0.8" "projectile_spread" "0" //only for multiple projecitles "projectile_speed" "300" // 200-400 is kind of average rock throw, 800+ is gonna be like an arrow "num_projectiles" "1" "outofreach_projectile_enabled" "1" // This is what enables guards to throw rocks and such at you when you are in a place they cant reach Btw having "unarmed_melee" "1" and "melee_range" "40" means the beast will still try to punch you if you get too close. You might want ot mess with that to get the behavior you want. Ive disabled it before by setting melee_range to 1 ( iirc setting 0 has adverse effects) Projectile speed seems to be a good thing to tweak to get the gameplay feel you are looking for. The default fireballs are pretty good but it just depends on how you are deploying these guys.

weld_verts.pyrelax_verts.pypatchsplitter.pypatch_match_seam_uvs.py @func_klausIm so stoked we have someone working on DR again and all the above suggestions sound awesome. I was talking to Welli and Amadeus about a couple scripts I had AI write for me to help with patches. Down the road it would be cool to improve the patch workflow and capabilities. I'll just post what I sent them. Fair warning these are ugly and made by AI so use at your own risk kinda deal These go in darkradiant/scripts/commands (please backup your folder before using these) --------------------------------- 1. Unify Patch Textures This doesnt work yet, but the idea is it will try to unify the texture coordinates on patches so the can have seemless textures without combining them. Good for like mountains and such 2. Relax verts Kinda whack, but it works(ish) Select verts on a patch. Hit Relax Amount 0-1 is the relax percentage Shrink (0 or 1 on or off basically). Collapses the verts inward Bloat same but inflates them 3. Weld Verts This will take two or maybe up to 8? verts and weld them (move them to the same XYZ, not literally weld them) Its still a little crashy if you dont select ANY verts or too many. Chat gpt cant make up its mind here 4. Split Patch Just a slightly faster/ more reliable version of the one we have. --------------------------------- No expectation for anyone to jump into making these better, but figured Id post them as they have helped me. Ill update when I get Unify Patch Textures working. @func_klausI ran into an interesting problem where DR couldn't bind these scripts to hotkeys. Everytime DR loads it nukes them. Maybe something in DR startup is preventing it from writing the binds for custom scripts correctly?