kingsal

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?

I want to say it started in beta 5, maybe after the updates to reloadscript. It doesnt appear to be related to any specific type of scripitng error. To reproduce: - Open saint lucia, - Make an obvious error in any script - reloadScripts -> crash and / or freeze Sometime it will actually post the error in the console and then freezes. OR it just completely freezes before even printing (requires a control alt delete -> end task in either case) . Im on windows 11 if that makes a difference.

@stgatilovApolgies if this was mentioned but I am having a problem if an error is posted to the console. I get a black screen and a freeze if the level tried to load with an error in its map.script file (probably in any script file actually.) The error shows up in the log for example : ERROR:Function 'spiderweb_enter' has the wrong number of parameters for function call from 'test_web1' -------------------------------------- WARNING:idSession: triggering mainmenu watchdog But it doesnt do the previous behavior of kicking you out of the map and posting the error. It just freezes.

@stgatilovGood fix on reloadScript, thank you. reloadEngine is still crashing for me but this has been common throughout the versions. Its worth looking into if you have the time.

Wow my statements were back in this massive massive thread years ago: Anyhow, subtle out the box and then let players decide how much frob shader they want.

@STiFUIm glad to see this is back on the menu! Looks really nice. A neutral grey or a very subtle "golden" hue for all frobable objects is the way to go. Colored shaders can get messy with different lighting scenarios, different loot object colors, always fighting players preferences, ect. Also object specific frob colors will open up a brand new communication channel that wasnt there before. Its just messy imo. I did some early prototypes for colors a long time ago, might be in the dev forums somewhere actually. Anyways, great to see it getting worked on. Thanks for doing it.

Yeah so I use them in a couple ways but ill give you some examples: Scripting inside fm/scripts - Fire up map - Make scripting changes. - reloadScripts to see changes. (crash in 2.14) - Load map again. *Side note - it would be great if reloadScripts loaded you back into the map your were on, but maybe there is a reason for this? Level editing: - Fire up DR - Use (Re)start map to create connection (works in 2.14) - Use hotReload for changes. (works in 2.14) This usually works great However.. There are some cases where we just need to reload the whole engine (usually from .def confilcts or some weird edge cases) - reloadEngine (crash in 2.14) . This all works in 2.13 and both crashes will only occur once you are in a map.

@stgatilovIm having an issue with reloadScript and reloadEngine crashing to desktop in 2.14. I did a fresh install and the only thing I carried over are my hotkeys. I tested it on La Banq and St Lucia with the same result.

Yessss! This is one hell of mission. Don't miss this one!

Yeah that could be it. I remember using it to test AI model lods and maybe it just stuck around. Its doesn't seem necessary, but probably harmless in that mission.

Nice updates! Thank you for fixing the flashbombs, they're gonna be a lot more useful now. @datiswousUse a different mission to test that. I don't remember why that lod_bias is there, but Im sure there is or was a reason for it.

@stgatilovRoger that, thanks for the info.