Connection to TDM with automation

[stgatilov 1251]

On 12/29/2020 at 8:41 PM, peter_spy said:

That's still confusing. User doesn't have to be familiar with underlying implementation, hot reload is continuous sync of what's being done with the map in dr, right? So how 'one time hot reload' differs from save map and reload map in TDM, and how's that useful?

Regarding "reload map" vs "update map".

I guess "reload map" mode can be removed from GUI, leaving only the "update map"... if "update map" works well enough and nobody sees any reason to retain the other mode. For debugging purposes, I can always save map in DR and execute "reloadMap" in TDM console.

As for "always sync" vs "sync now" in "update map" mode, I think both are useful.

[peter_spy 1603]

1 hour ago, kingsal said:

Tweaking textures! This is hands down the most tedious thing. Having to dmap and reload just to see texture changes is very time consuming.

What do you mean by that? Aligning textures on brushes? Otherwise, you don't need to dmap and reload the map, if you update texture images, models, or material declarations.

[kingsal 592]

29 minutes ago, peter_spy said:

What do you mean by that? Aligning textures on brushes? Otherwise, you don't need to dmap and reload the map, if you update texture images, models, or material declarations.

Tweaking texture in DR.

[stgatilov 1251]

38 minutes ago, peter_spy said:

What do you mean by that? Aligning textures on brushes?

I guess @kingsal means changing textures on brushes.
Right now hot reload cannot do it, so dmap + restart is needed.

To be honest, tweaking monsterclip is a way much harder task among these two...

[kingsal 592]

1 hour ago, stgatilov said:

Regarding "reload map" vs "update map".

I guess "reload map" mode can be removed from GUI, leaving only the "update map"... if "update map" works well enough and nobody sees any reason to retain the other mode. For debugging purposes, I can always save map in DR and execute "reloadMap" in TDM console.

As for "always sync" vs "sync now" in "update map" mode, I think both are useful.

I can see cases where you might want RELOAD MAP. This is more just a convenience thing. Lets say I have a scripted sequence in my mission that only runs once that I am tweaking (something that doesnt work on update map). I can quickly save my map, hit the "reload map" and when I switch back to TDM, bam, the map has already started the reload process. This really is just saving a couple clicks but I think its worth it.

[kingsal 592]

3 minutes ago, stgatilov said:

I guess @kingsal means changing textures on brushes.
Right now hot reload cannot do it, so dmap + restart is needed.

To be honest, tweaking monsterclip is a way much harder task among these two...

Yep, changing textures in DR. I would argue that yes monster clipping is incredibly tedious, but I do that less often than I texture. 

[stgatilov 1251]

29 minutes ago, kingsal said:

I can see cases where you might want RELOAD MAP. This is more just a convenience thing. Lets say I have a scripted sequence in my mission that only runs once that I am tweaking (something that doesnt work on update map).

If it runs once on trigger, you can probably respawn the trigger, and run it again.

[kingsal 592]

@stgatilov @OrbWeaver @greebo Just a heads up, as I am working I am finding RESPAWN SELECTED ENTITY very useful. It seems on update / reload certain things like hide_distance and _color on func_emitters do not update, so I find myself respawning those manually. 

 

also @stgatilovIt seems TDM doesnt set noclip, god, ect on camera sync when you restart the map completely from TDM. I've killed myself a couple time after dmapping and then using the camera sync. My thinking is that whenever camera sync is active, even after reload these cheats should kick back on. (Maybe we can make this a settings option?)

[stgatilov 1251]

5 hours ago, kingsal said:

@stgatilov @OrbWeaver @greebo Just a heads up, as I am working I am finding RESPAWN SELECTED ENTITY very useful. It seems on update / reload certain things like hide_distance and _color on func_emitters do not update, so I find myself respawning those manually.

Yes, respawn should serve as a way to "force" full update.

Could you please report precisely cases which don't work, so that I could probably adjust builtin rules in future?

Quote

also @stgatilovIt seems TDM doesnt set noclip, god, ect on camera sync when you restart the map completely from TDM. I've killed myself a couple time after dmapping and then using the camera sync. My thinking is that whenever camera sync is active, even after reload these cheats should kick back on. (Maybe we can make this a settings option?)

