eol
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/ZeroRadiant@190 8a3a26a2-13c4-0310-b231-cf6edde360e5
This commit is contained in:
TTimo
@@ -1,266 +1,266 @@
|
||||
OK. Again I would have liked to get a design document before it being done. Main functionalities we
|
||||
need in the inspector:
|
||||
|
||||
- Unifiy the inspector under a single dialog box, called with 'S'
|
||||
|
||||
- Depending on what is currently selected, display several frames in the inspector:
|
||||
only brushes -> surface inspector
|
||||
only patches -> patch inspector
|
||||
brushes & patches -> both
|
||||
and later when brush primitives are mixed with regular brushes + plugin entities, raise whatever
|
||||
additional inspector stuff we need
|
||||
|
||||
- The camera view must update realtime when we change some parameters.
|
||||
|
||||
- Get rid of the Apply button, use the Undo code to store settings when surface inspector is
|
||||
raised. If user hits Cancel, call the undo stuff.
|
||||
|
||||
- Use the message broadcasting stuff to keep the inspectors up to date when the user changes the
|
||||
current selection. Be careful to keep the undo stuff in sync with the select / deselect operations.
|
||||
|
||||
- Use a 3-state scheme to display the params in the widgets. If two faces are selected that don't
|
||||
have the same shift increment, just grey out the shift box.
|
||||
|
||||
Messaging:
|
||||
- a good chunk of the work is moving the selection/creation stuff to the messaging API
|
||||
we no longer use UpdateSurfaceDialog, we post messages instead ..
|
||||
the surface inspector has hooked one of it's listeners into the corresponding message
|
||||
we may need to reorganize the messages, maybe introduce a hierarchy?
|
||||
or pass a void * param with messages?
|
||||
|
||||
- we don't post messages like "update surface inspector", we post messages that say "this and that
|
||||
have changed", then the surface inspector reacts if it needs to.
|
||||
Do we need marshalling in the messages? Very likely .. maybe using Gtk signal stuff would be interesting?
|
||||
|
||||
-> the messaging stuff is a big chunk of work and our surface inspector changes are not totally
|
||||
dependent on it. Better leave that for l8r
|
||||
|
||||
the inspector works by states and transitions? Or we post messages to it?
|
||||
Use case:
|
||||
the user raises the inspector .. if we are up we'll ignore, if we are hidden we'll
|
||||
go through the whole process (initialise, look at what is selected, display)
|
||||
then we enter an active state (listening for select / deselects and applying stuff)
|
||||
|
||||
all in all it seems to be too big a change for next release. will see later probably.
|
||||
Trying a few more days with it, see what happens. after all the interface is fairly restricted
|
||||
so there's a good chance our changes are fairly stable in the end. But rebuilding the whole interface
|
||||
part might be too much ...
|
||||
We need something state based? AND a set of messages ..
|
||||
but first, need to write the initialisation loop
|
||||
build the dialog, get the current surface information and display
|
||||
|
||||
Undoing the changes on the selected stuff:
|
||||
at any point in time, one can get a snapshot of selected stuff and use it to store the surface
|
||||
properties settings for later on. But what happens if the user modifies the selected brush, pushing
|
||||
it in the undo stack? Then we would cancel the changes? (and just backup to the state right after
|
||||
the modif)
|
||||
We could has the 'Apply' button used for that .. grey it out when the current state is the one in
|
||||
the backup. This happens whenever we hit 'Apply' or change something in the selection.
|
||||
The selection has several items: entities, brushes and selected faces (possibly later generic plugin entities)
|
||||
Current undo stuff is aimed at entities and brushes.
|
||||
NOTE: you can't have selected faces and brushes/entities at the same time, that's a good point to
|
||||
keep that seperated to deal with undo and storage
|
||||
On what side should the implemetation be ? undo.cpp select.cpp or surfacedialog.cpp ?
|
||||
We are going to do it with the messaging API anyway..
|
||||
And hook in the undo stuff, to reset the snapshot each time something gets pushed in the undo?
|
||||
|
||||
We have advanced stuff on the Inspector branch, doing basics on Alpha branch.
|
||||
Start writing the watch code in surfacedialog.cpp, see if we need some merging with Undo stuff l8r
|
||||
We need to track for the patch inspector as well..
|
||||
|
||||
basic code for CSurfaceUndo written. need to add hooks for the snapshot stuff and undo stuff. and a
|
||||
debug flag to monitor the life cycle of the object.
|
||||
|
||||
some use cases:
|
||||
- select a brush
|
||||
- bring up surface inspector
|
||||
- check we had the debug messages from CSurfaceUndo (initialise, activate, snapshot)
|
||||
- edit the surface settings
|
||||
- check the views are updating correctly
|
||||
- hit Ok
|
||||
- check we had a deactivate message
|
||||
OK
|
||||
|
||||
- select a brush
|
||||
- bring up surface inspector
|
||||
- check we had the debug messages from CSurfaceUndo (initialise, activate, snapshot)
|
||||
- edit the surface settings
|
||||
- check the views are updating correctly
|
||||
- hit cancel / escape
|
||||
- check we have a undo and deactivate from CSurfaceUndo
|
||||
OK
|
||||
|
||||
- select a brush
|
||||
- bring up the surface inspector
|
||||
- edit the surface settings
|
||||
- hit apply
|
||||
- edit them again
|
||||
- hit cancel / escape
|
||||
- check you get back to the apply state
|
||||
OK
|
||||
|
||||
- make two brushes
|
||||
- select a brush
|
||||
- bring up surface inspector
|
||||
- change settings
|
||||
- select an additional brush
|
||||
- check the surface inspector, new snapshot
|
||||
- hit cancel
|
||||
- check brushes remained in the same state
|
||||
- use standard Undo
|
||||
- check the first brush got back to it's initial settings
|
||||
OK
|
||||
|
||||
- select a brush
|
||||
- bring up surface inspector
|
||||
- change settings
|
||||
- select an additional brush
|
||||
- check the surface inspector, new snapshot
|
||||
- change more settings
|
||||
- hit cancel
|
||||
- check the first brush returned to intermediate state, and second to initial state (i.e. last snapshot)
|
||||
OK
|
||||
|
||||
g_surfaceUndo acts as a layer on top of the core Undo code when the surface inspector is activated.
|
||||
We need it because the surface inspector can edit faces which are not handled by the undo?
|
||||
(or does the current code push the whole brush when editing a face?)
|
||||
|
||||
not sure of the utility of the g_surfaceDialog hooks here ..
|
||||
default undo usage in the sruface inspector sends way too many undo messages.
|
||||
with the new scheme we store in undo only when select/deselect or user hits apply
|
||||
that way the 'Cancel' and later Ctrl+Z calls make sense
|
||||
but is it worth implementing a new class to achieve that?? .. yes because we intend a later cleanup
|
||||
of this part. (ahem is this reason good enough..)
|
||||
this part is actually much closer from the undo code than I had expected..
|
||||
'Cancel' call being an Undo call..
|
||||
|
||||
going to Inspector3:
|
||||
don't create a new class, simply use the Undo more intelligently?
|
||||
i.e. don't create undo stuff when editing the brush
|
||||
-> we add a flag to turn off the default undo behaviour and force Undo storage when we want
|
||||
we could also store the undo Id we are interested in and call undo several times to get it back
|
||||
|
||||
NOTE: what happens if the user hits undo when the surface inspector is up?
|
||||
-> we'll have to take his request into account?
|
||||
err .. performing which undo? The texture positioning or something else?
|
||||
seems the snapshot approach would still make sense then?
|
||||
|
||||
more use cases, see with Undo calls and select/deselect events
|
||||
NOTE: this whole thing is probably a single call to select_settexture that needs to be turned on/off
|
||||
instead of working at the undo level. but we would like to move to messaging so maybe it still makes sense
|
||||
the undo call is in Select_SetTexture (which does not have that many callers, I was expecting more)
|
||||
|
||||
the question about having the undo code keep working when surface inspector is around is still raised.
|
||||
but it makes it a lot harder, gotta have a real inspector mode in the undo?
|
||||
dunno, think about it again later
|
||||
|
||||
two operations are mixed in a single one and should not be:
|
||||
reading the map to get the current data we'll manipulate
|
||||
feed it in the dialog box widgets
|
||||
WARNING: when putting stuff in the widgets, it raises a shitload of update messages and therefor completely
|
||||
fucks up our OnOK OnApply OnCancel scheme (specially OnApply!)
|
||||
|
||||
NOTE: we want to switch between Surface inspector for brushes only and Patch inspector for patches only
|
||||
there's some crappy code in the surface inspector that we need to get rid of
|
||||
but need to check about that before with Spog or others
|
||||
|
||||
Forcing the way into using the surface inspector is SCREWED?
|
||||
Doesn't seem to work the way we want to. Always get parasite Undo messages and stuff.
|
||||
We could use a seperate stack for Undo with the surface inspector?
|
||||
Just store the surface properties in a seperate stack?
|
||||
When user hits cancel you go back and apply whatever you had?
|
||||
Doesn't seem like a clean way either.
|
||||
|
||||
Now dealing with both regular surface inspector and patch inspector:
|
||||
we have some stuff that needs to be on/off with the two inspectors
|
||||
what about catching the messages and issuing new snapshots?
|
||||
the main surface inspector is doing it?
|
||||
no!
|
||||
so what, we have several states?
|
||||
FUCKED UP
|
||||
|
||||
INSPECTOR 5 ----------------------------------------------------------------
|
||||
restarted from scratch, made much more simple changes.
|
||||
trying another trick for undo (!)
|
||||
just let the undo work as usual, but call undo ourselves in SetTexMods if we have create the last do
|
||||
requires proper initialization/deinitialisation.. in SetTexMods and GetTexMods..
|
||||
|
||||
getting rid of patch manipulation code in the regular surface inspector. The buttons will
|
||||
still work, but manip will require the patch inspector. (seems the patch inspector doesn't have that
|
||||
much success anyway)
|
||||
|
||||
TODO:
|
||||
OK get rid of patch stuff
|
||||
OK get rid of the texture toolbar? (it's broken right now)
|
||||
(and doesn't have anything usefull..)
|
||||
OK (Partial) OnCancel? we need to cancel the texdef as well
|
||||
store an undo texdef each time we grab new texdef stuff
|
||||
this works in reverse than the Undo code? When we do the initial
|
||||
problem is, in some cases the settings that show up are not in sync with what's in the inspector??
|
||||
(we can't avoid that because if a brush is selected there's no single setting)
|
||||
prolly get it out as is and let Spog or others send feedback about what it's supposed to do..
|
||||
for now: store stuff in the cancel texdef when we initialize an undo loop
|
||||
revert to that if OnCancel is used
|
||||
OK message when spinning over a patch?
|
||||
DUPLICATE (.. see below ..) check the increments we store in the SI are used when shift + arrows etc.
|
||||
no it doesn't work .. the shifting on keyboard shortcuts is done with m_nTextureTweak
|
||||
seems m_nTextureTweak is nowhere available in the prefs (and it's not in MFC builds either)
|
||||
some cleanup to be done around that it seems
|
||||
OK (.. merged with below, maybe some special cases left ..) texture widget (catch the Enter key to force-call an OnApply)
|
||||
OK (.. see above ..) catch Enter key at dialog level to call OnDone
|
||||
NO (.. it's clean, but thats too many lines of code ..) move the code that blokes updates to use gtk_signal_handler_block_by_func and gtk_signal_handler_block_by_func
|
||||
OK shift + arrow must match the SI settings,
|
||||
OK (FIXME .. not using the right scale (using the scale step instead! + add a button in SI to 'Match grid')
|
||||
POSTPONED (.. m_nTextureTweak is used in the nudge commands ..
|
||||
.. and nudge shortcuts are broken right now ..) get rid of m_nTextureTweak
|
||||
+ SI and PI always on top!
|
||||
|
||||
+ known issues: "Match Grid" is broken in BP mode
|
||||
|
||||
now on the patch inspector (nightmare!):
|
||||
OK (.. put it as readonly .. don't bother ..) texture name widget is screwed?
|
||||
OK the spinners scheme doesn't work, the stuff in the dialog is the inc step and we just need arrows
|
||||
OK get rid of the 'Type' dialog box
|
||||
POSTPONED (.. can't do undo on PI without proper Undo module ..) add proper Done Apply Cancel with Undo
|
||||
NO (.. too much work for something that sucks ..) make the changes reflect in the views when manipulating the entries
|
||||
OK (.. using %g ..) cut down on the number of digits!
|
||||
OK increment steps to be stored in the registry
|
||||
|
||||
putting the Cancel stuff in the surface inspector: only based on the Undo code, no cancel settings to store
|
||||
because we don't have actual storage of a current texdef (we only send alterations) BTW we should do that for
|
||||
brushes as well
|
||||
the patch inspector works by increments, Patch_SetTextureInfo to incrementally modify the patch.
|
||||
we can still do some undo by having a texdef storing the changes and working together with the undo
|
||||
if the undo is recognized, it means our current texdef increment is valid
|
||||
no, we can't represent the combination of several increments scale and rotate in a single texdef..
|
||||
get rid of the undo code for now .. only Apply and Done left
|
||||
|
||||
it seems it's still vastly broken when you select something. or is it on linux only?
|
||||
need a LOT of testing and figuring it out!!
|
||||
selecting a brush breaks totally.. (the texture screws up it seems)
|
||||
does it attempt to change the texture of the selected object??
|
||||
also: it seems you can multiple select a same brush??
|
||||
|
||||
the UNDO code of the SURFACE INSPECTOR IS STILL BROKEN ????
|
||||
(ok I'm really screwed, time to sleep)
|
||||
-> can't reproduce now?? maybe it's linux specific problem, I can't tell
|
||||
|
||||
FOUND A WAY TO REPRODUCE THE CRASH:
|
||||
+ select brush
|
||||
+ hit "Fit"
|
||||
+ hit the shift spinners two times
|
||||
OR:
|
||||
+ select single face on brush
|
||||
+ manually edit scale values
|
||||
-> maybe we have a problem with current texture? (NO)
|
||||
it's some kind of infinite loop? we call UpdateSurfaceInspector from Select_Brush and bang!
|
||||
no, it's a texdef from a face that got deleted
|
||||
prolly that hooking the undo code in there screws up the selected faces stuff
|
||||
if you undo a selected face operation, you end up with the whole brush selected.
|
||||
but that does not necessarily explain why you remove the face at Undo_Start
|
||||
ho well .. removed the undo buffering when selected faces and everything's better
|
||||
would need to re-establish the right face selection after undo, might solve the problem
|
||||
(actually you'd still need to have the settings point to the right object)
|
||||
|
||||
From PJ about the 'Match Grid' stuff: textures are moved in pixels, not units.
|
||||
We must rely on the current texture scale AND gridsize to compute the shift increment
|
||||
OK. Again I would have liked to get a design document before it being done. Main functionalities we
|
||||
need in the inspector:
|
||||
|
||||
- Unifiy the inspector under a single dialog box, called with 'S'
|
||||
|
||||
- Depending on what is currently selected, display several frames in the inspector:
|
||||
only brushes -> surface inspector
|
||||
only patches -> patch inspector
|
||||
brushes & patches -> both
|
||||
and later when brush primitives are mixed with regular brushes + plugin entities, raise whatever
|
||||
additional inspector stuff we need
|
||||
|
||||
- The camera view must update realtime when we change some parameters.
|
||||
|
||||
- Get rid of the Apply button, use the Undo code to store settings when surface inspector is
|
||||
raised. If user hits Cancel, call the undo stuff.
|
||||
|
||||
- Use the message broadcasting stuff to keep the inspectors up to date when the user changes the
|
||||
current selection. Be careful to keep the undo stuff in sync with the select / deselect operations.
|
||||
|
||||
- Use a 3-state scheme to display the params in the widgets. If two faces are selected that don't
|
||||
have the same shift increment, just grey out the shift box.
|
||||
|
||||
Messaging:
|
||||
- a good chunk of the work is moving the selection/creation stuff to the messaging API
|
||||
we no longer use UpdateSurfaceDialog, we post messages instead ..
|
||||
the surface inspector has hooked one of it's listeners into the corresponding message
|
||||
we may need to reorganize the messages, maybe introduce a hierarchy?
|
||||
or pass a void * param with messages?
|
||||
|
||||
- we don't post messages like "update surface inspector", we post messages that say "this and that
|
||||
have changed", then the surface inspector reacts if it needs to.
|
||||
Do we need marshalling in the messages? Very likely .. maybe using Gtk signal stuff would be interesting?
|
||||
|
||||
-> the messaging stuff is a big chunk of work and our surface inspector changes are not totally
|
||||
dependent on it. Better leave that for l8r
|
||||
|
||||
the inspector works by states and transitions? Or we post messages to it?
|
||||
Use case:
|
||||
the user raises the inspector .. if we are up we'll ignore, if we are hidden we'll
|
||||
go through the whole process (initialise, look at what is selected, display)
|
||||
then we enter an active state (listening for select / deselects and applying stuff)
|
||||
|
||||
all in all it seems to be too big a change for next release. will see later probably.
|
||||
Trying a few more days with it, see what happens. after all the interface is fairly restricted
|
||||
so there's a good chance our changes are fairly stable in the end. But rebuilding the whole interface
|
||||
part might be too much ...
|
||||
We need something state based? AND a set of messages ..
|
||||
but first, need to write the initialisation loop
|
||||
build the dialog, get the current surface information and display
|
||||
|
||||
Undoing the changes on the selected stuff:
|
||||
at any point in time, one can get a snapshot of selected stuff and use it to store the surface
|
||||
properties settings for later on. But what happens if the user modifies the selected brush, pushing
|
||||
it in the undo stack? Then we would cancel the changes? (and just backup to the state right after
|
||||
the modif)
|
||||
We could has the 'Apply' button used for that .. grey it out when the current state is the one in
|
||||
the backup. This happens whenever we hit 'Apply' or change something in the selection.
|
||||
The selection has several items: entities, brushes and selected faces (possibly later generic plugin entities)
|
||||
Current undo stuff is aimed at entities and brushes.
|
||||
NOTE: you can't have selected faces and brushes/entities at the same time, that's a good point to
|
||||
keep that seperated to deal with undo and storage
|
||||
On what side should the implemetation be ? undo.cpp select.cpp or surfacedialog.cpp ?
|
||||
We are going to do it with the messaging API anyway..
|
||||
And hook in the undo stuff, to reset the snapshot each time something gets pushed in the undo?
|
||||
|
||||
We have advanced stuff on the Inspector branch, doing basics on Alpha branch.
|
||||
Start writing the watch code in surfacedialog.cpp, see if we need some merging with Undo stuff l8r
|
||||
We need to track for the patch inspector as well..
|
||||
|
||||
basic code for CSurfaceUndo written. need to add hooks for the snapshot stuff and undo stuff. and a
|
||||
debug flag to monitor the life cycle of the object.
|
||||
|
||||
some use cases:
|
||||
- select a brush
|
||||
- bring up surface inspector
|
||||
- check we had the debug messages from CSurfaceUndo (initialise, activate, snapshot)
|
||||
- edit the surface settings
|
||||
- check the views are updating correctly
|
||||
- hit Ok
|
||||
- check we had a deactivate message
|
||||
OK
|
||||
|
||||
- select a brush
|
||||
- bring up surface inspector
|
||||
- check we had the debug messages from CSurfaceUndo (initialise, activate, snapshot)
|
||||
- edit the surface settings
|
||||
- check the views are updating correctly
|
||||
- hit cancel / escape
|
||||
- check we have a undo and deactivate from CSurfaceUndo
|
||||
OK
|
||||
|
||||
- select a brush
|
||||
- bring up the surface inspector
|
||||
- edit the surface settings
|
||||
- hit apply
|
||||
- edit them again
|
||||
- hit cancel / escape
|
||||
- check you get back to the apply state
|
||||
OK
|
||||
|
||||
- make two brushes
|
||||
- select a brush
|
||||
- bring up surface inspector
|
||||
- change settings
|
||||
- select an additional brush
|
||||
- check the surface inspector, new snapshot
|
||||
- hit cancel
|
||||
- check brushes remained in the same state
|
||||
- use standard Undo
|
||||
- check the first brush got back to it's initial settings
|
||||
OK
|
||||
|
||||
- select a brush
|
||||
- bring up surface inspector
|
||||
- change settings
|
||||
- select an additional brush
|
||||
- check the surface inspector, new snapshot
|
||||
- change more settings
|
||||
- hit cancel
|
||||
- check the first brush returned to intermediate state, and second to initial state (i.e. last snapshot)
|
||||
OK
|
||||
|
||||
g_surfaceUndo acts as a layer on top of the core Undo code when the surface inspector is activated.
|
||||
We need it because the surface inspector can edit faces which are not handled by the undo?
|
||||
(or does the current code push the whole brush when editing a face?)
|
||||
|
||||
not sure of the utility of the g_surfaceDialog hooks here ..
|
||||
default undo usage in the sruface inspector sends way too many undo messages.
|
||||
with the new scheme we store in undo only when select/deselect or user hits apply
|
||||
that way the 'Cancel' and later Ctrl+Z calls make sense
|
||||
but is it worth implementing a new class to achieve that?? .. yes because we intend a later cleanup
|
||||
of this part. (ahem is this reason good enough..)
|
||||
this part is actually much closer from the undo code than I had expected..
|
||||
'Cancel' call being an Undo call..
|
||||
|
||||
going to Inspector3:
|
||||
don't create a new class, simply use the Undo more intelligently?
|
||||
i.e. don't create undo stuff when editing the brush
|
||||
-> we add a flag to turn off the default undo behaviour and force Undo storage when we want
|
||||
we could also store the undo Id we are interested in and call undo several times to get it back
|
||||
|
||||
NOTE: what happens if the user hits undo when the surface inspector is up?
|
||||
-> we'll have to take his request into account?
|
||||
err .. performing which undo? The texture positioning or something else?
|
||||
seems the snapshot approach would still make sense then?
|
||||
|
||||
more use cases, see with Undo calls and select/deselect events
|
||||
NOTE: this whole thing is probably a single call to select_settexture that needs to be turned on/off
|
||||
instead of working at the undo level. but we would like to move to messaging so maybe it still makes sense
|
||||
the undo call is in Select_SetTexture (which does not have that many callers, I was expecting more)
|
||||
|
||||
the question about having the undo code keep working when surface inspector is around is still raised.
|
||||
but it makes it a lot harder, gotta have a real inspector mode in the undo?
|
||||
dunno, think about it again later
|
||||
|
||||
two operations are mixed in a single one and should not be:
|
||||
reading the map to get the current data we'll manipulate
|
||||
feed it in the dialog box widgets
|
||||
WARNING: when putting stuff in the widgets, it raises a shitload of update messages and therefor completely
|
||||
fucks up our OnOK OnApply OnCancel scheme (specially OnApply!)
|
||||
|
||||
NOTE: we want to switch between Surface inspector for brushes only and Patch inspector for patches only
|
||||
there's some crappy code in the surface inspector that we need to get rid of
|
||||
but need to check about that before with Spog or others
|
||||
|
||||
Forcing the way into using the surface inspector is SCREWED?
|
||||
Doesn't seem to work the way we want to. Always get parasite Undo messages and stuff.
|
||||
We could use a seperate stack for Undo with the surface inspector?
|
||||
Just store the surface properties in a seperate stack?
|
||||
When user hits cancel you go back and apply whatever you had?
|
||||
Doesn't seem like a clean way either.
|
||||
|
||||
Now dealing with both regular surface inspector and patch inspector:
|
||||
we have some stuff that needs to be on/off with the two inspectors
|
||||
what about catching the messages and issuing new snapshots?
|
||||
the main surface inspector is doing it?
|
||||
no!
|
||||
so what, we have several states?
|
||||
FUCKED UP
|
||||
|
||||
INSPECTOR 5 ----------------------------------------------------------------
|
||||
restarted from scratch, made much more simple changes.
|
||||
trying another trick for undo (!)
|
||||
just let the undo work as usual, but call undo ourselves in SetTexMods if we have create the last do
|
||||
requires proper initialization/deinitialisation.. in SetTexMods and GetTexMods..
|
||||
|
||||
getting rid of patch manipulation code in the regular surface inspector. The buttons will
|
||||
still work, but manip will require the patch inspector. (seems the patch inspector doesn't have that
|
||||
much success anyway)
|
||||
|
||||
TODO:
|
||||
OK get rid of patch stuff
|
||||
OK get rid of the texture toolbar? (it's broken right now)
|
||||
(and doesn't have anything usefull..)
|
||||
OK (Partial) OnCancel? we need to cancel the texdef as well
|
||||
store an undo texdef each time we grab new texdef stuff
|
||||
this works in reverse than the Undo code? When we do the initial
|
||||
problem is, in some cases the settings that show up are not in sync with what's in the inspector??
|
||||
(we can't avoid that because if a brush is selected there's no single setting)
|
||||
prolly get it out as is and let Spog or others send feedback about what it's supposed to do..
|
||||
for now: store stuff in the cancel texdef when we initialize an undo loop
|
||||
revert to that if OnCancel is used
|
||||
OK message when spinning over a patch?
|
||||
DUPLICATE (.. see below ..) check the increments we store in the SI are used when shift + arrows etc.
|
||||
no it doesn't work .. the shifting on keyboard shortcuts is done with m_nTextureTweak
|
||||
seems m_nTextureTweak is nowhere available in the prefs (and it's not in MFC builds either)
|
||||
some cleanup to be done around that it seems
|
||||
OK (.. merged with below, maybe some special cases left ..) texture widget (catch the Enter key to force-call an OnApply)
|
||||
OK (.. see above ..) catch Enter key at dialog level to call OnDone
|
||||
NO (.. it's clean, but thats too many lines of code ..) move the code that blokes updates to use gtk_signal_handler_block_by_func and gtk_signal_handler_block_by_func
|
||||
OK shift + arrow must match the SI settings,
|
||||
OK (FIXME .. not using the right scale (using the scale step instead! + add a button in SI to 'Match grid')
|
||||
POSTPONED (.. m_nTextureTweak is used in the nudge commands ..
|
||||
.. and nudge shortcuts are broken right now ..) get rid of m_nTextureTweak
|
||||
+ SI and PI always on top!
|
||||
|
||||
+ known issues: "Match Grid" is broken in BP mode
|
||||
|
||||
now on the patch inspector (nightmare!):
|
||||
OK (.. put it as readonly .. don't bother ..) texture name widget is screwed?
|
||||
OK the spinners scheme doesn't work, the stuff in the dialog is the inc step and we just need arrows
|
||||
OK get rid of the 'Type' dialog box
|
||||
POSTPONED (.. can't do undo on PI without proper Undo module ..) add proper Done Apply Cancel with Undo
|
||||
NO (.. too much work for something that sucks ..) make the changes reflect in the views when manipulating the entries
|
||||
OK (.. using %g ..) cut down on the number of digits!
|
||||
OK increment steps to be stored in the registry
|
||||
|
||||
putting the Cancel stuff in the surface inspector: only based on the Undo code, no cancel settings to store
|
||||
because we don't have actual storage of a current texdef (we only send alterations) BTW we should do that for
|
||||
brushes as well
|
||||
the patch inspector works by increments, Patch_SetTextureInfo to incrementally modify the patch.
|
||||
we can still do some undo by having a texdef storing the changes and working together with the undo
|
||||
if the undo is recognized, it means our current texdef increment is valid
|
||||
no, we can't represent the combination of several increments scale and rotate in a single texdef..
|
||||
get rid of the undo code for now .. only Apply and Done left
|
||||
|
||||
it seems it's still vastly broken when you select something. or is it on linux only?
|
||||
need a LOT of testing and figuring it out!!
|
||||
selecting a brush breaks totally.. (the texture screws up it seems)
|
||||
does it attempt to change the texture of the selected object??
|
||||
also: it seems you can multiple select a same brush??
|
||||
|
||||
the UNDO code of the SURFACE INSPECTOR IS STILL BROKEN ????
|
||||
(ok I'm really screwed, time to sleep)
|
||||
-> can't reproduce now?? maybe it's linux specific problem, I can't tell
|
||||
|
||||
FOUND A WAY TO REPRODUCE THE CRASH:
|
||||
+ select brush
|
||||
+ hit "Fit"
|
||||
+ hit the shift spinners two times
|
||||
OR:
|
||||
+ select single face on brush
|
||||
+ manually edit scale values
|
||||
-> maybe we have a problem with current texture? (NO)
|
||||
it's some kind of infinite loop? we call UpdateSurfaceInspector from Select_Brush and bang!
|
||||
no, it's a texdef from a face that got deleted
|
||||
prolly that hooking the undo code in there screws up the selected faces stuff
|
||||
if you undo a selected face operation, you end up with the whole brush selected.
|
||||
but that does not necessarily explain why you remove the face at Undo_Start
|
||||
ho well .. removed the undo buffering when selected faces and everything's better
|
||||
would need to re-establish the right face selection after undo, might solve the problem
|
||||
(actually you'd still need to have the settings point to the right object)
|
||||
|
||||
From PJ about the 'Match Grid' stuff: textures are moved in pixels, not units.
|
||||
We must rely on the current texture scale AND gridsize to compute the shift increment
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
#!perl
|
||||
rename("$ARGV[0]", "$ARGV[0].old");
|
||||
open(FILE, "$ARGV[0].old");
|
||||
open(OFILE, ">$ARGV[0]");
|
||||
while(<FILE>)
|
||||
{
|
||||
if($. != $ARGV[1])
|
||||
{
|
||||
print OFILE;
|
||||
next;
|
||||
}
|
||||
s/Sys_Printf \(/Sys_FPrintf \(SYS_VRB,/;
|
||||
s/Sys_Printf\(/Sys_FPrintf \(SYS_VRB,/;
|
||||
print OFILE;
|
||||
}
|
||||
close(OFILE);
|
||||
#!perl
|
||||
rename("$ARGV[0]", "$ARGV[0].old");
|
||||
open(FILE, "$ARGV[0].old");
|
||||
open(OFILE, ">$ARGV[0]");
|
||||
while(<FILE>)
|
||||
{
|
||||
if($. != $ARGV[1])
|
||||
{
|
||||
print OFILE;
|
||||
next;
|
||||
}
|
||||
s/Sys_Printf \(/Sys_FPrintf \(SYS_VRB,/;
|
||||
s/Sys_Printf\(/Sys_FPrintf \(SYS_VRB,/;
|
||||
print OFILE;
|
||||
}
|
||||
close(OFILE);
|
||||
close(FILE);
|
||||
@@ -1,17 +1,17 @@
|
||||
#!perl
|
||||
rename("brush.c", "brush.c.old");
|
||||
open(FILE, "brush.c.old");
|
||||
open(OFILE, ">brush.c");
|
||||
while(<FILE>)
|
||||
{
|
||||
if($. != 150)
|
||||
{
|
||||
print OFILE;
|
||||
next;
|
||||
}
|
||||
s/Sys_Printf \(/Sys_FPrintf \(SYS_VRB,/;
|
||||
s/Sys_Printf\(/Sys_FPrintf \(SYS_VRB,/;
|
||||
print OFILE;
|
||||
}
|
||||
close(OFILE);
|
||||
#!perl
|
||||
rename("brush.c", "brush.c.old");
|
||||
open(FILE, "brush.c.old");
|
||||
open(OFILE, ">brush.c");
|
||||
while(<FILE>)
|
||||
{
|
||||
if($. != 150)
|
||||
{
|
||||
print OFILE;
|
||||
next;
|
||||
}
|
||||
s/Sys_Printf \(/Sys_FPrintf \(SYS_VRB,/;
|
||||
s/Sys_Printf\(/Sys_FPrintf \(SYS_VRB,/;
|
||||
print OFILE;
|
||||
}
|
||||
close(OFILE);
|
||||
close(FILE);
|
||||
@@ -1,27 +1,27 @@
|
||||
printf mess in q3map
|
||||
(and in the libs)
|
||||
|
||||
q3map: several breeds .. qprintf _printf printf
|
||||
should all resolve to use a single Sys_Printf thing
|
||||
and put #define printf ..
|
||||
|
||||
for the static libs? need to use function pointers..
|
||||
|
||||
q3map uses common/cmdlib.c
|
||||
Radiant links against cmdlib.lib based on libs/cmdlib/cmdlib.cpp
|
||||
|
||||
but eventually we'll want to use the same Sys_Printf scheme in q3map AND Radiant?
|
||||
qprintf and _printf are defined in common/cmdlib.c
|
||||
BUT: modifying cmdlib would probably break bspc and other stuff that relies on it?
|
||||
|
||||
moving q3map to use a custom version of cmdlib.c in q3map/cmdlib.c
|
||||
removing the qprintf and _printf stuff, moving to a seperate printout.c file
|
||||
|
||||
compiling libxml on win32: need to turn off a bunch of stuff.
|
||||
problem: we got two xmlversion.h files??
|
||||
we can't get rid of using libxml/xmlversion.h, so the solution is to get rid of xmlversion.h
|
||||
(add ../libxml to the paths)
|
||||
|
||||
fuck!
|
||||
we also compile some .c files from common/ !
|
||||
-> create a common2/ dir ..
|
||||
printf mess in q3map
|
||||
(and in the libs)
|
||||
|
||||
q3map: several breeds .. qprintf _printf printf
|
||||
should all resolve to use a single Sys_Printf thing
|
||||
and put #define printf ..
|
||||
|
||||
for the static libs? need to use function pointers..
|
||||
|
||||
q3map uses common/cmdlib.c
|
||||
Radiant links against cmdlib.lib based on libs/cmdlib/cmdlib.cpp
|
||||
|
||||
but eventually we'll want to use the same Sys_Printf scheme in q3map AND Radiant?
|
||||
qprintf and _printf are defined in common/cmdlib.c
|
||||
BUT: modifying cmdlib would probably break bspc and other stuff that relies on it?
|
||||
|
||||
moving q3map to use a custom version of cmdlib.c in q3map/cmdlib.c
|
||||
removing the qprintf and _printf stuff, moving to a seperate printout.c file
|
||||
|
||||
compiling libxml on win32: need to turn off a bunch of stuff.
|
||||
problem: we got two xmlversion.h files??
|
||||
we can't get rid of using libxml/xmlversion.h, so the solution is to get rid of xmlversion.h
|
||||
(add ../libxml to the paths)
|
||||
|
||||
fuck!
|
||||
we also compile some .c files from common/ !
|
||||
-> create a common2/ dir ..
|
||||
|
||||
@@ -1,34 +1,34 @@
|
||||
========================================================================
|
||||
CONSOLE APPLICATION : XMLPush
|
||||
========================================================================
|
||||
|
||||
|
||||
AppWizard has created this XMLPush application for you.
|
||||
|
||||
This file contains a summary of what you will find in each of the files that
|
||||
make up your XMLPush application.
|
||||
|
||||
XMLPush.dsp
|
||||
This file (the project file) contains information at the project level and
|
||||
is used to build a single project or subproject. Other users can share the
|
||||
project (.dsp) file, but they should export the makefiles locally.
|
||||
|
||||
XMLPush.cpp
|
||||
This is the main application source file.
|
||||
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
Other standard files:
|
||||
|
||||
StdAfx.h, StdAfx.cpp
|
||||
These files are used to build a precompiled header (PCH) file
|
||||
named XMLPush.pch and a precompiled types file named StdAfx.obj.
|
||||
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
Other notes:
|
||||
|
||||
AppWizard uses "TODO:" to indicate parts of the source code you
|
||||
should add to or customize.
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
========================================================================
|
||||
CONSOLE APPLICATION : XMLPush
|
||||
========================================================================
|
||||
|
||||
|
||||
AppWizard has created this XMLPush application for you.
|
||||
|
||||
This file contains a summary of what you will find in each of the files that
|
||||
make up your XMLPush application.
|
||||
|
||||
XMLPush.dsp
|
||||
This file (the project file) contains information at the project level and
|
||||
is used to build a single project or subproject. Other users can share the
|
||||
project (.dsp) file, but they should export the makefiles locally.
|
||||
|
||||
XMLPush.cpp
|
||||
This is the main application source file.
|
||||
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
Other standard files:
|
||||
|
||||
StdAfx.h, StdAfx.cpp
|
||||
These files are used to build a precompiled header (PCH) file
|
||||
named XMLPush.pch and a precompiled types file named StdAfx.obj.
|
||||
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
Other notes:
|
||||
|
||||
AppWizard uses "TODO:" to indicate parts of the source code you
|
||||
should add to or customize.
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
@@ -1,27 +1,27 @@
|
||||
XMLmap branch:
|
||||
|
||||
need to move the map loading / saving code out in a module
|
||||
what are the main dependencies?
|
||||
|
||||
main functions to move out:
|
||||
Map_LoadFile
|
||||
Map_SaveFile
|
||||
(and all their direct dependencies/call graph)
|
||||
ex Entity_Parse Brush_Parse Entity_Write Brush_Write
|
||||
|
||||
but? even changing to XML format we would need those functions too?
|
||||
is it worth having the .map and .xmlmap through a same interface?
|
||||
|
||||
what dependencies?
|
||||
-> active_brushes
|
||||
-> GetToken etc.
|
||||
-> LoadFile (load into a buffer) .. that's VFS right?
|
||||
|
||||
first step: move some code out in map module and try to compile it..
|
||||
Map_LoadFile for example
|
||||
or the whole map.cpp?
|
||||
|
||||
first problem: entity_t is declared in entity.h, currently not available to
|
||||
the plugin API. Clean way would be to create a wrapper, but speed says we
|
||||
should move entity_t to qertypes.h..
|
||||
|
||||
XMLmap branch:
|
||||
|
||||
need to move the map loading / saving code out in a module
|
||||
what are the main dependencies?
|
||||
|
||||
main functions to move out:
|
||||
Map_LoadFile
|
||||
Map_SaveFile
|
||||
(and all their direct dependencies/call graph)
|
||||
ex Entity_Parse Brush_Parse Entity_Write Brush_Write
|
||||
|
||||
but? even changing to XML format we would need those functions too?
|
||||
is it worth having the .map and .xmlmap through a same interface?
|
||||
|
||||
what dependencies?
|
||||
-> active_brushes
|
||||
-> GetToken etc.
|
||||
-> LoadFile (load into a buffer) .. that's VFS right?
|
||||
|
||||
first step: move some code out in map module and try to compile it..
|
||||
Map_LoadFile for example
|
||||
or the whole map.cpp?
|
||||
|
||||
first problem: entity_t is declared in entity.h, currently not available to
|
||||
the plugin API. Clean way would be to create a wrapper, but speed says we
|
||||
should move entity_t to qertypes.h..
|
||||
|
||||
|
||||
@@ -1,76 +1,76 @@
|
||||
Listing of required modules and interfaces as an XML file
|
||||
=========================================================
|
||||
|
||||
Purpose:
|
||||
--------
|
||||
|
||||
Make the editor more data driven. Be able to specify during
|
||||
startup the full running configuration of the editor:
|
||||
- what modules to load
|
||||
- general execution paths (i.e. what's in the project settings)
|
||||
- configuration for the loaded modules
|
||||
- user preferences
|
||||
|
||||
Feature Requirements:
|
||||
---------------------
|
||||
|
||||
This is primarily intended for multiple games support. A restart
|
||||
of the editor may be required when going from one game to the
|
||||
other, but otherwise it should read the XML file and initialize
|
||||
the right modules and APIs from there.
|
||||
|
||||
Don't have a clear view of what multiple games support is gonna
|
||||
be like. Can list a few things:
|
||||
|
||||
- some interfaces are required for startup in a given game mode.
|
||||
That's primarily what the XML config file is there for.
|
||||
For instance in Q3 you will require Q3 map format module
|
||||
and Q1 will require Q1 map format module
|
||||
|
||||
- some modules are to be ignored? that's primary intended to
|
||||
avoid loading unneeded modules.
|
||||
|
||||
- some plugins are loaded for all games?
|
||||
- some plugins are only relevant for some games?
|
||||
(those two suggest various installation paths for modules
|
||||
and directory-based scan?)
|
||||
|
||||
- a plugin might require some other APIs to complete it's loading
|
||||
process (i.e. sending it's own XML description of required
|
||||
interfaces).
|
||||
|
||||
Constaints:
|
||||
-----------
|
||||
|
||||
We have a nasty collision between preferences / project settings
|
||||
and XML requirements. All three things need to be unified in some way.
|
||||
The long term target being to have a central installation location
|
||||
for the editor, and independant packages for each game.
|
||||
|
||||
What kind of difference is there between project settings and prefs?
|
||||
Prefs would be user settings that survive throughout all games,
|
||||
whereas project settings are per-game / per-mod configuration. Turns
|
||||
out it's all a matter of loading the right configuration chunks at the
|
||||
right time.
|
||||
|
||||
Proposed implementation:
|
||||
------------------------
|
||||
|
||||
Use key/values (== property bags) based on XML format for everything.
|
||||
Use them on project settings, and user prefs. The only difference
|
||||
between what would be project settings and what would be user pref
|
||||
is in which game configuration they are loaded, and how they are used.
|
||||
|
||||
Project templates: We have a particular syntax to build settings from
|
||||
a 'template' version. Instead of loading a project template, we should
|
||||
be selecting a template from a list.
|
||||
|
||||
Default startup: If we are configured to load last project on startup,
|
||||
load it .. otherwise display a list of games and templates?
|
||||
|
||||
Module library:
|
||||
---------------
|
||||
|
||||
The dynamic loading / interfaces sharing / pure virtual classes needs
|
||||
to be implemented in a generic module. It should be the basis of the
|
||||
editor startup process.
|
||||
Listing of required modules and interfaces as an XML file
|
||||
=========================================================
|
||||
|
||||
Purpose:
|
||||
--------
|
||||
|
||||
Make the editor more data driven. Be able to specify during
|
||||
startup the full running configuration of the editor:
|
||||
- what modules to load
|
||||
- general execution paths (i.e. what's in the project settings)
|
||||
- configuration for the loaded modules
|
||||
- user preferences
|
||||
|
||||
Feature Requirements:
|
||||
---------------------
|
||||
|
||||
This is primarily intended for multiple games support. A restart
|
||||
of the editor may be required when going from one game to the
|
||||
other, but otherwise it should read the XML file and initialize
|
||||
the right modules and APIs from there.
|
||||
|
||||
Don't have a clear view of what multiple games support is gonna
|
||||
be like. Can list a few things:
|
||||
|
||||
- some interfaces are required for startup in a given game mode.
|
||||
That's primarily what the XML config file is there for.
|
||||
For instance in Q3 you will require Q3 map format module
|
||||
and Q1 will require Q1 map format module
|
||||
|
||||
- some modules are to be ignored? that's primary intended to
|
||||
avoid loading unneeded modules.
|
||||
|
||||
- some plugins are loaded for all games?
|
||||
- some plugins are only relevant for some games?
|
||||
(those two suggest various installation paths for modules
|
||||
and directory-based scan?)
|
||||
|
||||
- a plugin might require some other APIs to complete it's loading
|
||||
process (i.e. sending it's own XML description of required
|
||||
interfaces).
|
||||
|
||||
Constaints:
|
||||
-----------
|
||||
|
||||
We have a nasty collision between preferences / project settings
|
||||
and XML requirements. All three things need to be unified in some way.
|
||||
The long term target being to have a central installation location
|
||||
for the editor, and independant packages for each game.
|
||||
|
||||
What kind of difference is there between project settings and prefs?
|
||||
Prefs would be user settings that survive throughout all games,
|
||||
whereas project settings are per-game / per-mod configuration. Turns
|
||||
out it's all a matter of loading the right configuration chunks at the
|
||||
right time.
|
||||
|
||||
Proposed implementation:
|
||||
------------------------
|
||||
|
||||
Use key/values (== property bags) based on XML format for everything.
|
||||
Use them on project settings, and user prefs. The only difference
|
||||
between what would be project settings and what would be user pref
|
||||
is in which game configuration they are loaded, and how they are used.
|
||||
|
||||
Project templates: We have a particular syntax to build settings from
|
||||
a 'template' version. Instead of loading a project template, we should
|
||||
be selecting a template from a list.
|
||||
|
||||
Default startup: If we are configured to load last project on startup,
|
||||
load it .. otherwise display a list of games and templates?
|
||||
|
||||
Module library:
|
||||
---------------
|
||||
|
||||
The dynamic loading / interfaces sharing / pure virtual classes needs
|
||||
to be implemented in a generic module. It should be the basis of the
|
||||
editor startup process.
|
||||
|
||||
@@ -1,33 +1,33 @@
|
||||
** currently supported debug messages:
|
||||
|
||||
* map leaked / pointfile information
|
||||
+ tested
|
||||
|
||||
* duplicate plane
|
||||
+ tested
|
||||
|
||||
* degenerate plane, mirrored plane
|
||||
+ testing may not be necessary, exact same code as duplicate plane
|
||||
|
||||
* mixed CONTENTS_DETAIL and CONTENTS_STRUCTURAL
|
||||
- not tested!
|
||||
|
||||
* fog brush has multiple visible sides
|
||||
+ tested
|
||||
|
||||
* WindingFromDrawSurf failed: MAX_POINTS_ON_WINDING exceeded
|
||||
+ tested, only outputs a single point, would need much improvement
|
||||
(TstMaps/western.map)
|
||||
|
||||
* MAX_BUILD_SIDES
|
||||
uses xml_Select as other warnings, switched xml_Select to error or warn
|
||||
+ tested
|
||||
|
||||
** to-be-added list (and associated test map file if any)
|
||||
|
||||
* Node without a volume
|
||||
* leaf with too many portals
|
||||
-> both in Desktop_p_leaf.map, contributed by y_lavanant@vistech.ie
|
||||
|
||||
Mesh lightmap miscount
|
||||
** currently supported debug messages:
|
||||
|
||||
* map leaked / pointfile information
|
||||
+ tested
|
||||
|
||||
* duplicate plane
|
||||
+ tested
|
||||
|
||||
* degenerate plane, mirrored plane
|
||||
+ testing may not be necessary, exact same code as duplicate plane
|
||||
|
||||
* mixed CONTENTS_DETAIL and CONTENTS_STRUCTURAL
|
||||
- not tested!
|
||||
|
||||
* fog brush has multiple visible sides
|
||||
+ tested
|
||||
|
||||
* WindingFromDrawSurf failed: MAX_POINTS_ON_WINDING exceeded
|
||||
+ tested, only outputs a single point, would need much improvement
|
||||
(TstMaps/western.map)
|
||||
|
||||
* MAX_BUILD_SIDES
|
||||
uses xml_Select as other warnings, switched xml_Select to error or warn
|
||||
+ tested
|
||||
|
||||
** to-be-added list (and associated test map file if any)
|
||||
|
||||
* Node without a volume
|
||||
* leaf with too many portals
|
||||
-> both in Desktop_p_leaf.map, contributed by y_lavanant@vistech.ie
|
||||
|
||||
Mesh lightmap miscount
|
||||
(no test map)
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,75 +1,75 @@
|
||||
search orders with different settings
|
||||
|
||||
|
||||
=====================
|
||||
NON-TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
headmodel = *callisto/lily
|
||||
|
||||
models/players/heads/callisto/lily/head_default.skin
|
||||
models/players/heads/callisto/head_lily.skin
|
||||
|
||||
|
||||
-------------------------------------------------
|
||||
headmodel = callisto/lily
|
||||
|
||||
models/players/callisto/lily/head_default.skin
|
||||
models/players/callisto/head_lily.skin
|
||||
models/players/heads/callisto/lily/head_default.skin
|
||||
models/players/heads/callisto/head_lily.skin
|
||||
|
||||
|
||||
|
||||
=====================
|
||||
Q3 TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
team_headmodel = *callisto/lily
|
||||
team = red
|
||||
|
||||
models/players/heads/callisto/lily/head_red.skin
|
||||
models/players/heads/callisto/head_red.skin
|
||||
|
||||
|
||||
-------------------------------------------------
|
||||
team_headmodel = callisto/lily
|
||||
team = red
|
||||
|
||||
models/players/callisto/lily/head_red.skin
|
||||
models/players/callisto/head_red.skin
|
||||
models/players/heads/callisto/lily/head_red.skin
|
||||
models/players/heads/callisto/head_red.skin
|
||||
|
||||
|
||||
|
||||
=====================
|
||||
TA TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
team_headmodel = *callisto/lily
|
||||
team = red
|
||||
teamName = Stroggs
|
||||
|
||||
models/players/heads/callisto/lily/Stroggs/head_red.skin
|
||||
models/players/heads/callisto/Stroggs/head_red.skin
|
||||
models/players/heads/callisto/lily/head_red.skin
|
||||
models/players/heads/callisto/head_red.skin
|
||||
|
||||
|
||||
-------------------------------------------------
|
||||
team_headmodel = callisto/lily
|
||||
team = red
|
||||
teamName = Stroggs
|
||||
|
||||
models/players/callisto/lily/Stroggs/head_red.skin
|
||||
models/players/callisto/Stroggs/head_red.skin
|
||||
models/players/callisto/lily/head_red.skin
|
||||
models/players/callisto/head_red.skin
|
||||
models/players/heads/callisto/lily/Stroggs/head_red.skin
|
||||
models/players/heads/callisto/Stroggs/head_red.skin
|
||||
models/players/heads/callisto/lily/head_red.skin
|
||||
models/players/heads/callisto/head_red.skin
|
||||
search orders with different settings
|
||||
|
||||
|
||||
=====================
|
||||
NON-TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
headmodel = *callisto/lily
|
||||
|
||||
models/players/heads/callisto/lily/head_default.skin
|
||||
models/players/heads/callisto/head_lily.skin
|
||||
|
||||
|
||||
-------------------------------------------------
|
||||
headmodel = callisto/lily
|
||||
|
||||
models/players/callisto/lily/head_default.skin
|
||||
models/players/callisto/head_lily.skin
|
||||
models/players/heads/callisto/lily/head_default.skin
|
||||
models/players/heads/callisto/head_lily.skin
|
||||
|
||||
|
||||
|
||||
=====================
|
||||
Q3 TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
team_headmodel = *callisto/lily
|
||||
team = red
|
||||
|
||||
models/players/heads/callisto/lily/head_red.skin
|
||||
models/players/heads/callisto/head_red.skin
|
||||
|
||||
|
||||
-------------------------------------------------
|
||||
team_headmodel = callisto/lily
|
||||
team = red
|
||||
|
||||
models/players/callisto/lily/head_red.skin
|
||||
models/players/callisto/head_red.skin
|
||||
models/players/heads/callisto/lily/head_red.skin
|
||||
models/players/heads/callisto/head_red.skin
|
||||
|
||||
|
||||
|
||||
=====================
|
||||
TA TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
team_headmodel = *callisto/lily
|
||||
team = red
|
||||
teamName = Stroggs
|
||||
|
||||
models/players/heads/callisto/lily/Stroggs/head_red.skin
|
||||
models/players/heads/callisto/Stroggs/head_red.skin
|
||||
models/players/heads/callisto/lily/head_red.skin
|
||||
models/players/heads/callisto/head_red.skin
|
||||
|
||||
|
||||
-------------------------------------------------
|
||||
team_headmodel = callisto/lily
|
||||
team = red
|
||||
teamName = Stroggs
|
||||
|
||||
models/players/callisto/lily/Stroggs/head_red.skin
|
||||
models/players/callisto/Stroggs/head_red.skin
|
||||
models/players/callisto/lily/head_red.skin
|
||||
models/players/callisto/head_red.skin
|
||||
models/players/heads/callisto/lily/Stroggs/head_red.skin
|
||||
models/players/heads/callisto/Stroggs/head_red.skin
|
||||
models/players/heads/callisto/lily/head_red.skin
|
||||
models/players/heads/callisto/head_red.skin
|
||||
|
||||
@@ -1,73 +1,73 @@
|
||||
search orders with different settings
|
||||
|
||||
|
||||
=====================
|
||||
NON-TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
model = hunter/harpy
|
||||
|
||||
|
||||
legs:
|
||||
models/players/hunter/lower_harpy_default.skin
|
||||
models/players/hunter/lower_harpy.skin
|
||||
models/players/characters/james/lower_harpy_default.skin
|
||||
models/players/characters/james/lower_harpy.skin
|
||||
torso:
|
||||
models/players/hunter/upper_harpy_default.skin
|
||||
models/players/hunter/upper_harpy.skin
|
||||
models/players/characters/hunter/upper_harpy_default.skin
|
||||
models/players/characters/hunter/upper_harpy.skin
|
||||
|
||||
|
||||
=====================
|
||||
Q3 TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
team_model = hunter/harpy
|
||||
team = red
|
||||
|
||||
legs:
|
||||
models/players/hunter/lower_harpy_red.skin
|
||||
models/players/hunter/lower_red.skin
|
||||
models/players/characters/hunter/lower_harpy_red.skin
|
||||
models/players/characters/hunter/lower_red.skin
|
||||
torso:
|
||||
models/players/hunter/upper_harpy_red.skin
|
||||
models/players/hunter/upper_red.skin
|
||||
models/players/characters/hunter/upper_harpy_red.skin
|
||||
models/players/characters/hunter/upper_red.skin
|
||||
|
||||
|
||||
=====================
|
||||
TA TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
team_model = james/badass
|
||||
team = red
|
||||
teamName = Stroggs
|
||||
|
||||
legs:
|
||||
models/players/james/Stroggs/lower_badass_red.skin
|
||||
models/players/james/Stroggs/lower_red.skin
|
||||
models/players/james/lower_badass_red.skin
|
||||
models/players/james/lower_red.skin
|
||||
models/players/characters/james/Stroggs/lower_badass_red.skin
|
||||
models/players/characters/james/Stroggs/lower_red.skin
|
||||
models/players/characters/james/lower_badass_red.skin
|
||||
models/players/characters/james/lower_red.skin
|
||||
torso:
|
||||
models/players/james/Stroggs/upper_badass_red.skin
|
||||
models/players/james/Stroggs/upper_red.skin
|
||||
models/players/james/upper_badass_red.skin
|
||||
models/players/james/upper_red.skin
|
||||
models/players/characters/james/Stroggs/upper_badass_red.skin
|
||||
models/players/characters/james/Stroggs/upper_red.skin
|
||||
models/players/characters/james/upper_badass_red.skin
|
||||
models/players/characters/james/upper_red.skin
|
||||
|
||||
|
||||
|
||||
search orders with different settings
|
||||
|
||||
|
||||
=====================
|
||||
NON-TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
model = hunter/harpy
|
||||
|
||||
|
||||
legs:
|
||||
models/players/hunter/lower_harpy_default.skin
|
||||
models/players/hunter/lower_harpy.skin
|
||||
models/players/characters/james/lower_harpy_default.skin
|
||||
models/players/characters/james/lower_harpy.skin
|
||||
torso:
|
||||
models/players/hunter/upper_harpy_default.skin
|
||||
models/players/hunter/upper_harpy.skin
|
||||
models/players/characters/hunter/upper_harpy_default.skin
|
||||
models/players/characters/hunter/upper_harpy.skin
|
||||
|
||||
|
||||
=====================
|
||||
Q3 TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
team_model = hunter/harpy
|
||||
team = red
|
||||
|
||||
legs:
|
||||
models/players/hunter/lower_harpy_red.skin
|
||||
models/players/hunter/lower_red.skin
|
||||
models/players/characters/hunter/lower_harpy_red.skin
|
||||
models/players/characters/hunter/lower_red.skin
|
||||
torso:
|
||||
models/players/hunter/upper_harpy_red.skin
|
||||
models/players/hunter/upper_red.skin
|
||||
models/players/characters/hunter/upper_harpy_red.skin
|
||||
models/players/characters/hunter/upper_red.skin
|
||||
|
||||
|
||||
=====================
|
||||
TA TEAMPLAY
|
||||
=====================
|
||||
|
||||
-------------------------------------------------
|
||||
team_model = james/badass
|
||||
team = red
|
||||
teamName = Stroggs
|
||||
|
||||
legs:
|
||||
models/players/james/Stroggs/lower_badass_red.skin
|
||||
models/players/james/Stroggs/lower_red.skin
|
||||
models/players/james/lower_badass_red.skin
|
||||
models/players/james/lower_red.skin
|
||||
models/players/characters/james/Stroggs/lower_badass_red.skin
|
||||
models/players/characters/james/Stroggs/lower_red.skin
|
||||
models/players/characters/james/lower_badass_red.skin
|
||||
models/players/characters/james/lower_red.skin
|
||||
torso:
|
||||
models/players/james/Stroggs/upper_badass_red.skin
|
||||
models/players/james/Stroggs/upper_red.skin
|
||||
models/players/james/upper_badass_red.skin
|
||||
models/players/james/upper_red.skin
|
||||
models/players/characters/james/Stroggs/upper_badass_red.skin
|
||||
models/players/characters/james/Stroggs/upper_red.skin
|
||||
models/players/characters/james/upper_badass_red.skin
|
||||
models/players/characters/james/upper_red.skin
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user