Thomas Debesse [Thu, 13 Jul 2017 15:03:31 +0000 (17:03 +0200)]
remove version string from home config path
- GtkRadiant uses ~/.radiant/1.6.0/
- UFORadiant uses `~/.ufoai/radiant/
- DarkRadiant uses ~/.darkradiant/
- NetRadiant was using uses both ~/.netradiant/1.5.0/ and ~/.netradiant/1.1.5/, which is not defined by the version but the way you build it.
- AARadiant uses `~/.aaradiant/1.5.0/
- XrealRadiant used ~/.rxealradiant/
I guess no one Radiant out there needs a version number in config path to not mess with other Radiants.
Thomas Debesse [Sun, 23 Jul 2017 21:33:29 +0000 (23:33 +0200)]
really filter notex (filter fallback)
- filter all /notex and /shadernotex
- filter both shadername and texture name
- only add group if shader isn't notex
- refresh the tree (hence groups) on toggling
- rename "filter notex" to "filter missing"
to avoid confusion, because that's what that
does
Thomas Debesse [Sat, 22 Jul 2017 19:57:34 +0000 (21:57 +0200)]
[dpkdir] introducing dpkdeps.h
It was a change included in a commit by Neumond I haven't picked-up
because I disagreed with some other changes this commit introduced.
But this part is legit, it moves some DPK's DEPS file read and
version computation code to its own file. This clean-up a bit the
vfspk3 code and by the way it will be needed by future code to write
DEPS file from NetRadiant itself.
This commit is only about reorganizing code a better way.
Thomas Debesse [Tue, 18 Jul 2017 11:04:26 +0000 (13:04 +0200)]
[dpkdir] restart VFS only for Map_Free() and Map_LoadFile(), refresh others
Since there is no map file observer anymore for that stuff,
we Restart or Refresh it explicitely when needed.
- Opening map or New map needs Restarting VFS.
- Saving map or Renaming map (Save as) needs Refreshing VFS.
The Refresh also triggers the Texture browser.
A previous fix for #105 was done Refreshing VFS instead of Restarting it
but it was not perfect, for example map opening behavior is better with
VFS restart, and map saving needs to refresh the VFS and the texture
browser but not restart (that was the earlier fault). So, it's clearly
not a good idea to trigger either Refresh or Restart on any map event
since the behavior differs according to the event.
If one day one plugin wants to act on VFS on map event, it must refresh or
restart VFS according to what the plugin does. It does not make sense to
trigger the same task for different events.
Neumond probably thoughts it would be cool to make a file observer
that reloads the VFS each time the map change, was a nice idea.
Badly, it makes the VFS reloading itself before saving a map,
losing the current work done.
Would be easier to not rely on that observer mechanism and just
make an explicit call to reload VFS when needed instead, so we
revert this part.
This VFS reload mechanism will be reintroduced in next commit.
This commit fixes #105 even if DPK VFS is not yet fully restored.
Note: this observer mechanism was also made available to plugins, so
it's not available to plugins anymore (it was not used, and it's a bad
idea, see the next commit).
Thomas Debesse [Tue, 18 Jul 2017 11:26:30 +0000 (13:26 +0200)]
refresh VFS on map change instead of restarting VFS, fix #105
Neumond probably thoughts it would be cool to make a file observer
that reloads the VFS each time the map change, was a nice idea.
Badly, it makes the VFS reloading itself before saving a map,
losing the current work done.
Hopefull, since I added a “Refresh” ability that refreshes the VFS
without reloading the map, we can just use that Regresh ability
instead.
projects / xonotic / netradiant.git / log