It is pretty hard to understand when something is changed from within TDM. For example, in order to set god mode ON, "god" command is executed, then the console message is read, and if it says "god mode OFF", then "god" command is executed again.
There is no direct way to learn if god mode is ON, and although it is possible to add a specific automation command for this, I'd better avoid it. And it is even harder to learn when god mode changes: I believe current architecture is like HTTP, i.e. TDM cannot send stuff when it wants to, it only responds to requests sent from DR.

I think it would be better to add a way to "restart FM", and make it disable/enable camera sync automatically.

[stgatilov 1251]

I think we can add a GUI button which would start or restart map in TDM. It can be used for many different features already proposed. I think there should also be a "dmap" checkbox near the button.

I see it working the following way:

1. If TDM is already connected, then execute "getviewpos" to learn current coordinates and disconnect.
2. Save the map in DR if it has local modifications.
3. If there is no TDM with automation ON, then start new one.
4. Connect to TDM instance with automation ON.
5. Select the current FM(project) if it does not match yet (extend automation: learn the current FM).
6. Run dmap if the "dmap" checkbox is enabled. If there is an error, then stop completely.
7. Start the map.
8. If camera sync was enabled initially, then enable it again (turning noclip/god/notarget ON).
9. If the player position was saved, then "setviewpos" to it.
10. If various other modes (i.e. map update) were on, then enable them back too.

I think it should cover the features like "start TDM automatically", "restart map", and "dmap map".

 

P.S. @OrbWeaver, I guess we need to search for yet another library, this time similar to Python's subprocess. I have written various process-starting C++ code with WinAPI in the past, and don't want to go through it again

[OrbWeaver 639]

7 hours ago, stgatilov said:

P.S. @OrbWeaver, I guess we need to search for yet another library, this time similar to Python's subprocess. I have written various process-starting C++ code with WinAPI in the past, and don't want to go through it again

Boost.Process can handle this, however we don't currently have Boost in DarkRadiant (since all of the Boost features we were originally using are now part of Standard C++, and I understand the Boost dependency complicates the build on Windows).

I see that wxWidgets has some process related classes, would these be sufficient?

[kingsal 592]

12 hours ago, stgatilov said:

I think we can add a GUI button which would start or restart map in TDM. It can be used for many different features already proposed. I think there should also be a "dmap" checkbox near the button.

I love this proposal if its feasible!

[kingsal 592]

14 hours ago, stgatilov said:

Could you please report precisely cases which don't work, so that I could probably adjust builtin rules in future?

Right so far this is what doesn't seem to be hotReloading correctly and requires respawning. I'll report more as I find them:

• Speakers are not updating "s_shader" and playing the newly selected sound.
• Func_emitters are not updating "_color" on particles. 
• Func_statics are not updating "hide_distance"

I've also noticed that occasionally the system isn't deleting the old entity. So in some cases its spawning a duplicate func_static or speaker when respawning the entity.

[stgatilov 1251]

On 1/2/2021 at 2:59 AM, kingsal said:

I've also noticed that occasionally the system isn't deleting the old entity. So in some cases its spawning a duplicate func_static or speaker when respawning the entity.

Very unlikely.

But when you delete/respawn entity, its sound remains (that's default behavior when deleting entity). I'll make sure sound is stopped when entity is deleted via hot reload.

Quote

Speakers are not updating "s_shader" and playing the newly selected sound.

I'll force respawn if any spawnarg starting form "s_" has changed. Along with sound stopping fix, it solves the problem.

The harder problem is with lights. They have some stuff with "lit", "extinguished", "unlit", etc. suffixes, and script code which switches between them. I'm not yet certain how to deal with them.

[kingsal 592]

3 hours ago, stgatilov said:

Very unlikely.

This for sure happened. I'll capture a video or screenshots next time I'm in the game.

[kingsal 592]

@stgatilov EDIT : Looking into this further, I think this is a problem specific to these models. I can't seem to reproduce with other models. Might be an issue with the mesh or something weird?

This is what I did to get the duplicates (video below):

• Selected a group of func_statics. Reduced the current hide_distance and hit enter to apply to all:
• Hit respawn selected entities
• There are now duplicates spawned in the game.

Video here:

https://www.dropbox.com/s/722cns51h3wbedp/The Dark Mod 2.09_64 2021-01-06 10-55-39_Trim.mp4?dl=0